From nobody Fri Jul 1 07:09:13 2016 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 0BEF112D65E for ; Fri, 1 Jul 2016 07:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 Gm-CW3u9nA_m for ; Fri, 1 Jul 2016 07:09:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 88B6412D650 for ; Fri, 1 Jul 2016 07:09:08 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id BF689C1B1C8A5; Fri, 1 Jul 2016 14:09:03 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u61E96hv021392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2016 14:09:06 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u61E7qEP014852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Jul 2016 16:09:05 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 1 Jul 2016 16:07:49 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Carsten Bormann , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] WG Last Call for draft-ietf-core-http-mapping-11 Thread-Index: AQHR0HF1H8Nvee8urUSaVHjBlEy6f5//qxiAgABnMYCAACAKgP//9tGAgAAIewCAAAk6AIAAvjaAgABdv4CAAAMSAIAAG/AAgABAcACAAdv3AA== Date: Fri, 1 Jul 2016 14:07:48 +0000 Message-ID: References: <1353C239-453D-4F44-ADD5-0BD300A25B6A@ericsson.com> <244bdb7e-6cad-b795-685c-df1f7d0872d3@nteczone.com> <5773AADB.7040906@tzi.org> <240903ef168f7c6559d493ad50406349@xs4all.nl> <5773B9B6.40508@tzi.org> <4dce44e3-8279-b86c-8376-4a332323f925@nteczone.com> <5774F7FA.7020801@tzi.org> In-Reply-To: <5774F7FA.7020801@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] WG Last Call for draft-ietf-core-http-mapping-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jul 2016 14:09:12 -0000 Peter, Carsten: thanks for the suggestions. I think I'm going with Carsten's proposal, which seems to be the safest from the point of view of the requirements on future specs: This document describes HTTP mappings that apply to protocol elements defined in the base CoAP specification [RFC7252]. It is up to CoAP protocol extensions (new methods, response codes, options, content- formats) to describe their own HTTP mappings, if applicable. Cheers, t On 30/06/2016 11:44, "core on behalf of Carsten Bormann" wrote: >Fossati, Thomas (Nokia - GB) wrote: >> Peter, Carsten: is it OK for you as well? Or do you want to propose a >> different wording? > >I'm not sure this is the place to make mandates about what other >specifications will be. > >I'd rather say that this document describes base CoAP (insert >references) and it is up to extensions... to describe their HTTP mapping. > >(Specific example: I don't think we should nail down an HTTP mapping >for FETCH/PATCH at the same time we nail down the CoAP side. Just as we >nailed down RFC 7252 before completing the HTTP mapping informational >document.) > >Gr=FC=DFe, Carsten > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From nobody Fri Jul 1 09:14:58 2016 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 7955212D73E; Fri, 1 Jul 2016 09:14:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160701161457.24686.61194.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2016 09:14:57 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 16:14:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Guidelines for HTTP-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-12.txt Pages : 36 Date : 2016-07-01 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 3 21:34:33 2016 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 6A24912D1ED; Sun, 3 Jul 2016 21:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUvEWwTFnYdN; Sun, 3 Jul 2016 21:34:30 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 0A17112D1DC; Sun, 3 Jul 2016 21:34:30 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id c34so82909104qte.0; Sun, 03 Jul 2016 21:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Hc71Ked/Wg5reRON7/0QFIgh9+X11Plh2hkxJFJKXxU=; b=ZZzaU2bO/gDk9TYdNF1xqXX6Cp5I3+nqjMpr46sAyvodAsCHJOiTiCgY5P0FG/MhGR 6INVq71euUPKpZIDT5Gjisf18uhHHO5pY0h5RhXToNawgMEYOktxhUF2ZnyO601bzIHI k9/krX6C+fKlyyboAlhN5WoMYZl5WXkXuV9pn95keTnNMX3VVcrtNpVd4yXsVqF6PK1r 1qZGzeGTufJ6jym4hdeC82qpzhMv7VJSwagqEY0GfyqVI+tGcJRX+NCHaOHpcM6hlME6 jy6jfyF/bna+my+3VYykk5+sgCRcL+cRdGplnX/MraDgBUsJ0mAQlQpuLZrpefvDmjlR MMjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Hc71Ked/Wg5reRON7/0QFIgh9+X11Plh2hkxJFJKXxU=; b=FAkMXZWqO9DR2TP1AomA4wnm84LPLyZGRjxO/ByDGVKqcnhqQEMpXuLt/Rl6q35tWu tob4xUhuSveKU9eAD5KTcjKJ3o0MnFTyEzE1tFCWIX1wLWJbpZKa3QcKFmzfsowsKy+E E6NyfdzLZdLO+Uj1He3Pee7X0r7d5hQ3fKGXkOG+By0Ufc9pNtlm5GK3h6G0BnJI7Q+T PmvuoTCtWAkRFCiGmrH7tpq9VQhgswS+lw+/EBhH7BUB/24HuXWn45WFEOokDHrM2q2h qBLwyA17X4bekwXT7qokilIPLU3fnU2ln5hGJrALxd9BdRPH1BQMaEg+SNfT2Ezgogc1 8r1A== X-Gm-Message-State: ALyK8tKxruLTnmZKB/C3U1D7Ep1UCTPhY2NbvOpkSkvcbann8xGjJPXJQ/rDeJSZdZm1mIR2gOMJa3MvNMbDmQ== X-Received: by 10.200.45.28 with SMTP id n28mr15363741qta.79.1467606869001; Sun, 03 Jul 2016 21:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.71.80 with HTTP; Sun, 3 Jul 2016 21:34:28 -0700 (PDT) In-Reply-To: <0ADB5996A09C254EB300AB612DA815082152B4CA@SZXEMI506-MBX.china.huawei.com> References: <20160704031553.9424.79833.idtracker@ietfa.amsl.com> <0ADB5996A09C254EB300AB612DA815082152B4CA@SZXEMI506-MBX.china.huawei.com> From: Zhen Cao Date: Mon, 4 Jul 2016 12:34:28 +0800 Message-ID: To: lwip@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [core] Fwd: FW: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jul 2016 04:34:32 -0000 FYI. -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, July 04, 2016 11:16 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CoAP Latency Evaluation Authors : Fei Zheng Baicheng Fu Zhen Cao Filename : draft-zheng-core-coap-lantency-evaluation-00.txt Pages : 9 Date : 2016-07-03 Abstract: This document presents the evaluation results of CoAP in terms of various latency metrics over UDP/TCP under different network environments. We conduct experiments via both GPRS and WiFi. We also evaluate how the latency metrics are impacted by the background traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zheng-core-coap-lantency-evaluation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-zheng-core-coap-lantency-evaluation-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 4 01:57:55 2016 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 60FB212B049; Mon, 4 Jul 2016 01:57:50 -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 3p17k2vWfaFD; Mon, 4 Jul 2016 01:57:47 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAF5126FDC; Mon, 4 Jul 2016 01:57:46 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u648vh2C018467; Mon, 4 Jul 2016 10:57:43 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id B74ED1D53C1; Mon, 4 Jul 2016 10:57:42 +0200 (CEST) Received: from 131.111.5.142 by webmail.entel.upc.edu with HTTP; Mon, 4 Jul 2016 10:58:28 +0200 Message-ID: <1610eda080886221317a6a4e3e7c66b4.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <20160704031553.9424.79833.idtracker@ietfa.amsl.com> <0ADB5996A09C254EB300AB612DA815082152B4CA@SZXEMI506-MBX.china.huawei.com> Date: Mon, 4 Jul 2016 10:58:28 +0200 From: "Carles Gomez Montenegro" To: "Zhen Cao" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Mon, 04 Jul 2016 10:57:43 +0200 (CEST) Archived-At: Cc: lwip@ietf.org, "core@ietf.org WG" Subject: Re: [core] Fwd: FW: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jul 2016 08:57:50 -0000 Hi Zhen, Thanks a lot for this draft! A few comments/questions: - Did you measure the native packet loss rate? - In Table 3 (Wi-Fi), latency of CoAP-CoCoA is the same regardless of the manually introduced packet loss rate. I would expect some C-RTT increase with packet loss rate increase... Which is the reason why C-RTT increase does not happen? Or is there maybe some increase below the millisecond granularity? - I noticed that ICMP RTT for GPRS is 572 ms, while obtained C-RTT is often lower than that value. I guess that is due to the size of the ICMP packets used to measure the ICMP RTT? (It would be good to indicate the size of such packets) - In GPRS, we also observed a slight retry ratio increase for CoAP-CoCoA in low congestion GPRS scenarios. However, the retry ratio was significantly lower for CoAP-CoCoA (compared to CoAP-RAW) in moderate to high congestion conditions. It would be interesting to measure what happens for different offered loads. - Which window size did you use for TCP? Minor: - Is the CoAP client (over UDP) encapsulating the messages as CONs? - Apparently there is a jump from section 4.2 to 4.4. - Section 4.4: s/as composed to/as opposed to - Reference [COAPCC]: s/Networks magazine/Communications magazine Cheers, Carles > FYI. > > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 04, 2016 11:16 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : CoAP Latency Evaluation > Authors : Fei Zheng > Baicheng Fu > Zhen Cao > Filename : draft-zheng-core-coap-lantency-evaluation-00.txt > Pages : 9 > Date : 2016-07-03 > > Abstract: > This document presents the evaluation results of CoAP in terms of > various latency metrics over UDP/TCP under different network > environments. We conduct experiments via both GPRS and WiFi. We > also evaluate how the latency metrics are impacted by the background > traffic. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zheng-core-coap-lantency-evaluation/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-zheng-core-coap-lantency-evaluation-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Jul 4 17:30:45 2016 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 E134F12B02E for ; Mon, 4 Jul 2016 17:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 fLtxrnTPni1S for ; Mon, 4 Jul 2016 17:30:42 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 4629E12B00A for ; Mon, 4 Jul 2016 17:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:To:References:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4IQ/KCvxYVeXFZF4L10X1MIovybcT/abfrfUrgVjqh4=; b=gUUVm82MFeiQa50bKE0orNXGQc 8mgfWreAeZ4jTEv+Enhy7vzAK1Ms/O9joGFys0sv4i5MCXaDDS3O2IGsGeA9XokRQnrxMIv+jdLc7 +dblkowg33nQuIH/ib8g7pgTwPdmsn+XPAmpT5lB4bEyVNJ0uf5ix4foeTRCzTWFnb93iZInPDUcK 88l904Zwotzt9fwSUy1hH7EBZyJqxI9xFYlUGGKwuuLt5UM2d8A7TvzW5RFTJ5KjpP6dlThSzAByi kZ3m+tNpyZTVepAtKRnOi6jTVnkDA6BCu7ZpG5rMtn/4JqxWMc5GVUtFBCXVtGvi72DW4SkLd0fQB 0+vL7Bww==; Received: from ppp118-209-41-225.lns20.mel4.internode.on.net ([118.209.41.225]:50087 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bKEG7-002pke-Sd for core@ietf.org; Tue, 05 Jul 2016 10:30:39 +1000 References: <20160705001738.2578.25202.idtracker@ietfa.amsl.com> To: core From: Christian Groves X-Forwarded-Message-Id: <20160705001738.2578.25202.idtracker@ietfa.amsl.com> Message-ID: <0257c801-317d-7432-7c79-1c4c5ee533c3@nteczone.com> Date: Tue, 5 Jul 2016 10:30:38 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160705001738.2578.25202.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [core] Fwd: New Version Notification for draft-groves-coap-webrtcdc-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 00:30:45 -0000 Hello all, FYI, to throw another transport in the CoAP transport mix I've developed a draft looking at transport of CoAP over a WebRTC data channels. I think what's interesting in the transport discussions is to what extent the CoAP "transport functions" are replaced by the underlying transport and also whether CoAP messages are optimised for message transmission or ease of interworking. Several author's notes touch on issues related to these aspects. Regards, Christian -------- Forwarded Message -------- Subject: New Version Notification for draft-groves-coap-webrtcdc-00.txt Date: Mon, 04 Jul 2016 17:17:38 -0700 From: internet-drafts@ietf.org To: Christian Groves , Weiwei Yang A new version of I-D, draft-groves-coap-webrtcdc-00.txt has been successfully submitted by Christian Groves and posted to the IETF repository. Name: draft-groves-coap-webrtcdc Revision: 00 Title: A WebRTC Data Channel Transport for the Constrained Application Protocol (CoAP) Document date: 2016-07-04 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-groves-coap-webrtcdc-00.txt Status: https://datatracker.ietf.org/doc/draft-groves-coap-webrtcdc/ Htmlized: https://tools.ietf.org/html/draft-groves-coap-webrtcdc-00 Abstract: The WebRTC framework defines a generic transport service allowing WEB-browsers and other endpoints to exchange generic data from peer to peer utilizing a Stream Control Transmission Protocol (SCTP) transport. This service is known as Web Real Time Communication WebRTC data channels (WebRTC DC). The use of WebRTC DCs for the Constrained Application Protocol (CoAP) allows WebRTC enabled devices to exchange CoAP data between peers in a secure reliable manner. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jul 5 00:07:00 2016 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 9502A12D137; Tue, 5 Jul 2016 00:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K77JaQ6pnQ5v; Tue, 5 Jul 2016 00:06:57 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 52C1512D11D; Tue, 5 Jul 2016 00:06:57 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id w59so96777599qtd.3; Tue, 05 Jul 2016 00:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pXZ2+44VC+x70e7OOIVNMdusFxWnc+03CgVTIOlpGaQ=; b=w7tAZb6cguI6p3ceEuhtvEPknn/0gM7p0xjHtTIdAolxPukbuNsjjqSkz68pjPnn7q yN9eIrefxaV/9aLmRYGSAdRk5kus1rFePTdRMTh8yAn5EQE9+ofuZ3B0BMGKjxBcRU19 ueW3pWVFzeJQgh/qAY4FgYpOpKclOTdWukfAckE6gDaS7BELSeBxUTQPfgZHajECUcXF trRIKpaKQ1n4tdUfGRCF1P7mu9WKLgRroUewaRQgl9Mhqpheqnk4NDmouzfKeNYsTcPw GVY/PYfMR4Wx2zd6sYSYMHp5jAxeyG6hLa+vy2dt192muJzlYT3glMS13NKrmAZkEm05 2Ojg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pXZ2+44VC+x70e7OOIVNMdusFxWnc+03CgVTIOlpGaQ=; b=jIwANaTtafk+4CuvutobCu9BRarvnGp8/nAPhE1fIxucOypbtk02dC4BjUyX9ow1jT 9b7jRWOLuUYg2k+IdAyI/p6X9EOcoJpjiBSgK54U3pft8g5sgI57dEdUMvZlSyb3nyNl VWUyk3VqT/fy6LOrl7K9IINdOQCGH3d/QnDnae9aRPXih3VopUJ/hpce8y5LlMAvxA+t ErE3ra/otlb31Qt2mxGH0RR0kAcZuL5pREFm39zGvsCTB59RDV8ePtvsTHZY/v69pv24 +vlFnLsBV/8g+XO08xCX0GAGdBPK+oWlhf3A/BuN5m0rYCMfxysn0HB2DLzINKxbKovy SI5A== X-Gm-Message-State: ALyK8tKZsCyVDlVSFQqOUAOhyJwXDL7soq2V48L5F/ncA4u4J7scdwr0mW50atrYsplnaOhhqhj9G64y4OgKyg== X-Received: by 10.237.53.51 with SMTP id a48mr24279225qte.54.1467702416413; Tue, 05 Jul 2016 00:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.71.80 with HTTP; Tue, 5 Jul 2016 00:06:56 -0700 (PDT) In-Reply-To: <1610eda080886221317a6a4e3e7c66b4.squirrel@webmail.entel.upc.edu> References: <20160704031553.9424.79833.idtracker@ietfa.amsl.com> <0ADB5996A09C254EB300AB612DA815082152B4CA@SZXEMI506-MBX.china.huawei.com> <1610eda080886221317a6a4e3e7c66b4.squirrel@webmail.entel.upc.edu> From: Zhen Cao Date: Tue, 5 Jul 2016 15:06:56 +0800 Message-ID: To: Carles Gomez Montenegro Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: lwip@ietf.org, "core@ietf.org WG" Subject: Re: [core] Fwd: FW: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 07:06:59 -0000 Hi Carles, Thanks for feedback. On Mon, Jul 4, 2016 at 4:58 PM, Carles Gomez Montenegro wrote: > Hi Zhen, > > Thanks a lot for this draft! > > A few comments/questions: > > - Did you measure the native packet loss rate? not really. many paper has studied this, native packet loss rate for cellular network is rather low in steady environment, because 3gpp stack is very good at fast retransmission. > > - In Table 3 (Wi-Fi), latency of CoAP-CoCoA is the same regardless of the > manually introduced packet loss rate. I would expect some C-RTT increase > with packet loss rate increase... Which is the reason why C-RTT increase > does not happen? Or is there maybe some increase below the millisecond > granularity? We only notice sub-ms increase in this set of data. Because the data is averaged for the 100 rounds, several retransmissions do not account much probably. > > - I noticed that ICMP RTT for GPRS is 572 ms, while obtained C-RTT is > often lower than that value. I guess that is due to the size of the ICMP > packets used to measure the ICMP RTT? (It would be good to indicate the > size of such packets) ICMP packet size is smaller than CoAP+UDP. ICMP Ping request is 40 bytes. > > - In GPRS, we also observed a slight retry ratio increase for CoAP-CoCoA > in low congestion GPRS scenarios. However, the retry ratio was > significantly lower for CoAP-CoCoA (compared to CoAP-RAW) in moderate to > high congestion conditions. It would be interesting to measure what > happens for different offered loads. CoAP-RAW by default retries after 2 seconds. If the RTT is higher than 2s, CoAP-RAW will definitely be more aggressive than CoAP-CoCoA which calculates RTO based on SmoothedRTT. So what's your RTT? > > - Which window size did you use for TCP? Default on Android, which is TEN. > > Minor: > > - Is the CoAP client (over UDP) encapsulating the messages as CONs? Yes,. > > - Apparently there is a jump from section 4.2 to 4.4. > > - Section 4.4: s/as composed to/as opposed to > > - Reference [COAPCC]: s/Networks magazine/Communications magazine we will correct the above three nits. Many thanks, Zhen > > Cheers, > > Carles > > >> FYI. >> >> >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Monday, July 04, 2016 11:16 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : CoAP Latency Evaluation >> Authors : Fei Zheng >> Baicheng Fu >> Zhen Cao >> Filename : draft-zheng-core-coap-lantency-evaluation-00.txt >> Pages : 9 >> Date : 2016-07-03 >> >> Abstract: >> This document presents the evaluation results of CoAP in terms of >> various latency metrics over UDP/TCP under different network >> environments. We conduct experiments via both GPRS and WiFi. We >> also evaluate how the latency metrics are impacted by the background >> traffic. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-zheng-core-coap-lantency-evaluation/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-zheng-core-coap-lantency-evaluation-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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > From nobody Tue Jul 5 01:02:10 2016 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 5FB9212D09D for ; Tue, 5 Jul 2016 01:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiCumx3xBg5q for ; Tue, 5 Jul 2016 01:02:01 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8749F12D0B0 for ; Tue, 5 Jul 2016 01:02:01 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 1C3E919F3D8 for ; Tue, 5 Jul 2016 16:02:00 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.25]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 73CB019F390; Tue, 5 Jul 2016 16:01:59 +0800 (HKT) Message-ID: From: "weigengyu" To: "Zhen Cao" , "Carles Gomez Montenegro" References: <20160704031553.9424.79833.idtracker@ietfa.amsl.com> <0ADB5996A09C254EB300AB612DA815082152B4CA@SZXEMI506-MBX.china.huawei.com> <1610eda080886221317a6a4e3e7c66b4.squirrel@webmail.entel.upc.edu> In-Reply-To: Date: Tue, 5 Jul 2016 16:01:53 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: lwip@ietf.org, core@ietf.org Subject: Re: [core] Fwd: FW: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 08:02:05 -0000 Hi， Some questions: 1. How large the NS is set for CoAP- Cocoa? 2. The ICMP latency is measured when the FTP background traffic is exiting, or not? 3. For CoAP over TCP on GPRS, how many are the allocated bufffers inside the andoid terminal? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Zhen Cao Sent: Tuesday, July 05, 2016 3:06 PM To: Carles Gomez Montenegro Cc: lwip@ietf.org ; core@ietf.org WG Subject: Re: [core] Fwd: FW: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt Hi Carles, Thanks for feedback. On Mon, Jul 4, 2016 at 4:58 PM, Carles Gomez Montenegro wrote: > Hi Zhen, > > Thanks a lot for this draft! > > A few comments/questions: > > - Did you measure the native packet loss rate? not really. many paper has studied this, native packet loss rate for cellular network is rather low in steady environment, because 3gpp stack is very good at fast retransmission. > > - In Table 3 (Wi-Fi), latency of CoAP-CoCoA is the same regardless of the > manually introduced packet loss rate. I would expect some C-RTT increase > with packet loss rate increase... Which is the reason why C-RTT increase > does not happen? Or is there maybe some increase below the millisecond > granularity? We only notice sub-ms increase in this set of data. Because the data is averaged for the 100 rounds, several retransmissions do not account much probably. > > - I noticed that ICMP RTT for GPRS is 572 ms, while obtained C-RTT is > often lower than that value. I guess that is due to the size of the ICMP > packets used to measure the ICMP RTT? (It would be good to indicate the > size of such packets) ICMP packet size is smaller than CoAP+UDP. ICMP Ping request is 40 bytes. > > - In GPRS, we also observed a slight retry ratio increase for CoAP-CoCoA > in low congestion GPRS scenarios. However, the retry ratio was > significantly lower for CoAP-CoCoA (compared to CoAP-RAW) in moderate to > high congestion conditions. It would be interesting to measure what > happens for different offered loads. CoAP-RAW by default retries after 2 seconds. If the RTT is higher than 2s, CoAP-RAW will definitely be more aggressive than CoAP-CoCoA which calculates RTO based on SmoothedRTT. So what's your RTT? > > - Which window size did you use for TCP? Default on Android, which is TEN. > > Minor: > > - Is the CoAP client (over UDP) encapsulating the messages as CONs? Yes,. > > - Apparently there is a jump from section 4.2 to 4.4. > > - Section 4.4: s/as composed to/as opposed to > > - Reference [COAPCC]: s/Networks magazine/Communications magazine we will correct the above three nits. Many thanks, Zhen > > Cheers, > > Carles > > >> FYI. >> >> >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Monday, July 04, 2016 11:16 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : CoAP Latency Evaluation >> Authors : Fei Zheng >> Baicheng Fu >> Zhen Cao >> Filename : >> draft-zheng-core-coap-lantency-evaluation-00.txt >> Pages : 9 >> Date : 2016-07-03 >> >> Abstract: >> This document presents the evaluation results of CoAP in terms of >> various latency metrics over UDP/TCP under different network >> environments. We conduct experiments via both GPRS and WiFi. We >> also evaluate how the latency metrics are impacted by the background >> traffic. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-zheng-core-coap-lantency-evaluation/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-zheng-core-coap-lantency-evaluation-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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> 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 From nobody Tue Jul 5 02:50:46 2016 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 7FE7112D0FA for ; Tue, 5 Jul 2016 02:50:45 -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 unwUz8CsqyR5 for ; Tue, 5 Jul 2016 02:50:42 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B1312D17B for ; Tue, 5 Jul 2016 02:50:41 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud3.xs4all.net with ESMTP id Exqf1t00b4aYjWA01xqf5g; Tue, 05 Jul 2016 11:50:39 +0200 Received: from AMontpellier-654-1-248-197.w92-133.abo.wanadoo.fr ([92.133.19.197]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 05 Jul 2016 11:50:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 05 Jul 2016 11:50:39 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> X-Sender: stokcons@xs4all.nl (uhqHjSNd2tttqaLrpGjkY5/XlZzl7f0Y) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 09:50:45 -0000 Hi authors, Attached my review of the document. I have not looked at the enum, union encoding as this was done by Andy. ______________________________________________________________________________ YANG to CBOR Section 1 line 2; remove “only” Page 5; the table is referenced nowhere End of section 2.1 “Deltas are represented as positive number” is contradicted in section 4.2 “SIDs as keys” second bullet: “Clients and servers MUST support negative deltas. Suggestion: Deltas are represented as numbers preceded by a + or – sign End page 5: “value need” -> “value needs” Section 3: “the specification supports three types of keys.” I would suggest only 2: character strings and numbers. The use of deltas is either application (CoOL) specific or YANG to CBOR mapping specific. If it is YANG to CBOR specific, I would encourage the use of another CBOR type that specifies a delta. As specified here its use is ambiguous; and forces each application to specify explicitly what is meant. In the case that the delta is CoOL specific, I recommend to remove it completely from this draft, and explain the use of Deltas in the appropriate CoOL draft. In the latter case: What remains are two key types: number and character string. Last alinea of section 3: “entities generating” should that not be” agents (processes) generating”… “The CoAP content-Format Option …. In the first place.” I don’t understand this phrase. Section 4.2 title: ‘container” Schema Node. Is “CBOR map key” not a better title? As suggested earlier: Reduce this to string (major type 3) and number (major type 0) keys. I think that a large number of the CBOR encoding examples in section 4.2 can be left out. They can be generated any time by an interested implementer; and now confuse the issues. Section 4.4; the example is really complex; some explanation what this all illustrates would be welcome. Why is the use of choice necessary to understand the list encoding? The CBOR encoding can be removed. I suggest to first present the names example followed by the number example. The hash example is really not needed (see above). Section 5: I need more explanation to relate the instance examples to the type definitions. For example section 5.1; does the 1280 come from {mtu: 1280} ? Here we do need the CBOR encoding to see the relation between the type specification and the CBOR encoding. Section 5.2 example illustrates major type 1? Not immediately clear unless you decode the CBOR. Section 5.3; Start phrase got lost 3 lines lower. In the example, where do I find in the CBOR encoding that the fraction is 2 digits? Sections 5.4 - 5.8; see comments on section 5.1 Section 5.9 Here more text is needed to connect the complex YANG specification to “eth1” value. Section 5.10; what is a name-space qualified form? In YANG-JSON it is defined but may need some repetition here. Why is the subject SIDs as identityref* split in two parts? And again I find the CBOR encoding difficult to relate to the definition example. Section 5.11 CBOR diagnostic is: {isrouter: [null]} ? Section 5.13. I don’t understand how this section relates to YANG to CBOR mapping. If the section refers to specifying an instance identifier in the request, I think it can be removed. The use of [key=value] as instance identifier is well explained in restconf draft. The use of numeric identifier is currently described in CoMI draft, and differently in CoOL draft. I propose to remove this section as it does not directly relate to CBOR encoding. However, I am missing how to transport a given list instance with its key values in the CBOR encoding. Section 4.4 describes the encoding of a complete list not a subset of its instances. _____________________________________________________________________________________________ Hope this helps, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org From nobody Tue Jul 5 08:32:24 2016 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 597D212D0AA for ; Tue, 5 Jul 2016 08:32:22 -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 cqhUcs9_EsT9 for ; Tue, 5 Jul 2016 08:32:20 -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 7B88612D0EB for ; Tue, 5 Jul 2016 08:32:20 -0700 (PDT) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id CFF081720B4 for ; Tue, 5 Jul 2016 17:32:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 6z0-dOfZtBNV for ; Tue, 5 Jul 2016 17:32:16 +0200 (CEST) X-Originating-IP: 193.54.23.146 Received: from [10.138.197.159] (unknown [193.54.23.146]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D25FC1720B3 for ; Tue, 5 Jul 2016 17:32:16 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Tue, 5 Jul 2016 17:32:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18B7A2A3-C44F-493D-AFFF-1A98EB6C26AA@ackl.io> References: <4CBCFA76-6E62-4B92-A615-F65ADCC61524@ericsson.com> To: "core@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [core] IETF96 Agenda items preparation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 15:32:22 -0000 Dear WG chairs, With the Berlin meeting rapidly approaching, we=92d like to request four = slots to present the CoOL/CoMI work. These slots include: 1) 5 min: Document roadmap (what to expect, when to expect it, and why) 2) 10-15 min: YANG-CBOR mapping (draft-ietf-core-yang-cbor) - = advancement on this WG item (closed tickets, issues) 3) 10 min: Structured Identifiers (SID - draft-somaraju-core-sid) - = concept, use and call for adoption of the WG 4) 10 min: Constrained Objects Language (draft-veillette-core-cool) - = basic operation set, open questions of interest - notifications, use of = RESTful paradigm Any feedback would be greatly appreciated.=20 Best, Alexander From nobody Wed Jul 6 04:55:54 2016 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 E896D12D769; Wed, 6 Jul 2016 04:55:52 -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 8u_ssOQeE9VF; Wed, 6 Jul 2016 04:55:50 -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 44E0312D768; Wed, 6 Jul 2016 04:55:50 -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 6C8931720D6; Wed, 6 Jul 2016 13:55:48 +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 4hOQNFqjIAeh; Wed, 6 Jul 2016 13:55:46 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 7CB171720CE; Wed, 6 Jul 2016 13:55:44 +0200 (CEST) Message-ID: <577CF1BD.9050201@tzi.org> Date: Wed, 06 Jul 2016 13:55:41 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core-chairs@ietf.org Subject: [core] CoRE agenda @ietf96 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jul 2016 11:55:53 -0000 Jaime and I have started preparing a draft agenda for the CoRE meetings in Berlin. https://github.com/core-wg/ietf96/wiki (Please ignore for now the weird formatting issues github creates...) Those of you who put in a slot request: Please check that it is covered by this draft agenda. We haven't written down the slot leaders ("presenters") everywhere, so if you think you will be holding the microphone, please let Jaime and me know (core-chairs@ietf.org). Please also check the objectives: Is this a reasonable summary of what we are trying to achieve? Anything else we are missing? Grüße, Carsten From nobody Wed Jul 6 10:16:24 2016 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 6F34D12D0AA; Wed, 6 Jul 2016 10:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A85KhX2lP--L; Wed, 6 Jul 2016 10:16:14 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 10DE512D146; Wed, 6 Jul 2016 10:16:14 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s66so279445448oif.1; Wed, 06 Jul 2016 10:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KHjutuNvjHw5z0c1yZe/L7TPPz5OXj3GqChOVDVsIYM=; b=PbCfk9+PiGVGKKTh48qdL+Ill05grolUT+GQgtxPbLzLEL04QGfLj2AfEDq+pElnX0 8/8DA2dUEsiPERgkHQTvQDTu7ilXOhsZF3RqN4t1h2muQIAd0bqGpa1tsH9NAPnqvKnf qKcDK17IE22xO+4WDaEWkxn0Um2K5+oltXk/KcSZ6ZQMPor4kXn6gQqxNBbSfamzRa/d gguX61iruVfOIkJlyDKUEivxw4ZTYiFZoCQR0IxnZNjsXZSlTw/PndlHLy+KBt/8oKBt nNcBfIg04T6L24pX6mbY4M06VMkSNUCZSWnoFmHZ8Tan/efY3HHnvT+l889yt3CeTt30 PHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KHjutuNvjHw5z0c1yZe/L7TPPz5OXj3GqChOVDVsIYM=; b=bbYiyour2oVi3GNH0PNx8R/B2Snl+0S32jHq1Jx1kZfNyiYJQST6sASvyN5EkKEOue nqt6y0JiEUZMs+wwj/RM8Wt4VBTpV9zP+le7IP+4ujhaCv4K9zNoBEdTFYewgTo/O/lE +U+V1fksU0tBqS/65VkaNBWaaKK3DOkmlrPeRCma/8TrT63g3Zvjv6h8t4xlgM008XXn oHZItkG83d2Ztq6vMT2BQjp60OqkIBEpTbHckwBQTMnpggyGSrFQrGJa+EmwSFqYM1DV mGlwStrF+a8WDc7cDqvFqRcSzro4KOeU20iR0R2IPdcptg2Wt9/SCmai3H4LEyVlcu4M KOKQ== X-Gm-Message-State: ALyK8tIjQb/6+698TS8zC5NzQ+TPG2gHxEdwd3hajeKMz46WjzIyc8MvvzbrO4KA+7cnXZAwZ9bA1DKoemjCfg== X-Received: by 10.157.9.41 with SMTP id 38mr13923978otp.190.1467825373378; Wed, 06 Jul 2016 10:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.49.194 with HTTP; Wed, 6 Jul 2016 10:16:12 -0700 (PDT) In-Reply-To: <577CF1BD.9050201@tzi.org> References: <577CF1BD.9050201@tzi.org> From: Pascal Urien Date: Wed, 6 Jul 2016 19:16:12 +0200 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=94eb2c045bf2f9002d0536fab90b Archived-At: Cc: core-chairs@ietf.org, "core@ietf.org WG" Subject: Re: [core] CoRE agenda @ietf96 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jul 2016 17:16:16 -0000 --94eb2c045bf2f9002d0536fab90b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Chair According to https://github.com/core-wg/ietf96/wiki the document "draft-urien-core-identity-module-coap-00" is "apparently out of scope" The document "draft-urien-core-identity-module-coap-00" is a draft proposal for the (optional) support of an identity module by the CoAP protocol. According to rfc7252 "The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks" In the draft-urien-core-identity-module-coap-00 we suggest to use ISO7816 compatible devices, based on secure microcontrollers. One advantage of this approach is to design an interface with well defined encoding rules According to the rfc 7252 " Just as HTTP is secured using Transport Layer Security (TLS) over TCP, CoAP is secured using Datagram TLS (DTLS) [RFC6347] over UDP" Although not mandatory (DTLS may be disabled), DTLS may use PreSharedKey, RawPublicKey or Certificate. So the rfc 7252, in a way or another, suggests that DTLS is used as identity stack. The draft draft-urien-core-identity-module-coap-00 proposes the definition of an ISO7816 interface to DTLS/TLS stacks running in secure microcontrollers. If CoAP targets billion devices in M2M networks, then trust could be part of the WG scope, at least as recommendation. The WikiLeaks documents demonstrated that trust in networks can be an issue= . Rgs 2016-07-06 13:55 GMT+02:00 Carsten Bormann : > Jaime and I have started preparing a draft agenda for the CoRE meetings > in Berlin. > > https://github.com/core-wg/ietf96/wiki > > (Please ignore for now the weird formatting issues github creates...) > > Those of you who put in a slot request: > Please check that it is covered by this draft agenda. > > We haven't written down the slot leaders ("presenters") everywhere, so > if you think you will be holding the microphone, please let Jaime and me > know (core-chairs@ietf.org). > > Please also check the objectives: Is this a reasonable summary of what > we are trying to achieve? > > Anything else we are missing? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --94eb2c045bf2f9002d0536fab90b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Chair

=C2=A0

According to https://github.com/core-wg/ietf96/wiki the document "draft-urien-core-identity-module-coap-00" is "= apparently out of scope"

=C2=A0

The document "draft-urien-= core-identity-module-coap-00" is a draft proposal for the (optional) support of an identity module by the= CoAP protocol.

=C2=A0

According to rfc7252 "The = work on Constrained RESTful Environments (CoRE) aims at realizing the REST architec= ture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrol= lers with limited RAM and ROM) and networks"

=C2=A0

In the draft-urien-core-identit= y-module-coap-00 we suggest to use ISO7816 compatible devices, based on secure microcontroll= ers. One advantage of this approach is to design an interface with well defined = encoding rules

=C2=A0

According to the rfc 7252 "= ; Just as HTTP is secured using Transport Layer Security (TLS) over TCP, CoAP is secu= red using Datagram TLS (DTLS) [RFC6347] over UDP"

=C2=A0

Although not mandatory (DTLS ma= y be disabled), DTLS may use PreSharedKey, RawPublicKey or Certificate. <= /p>

=C2=A0

So the rfc 7252, in a way or an= other, suggests that DTLS is used as identity stack.

=C2=A0

The draft draft-urien-core-iden= tity-module-coap-00 proposes the definition of an ISO7816 interface to DTLS/TLS stacks running = in secure microcontrollers.

=C2=A0

If CoAP targets billion devices= in M2M networks, then trust could be part of the WG scope, at least as recommendat= ion.

=C2=A0

The WikiLeaks documents demonst= rated that trust in networks can be an issue.

=C2=A0

Rgs


2016-07-06 13:55 GMT+02:00 = Carsten Bormann <cabo@tzi.org>:
Jaime and I have started preparing a draft agenda for the CoRE meetings in Berlin.

https://github.com/core-wg/ietf96/wiki

(Please ignore for now the weird formatting issues github creates...)

Those of you who put in a slot request:
Please check that it is covered by this draft agenda.

We haven't written down the slot leaders ("presenters") every= where, so
if you think you will be holding the microphone, please let Jaime and me know (core-chairs@ietf.org).
Please also check the objectives: Is this a reasonable summary of what
we are trying to achieve?

Anything else we are missing?

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

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

--94eb2c045bf2f9002d0536fab90b-- From nobody Wed Jul 6 19:24:13 2016 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 1F0F812D1D1 for ; Wed, 6 Jul 2016 19:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq1RtlIroSIa for ; Wed, 6 Jul 2016 19:24:10 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BE3126579 for ; Wed, 6 Jul 2016 19:24:09 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id h14so1639536pfe.1 for ; Wed, 06 Jul 2016 19:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=UeybYTFnQjJC5cyAbPK4aPJjTSxfNjswaNeHK/DRxsY=; b=CLSCLLOrk3ZMysnS1AwSFnkhnwZBgJpIg8q3oTc+QFLfB6yo9C2I/NKuIPhU2e0SRZ TTNb5TwWdx1st1edhdPDtMj5JwnfcKRstyZQ54vKDmQclDJ9KMfA7zYCEzHtxoLpNPMr WnGIYz1a6Kx6vgU1FKTOSBSqcYapcRcJEXp2gEAgB5Ua4ByGMgHU8NV4XWIVvEH7BGez iAZyGvvuxJoL7KGMZ4qfZi0H7ecPxczlSdrwIQyEbBSOxiE2ddQA2vQEd8ibQflGO9EB jmAqsB7wa5U6hBnEBQu9bBPntYz+Pe/sLJwV4kRoHckSeviDQqYj7N255KpjY+lAC165 ME0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=UeybYTFnQjJC5cyAbPK4aPJjTSxfNjswaNeHK/DRxsY=; b=cOqjAmPx0ZhEwpG2ibKAFoLJJ2OEHQQTg8UNocU62UKW7dH4hksRxV6GckX2qxJumG G49VSQxfxYQhhlxtzqMJCFR+askUbh2AmNIlGQfdPGb3qFTDgCx81A9eU/KIcBjmRq0G A+Ufw4OXdxaROd/rhFvrsAlKxp4/fqLzoBx6152z3mcN2LyvxSHa6VJXO0YGY2MkORa9 /J/H6nTKmVU2l1kvkHNWNVXmbhbJAfXcxDtw/1nSxGpffl3HlknE5jhEp6hB/hpHIgn4 KG0blyIr/5F7AOLNS1qP/cyMdnwfYIo4GZdDGDLG8FeQrRdlb1UH4YYPumg20y5GCFkf b7kA== X-Gm-Message-State: ALyK8tKBRYGOCC+maoBR/Z2wZNwx0QJkcxSJgcaCMgn+vhZCA+2F0hkGlNuMpjOdwuxGSg== X-Received: by 10.98.76.211 with SMTP id e80mr970840pfj.28.1467858248028; Wed, 06 Jul 2016 19:24:08 -0700 (PDT) Received: from ThanhDinhPC ([220.70.2.22]) by smtp.gmail.com with ESMTPSA id tm1sm6395245pac.23.2016.07.06.19.24.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 19:24:06 -0700 (PDT) From: "William" To: "'Pascal Urien'" , References: <577CF1BD.9050201@tzi.org> In-Reply-To: Date: Thu, 7 Jul 2016 11:24:02 +0900 Message-ID: <001101d1d7f6$a2737fa0$e75a7ee0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D1D842.125D7190" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKrTtzCs29CF33g1u36qBEo0XPg+AKOJZK1nkTbfFA= Content-Language: en-us Archived-At: Subject: Re: [core] CoRE agenda @ietf96 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 02:24:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0012_01D1D842.125D7190 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Dr. Bormann that trust could be taken into consideration = for scope the WG.=20 It is quite important when we have a large and global M2M networks. Looking forward to see our WG discussion on trust and identity module. =20 Many thanks, William PhD of Research IoT based Smart Furniture for Smart Home = Research Group =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Pascal Urien Sent: Thursday, July 07, 2016 2:16 AM To: Carsten Bormann Cc: core-chairs@ietf.org; core@ietf.org WG Subject: Re: [core] CoRE agenda @ietf96 =20 Dear Chair =20 According to https://github.com/core-wg/ietf96/wiki the document = "draft-urien-core-identity-module-coap-00" is "apparently out of scope" =20 The document "draft-urien-core-identity-module-coap-00" is a draft = proposal for the (optional) support of an identity module by the CoAP = protocol. =20 According to rfc7252 "The work on Constrained RESTful Environments = (CoRE) aims at realizing the REST architecture in a suitable form for = the most constrained nodes (e.g., 8-bit microcontrollers with limited = RAM and ROM) and networks" =20 In the draft-urien-core-identity-module-coap-00 we suggest to use = ISO7816 compatible devices, based on secure microcontrollers. One = advantage of this approach is to design an interface with well defined = encoding rules =20 According to the rfc 7252 " Just as HTTP is secured using Transport = Layer Security (TLS) over TCP, CoAP is secured using Datagram TLS (DTLS) = [RFC6347] over UDP" =20 Although not mandatory (DTLS may be disabled), DTLS may use = PreSharedKey, RawPublicKey or Certificate.=20 =20 So the rfc 7252, in a way or another, suggests that DTLS is used as = identity stack. =20 The draft draft-urien-core-identity-module-coap-00 proposes the = definition of an ISO7816 interface to DTLS/TLS stacks running in secure = microcontrollers. =20 If CoAP targets billion devices in M2M networks, then trust could be = part of the WG scope, at least as recommendation.=20 =20 The WikiLeaks documents demonstrated that trust in networks can be an = issue. =20 Rgs =20 2016-07-06 13:55 GMT+02:00 Carsten Bormann >: Jaime and I have started preparing a draft agenda for the CoRE meetings in Berlin. https://github.com/core-wg/ietf96/wiki (Please ignore for now the weird formatting issues github creates...) Those of you who put in a slot request: Please check that it is covered by this draft agenda. We haven't written down the slot leaders ("presenters") everywhere, so if you think you will be holding the microphone, please let Jaime and me know (core-chairs@ietf.org ). Please also check the objectives: Is this a reasonable summary of what we are trying to achieve? Anything else we are missing? Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core =20 ------=_NextPart_000_0012_01D1D842.125D7190 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I agree = with Dr. Bormann that trust could be taken into consideration for scope = the WG.

It is quite important when = we have a large and global M2M networks.

Looking forward to see our WG discussion on trust and = identity module.

 

Many = thanks,

William

PhD of Research

IoT = based Smart Furniture for Smart = Home Research Group

 

 

From: core = [mailto:core-bounces@ietf.org] On Behalf Of Pascal = Urien
Sent: Thursday, July 07, 2016 2:16 AM
To: = Carsten Bormann
Cc: core-chairs@ietf.org; core@ietf.org = WG
Subject: Re: [core] CoRE agenda = @ietf96

 

Dear = Chair

 <= /o:p>

According = to https://github.com/core-w= g/ietf96/wiki the document = "draft-urien-core-identity-module-coap-00" is "apparently = out of scope"

 <= /o:p>

The = document "draft-urien-core-identity-module-coap-00" is a draft = proposal for the (optional) support of an identity module by the CoAP = protocol.

 <= /o:p>

According = to rfc7252 "The work on Constrained RESTful Environments (CoRE) = aims at realizing the REST architecture in a suitable form for the most = constrained nodes (e.g., 8-bit microcontrollers with limited RAM and = ROM) and networks"

 <= /o:p>

In the = draft-urien-core-identity-module-coap-00 we suggest to use ISO7816 = compatible devices, based on secure microcontrollers. One advantage of = this approach is to design an interface with well defined encoding = rules

 <= /o:p>

According = to the rfc 7252 " Just as HTTP is secured using Transport Layer = Security (TLS) over TCP, CoAP is secured using Datagram TLS (DTLS) = [RFC6347] over UDP"

 <= /o:p>

Although = not mandatory (DTLS may be disabled), DTLS may use PreSharedKey, = RawPublicKey or Certificate.

 <= /o:p>

So the rfc = 7252, in a way or another, suggests that DTLS is used as identity = stack.

 <= /o:p>

The draft = draft-urien-core-identity-module-coap-00 proposes the definition of an = ISO7816 interface to DTLS/TLS stacks running in secure = microcontrollers.

 <= /o:p>

If CoAP = targets billion devices in M2M networks, then trust could be part of the = WG scope, at least as recommendation.

 <= /o:p>

The = WikiLeaks documents demonstrated that trust in networks can be an = issue.

 <= /o:p>

Rgs

 

2016-07-06 13:55 GMT+02:00 Carsten Bormann <cabo@tzi.org>:

Jaime and = I have started preparing a draft agenda for the CoRE meetings
in = Berlin.

https://github.com/core-wg/ietf96/wiki

(Plea= se ignore for now the weird formatting issues github = creates...)

Those of you who put in a slot request:
Please = check that it is covered by this draft agenda.

We haven't written = down the slot leaders ("presenters") everywhere, so
if you = think you will be holding the microphone, please let Jaime and = me
know (core-chairs@ietf.org).

Pl= ease also check the objectives: Is this a reasonable summary of = what
we are trying to achieve?

Anything else we are = missing?

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

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

 

------=_NextPart_000_0012_01D1D842.125D7190-- From nobody Thu Jul 7 14:16:25 2016 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 53DD912D532 for ; Thu, 7 Jul 2016 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUs0rtIsi9N4 for ; Thu, 7 Jul 2016 14:16:22 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 890CD12D0CD for ; Thu, 7 Jul 2016 14:16:22 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id uj8so9103369pab.3 for ; Thu, 07 Jul 2016 14:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UcWyqiWqVQc4hwbSvNKaIHXfTUXIsQgMpM8nC8t5mII=; b=nFWvklgML75kLmj+A+IdFY21cC+fcKai2PVfI6s53+dEO9RVQLZcSRuBcarc4He106 XH3a7j16R6CrEwpgtQBIwdJxBiZmKXvH5A3yWxVNX+BuJgQpcI1GNjJ8rVd7lPMFuj+c 7z2U98uYFDSjf8/3Z9PfDk1d2DTNKSiSMR9GULy5UQaWxo8UiynB/bVmsdD8HI9U4/Kx 5JpobvSmmhahHe0o1SLP08+E4sUdhpd5A4j29B6/RZDAEmB70NgWqaR2smBPGgZCQaBQ Avq9weGKONq16vELIK9vVi4mCnc+iw9oy1bwIwsraNegdXsBllyhgyrr9TxrYUUN9GZW 2CTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UcWyqiWqVQc4hwbSvNKaIHXfTUXIsQgMpM8nC8t5mII=; b=bvH7vUF3Etw6gyIUiK6tsXc4PNCR0ujYEpEbJH+Pa15QoGUGjrgegsAxuGrIOsBnqN fj84nc4S5kYThWccVNLssJ0N2OnEeJ2/YCwN8ITCPlAK8vac5TiGlmCAVPBtl1Tvl+mM c0DooSk8GcndlsFZA4jwzEe6wfMejK61AiKLQaeqcEMaCyjxFK3Qq/EETTCITXyAaf5m f2aIlxR8GiozX6UBhQXC00KXFmaPC52HBoGgejpjCeWbGDgpR6ZRM7xknxbY6u31xylM gQxzhE+CyNFJujaY95EaJitghYwE0S267Q10OEYNBrO1w3TZVXaiKKwJ/Vk/16lNEakC tpMg== X-Gm-Message-State: ALyK8tI6jhiQlhPGq1SDp8JU4CpnvkgrFQYzd3Ii8BaYY4BZC2cFDng+K+FJn8gE3OPV3A== X-Received: by 10.66.236.133 with SMTP id uu5mr3779225pac.35.1467926182074; Thu, 07 Jul 2016 14:16:22 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id r143sm6108615pfr.48.2016.07.07.14.16.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 14:16:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3FAF2032-B1CE-4A3D-976D-3876848F5744" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <575C3AC4.9050407@tzi.org> Date: Thu, 7 Jul 2016 14:16:17 -0700 Message-Id: <44F8B98A-507F-4314-93CF-D8DD3FDADB87@gmail.com> References: <575C3AC4.9050407@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource directory evolution X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 21:16:24 -0000 --Apple-Mail=_3FAF2032-B1CE-4A3D-976D-3876848F5744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Carsten, > On Jun 11, 2016, at 9:22 AM, Carsten Bormann wrote: >=20 > * We need to link the resources implicitly included in the current > function sets (can be done in .well-known/core) > * We need to annotate how to formulate the requests to these resources > (can be done with rt=3D for now, backed by the textual descriptions = we > have in the RD specification) > * We need to allow for additional lookup interfaces (can be done > through additional rt=3D registrations, backed by the specifications > referenced) > * The registration interface would not change much, just support > additional media types (containing collections of links, which > need to be made available in link-format style to those consumers > not familiar with the media type) What we have now is similar to your description -------------------- Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40; ct=3D21225 ;rt=3D"core.rd-lookup";ct=3D40; ct=3D21225 ;rt=3D"core.rd-group";ct=3D40; ct=3D21225 ---------------------- We have links to function sets in .well-known/core that use rt=3D to = identify the function sets using IANA registered resource types We also have content-format hints in the links (I added a second ct to = illustrate) I will add something requiring ct=3D40 as a mandatory format, and noting = that any other format registered must have an equivalent link-format = representation Is there anything you can think of to add at this point? Best regards, Michael --Apple-Mail=_3FAF2032-B1CE-4A3D-976D-3876848F5744 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Carsten,

On Jun 11, 2016, at 9:22 AM, = Carsten Bormann <cabo@tzi.org> wrote:

* We need to link the resources implicitly = included in the current
 function sets (can = be done in .well-known/core)
* We need to annotate how = to formulate the requests to these resources
 (can be done with rt=3D for now, backed by = the textual descriptions we
 have in the RD = specification)
* We need to allow for = additional lookup interfaces (can be done
 through additional rt=3D registrations, = backed by the specifications
 referenced)
* The registration interface would not change = much, just support
 additional media = types (containing collections of links, which
 need to be made available in link-format = style to those consumers
 not familiar with = the media type)

What we have now is similar to your description

--------------------
   Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd*

   Res: 2.05 = Content
  =  </rd>;rt=3D"core.rd";ct=3D40; ct=3D21225
   </rd-lookup>;rt=3D"core.rd-lookup";ct=3D40; = ct=3D21225
  =  </rd-group>;rt=3D"core.rd-group";ct=3D40; = ct=3D21225
----------------------

We have links to function sets in = .well-known/core that use rt=3D to identify the function sets using IANA = registered resource types

We also have content-format hints in the links  (I added = a second ct to illustrate)

I will add something requiring ct=3D40 as a mandatory format, = and noting that any other format registered must have an equivalent = link-format representation

Is there anything you can think of to add at this = point?

Best = regards,

Michael

= --Apple-Mail=_3FAF2032-B1CE-4A3D-976D-3876848F5744-- From nobody Thu Jul 7 14:20:50 2016 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 A65D612D5AD for ; Thu, 7 Jul 2016 14:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdU1IoG3vwO7 for ; Thu, 7 Jul 2016 14:20:46 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 D0D9812D532 for ; Thu, 7 Jul 2016 14:20:46 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id b13so9164657pat.0 for ; Thu, 07 Jul 2016 14:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gPIEmyKNc9Xff6EfrnC+P9hzeIzTlYajLF+JKqhMvP0=; b=Y8GWek8dz0mOiMXt5U5hWVAj5P69+DYD6mf+XUVEDr+RgeqW0H9gOrbEf//seLO5c/ 1uU/wapwJPFCpY68OpkoOspwFarBi0CMFADNL5by+HpsBw4ZBk4tEHiKLietIC5bY5WT XYq88raikB61morBE7SpKfZpuqnPgKPPboIZVqopipPhKb4ejli0U2pzVU/SY6wxYO1q EKvqcPyOAjpFIAY7rOk2qAkns+FVyZ+PSQNTSBm3DklSy0HhnbQyhE1seU9w0ZljUH2M eNqa9F5CmSOBs//djZQnVt/sqcsR4l7S4wqCg8sEgp1lWSVcfrHnSpZ3TDTT4S70yn+M Imrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gPIEmyKNc9Xff6EfrnC+P9hzeIzTlYajLF+JKqhMvP0=; b=bLMjCojWIHeSLYX6Gg+b6Vkv5kLi2/2QDF9VWFJsnYSFRj3VoTKXmeNpBtoo922X7z UXgX4ssW7a3h+47NNPYsym6Un6A/qTxl+m9uNioQaiWDs03byT2FHDLVmMJJGvnVhI0U KDUu6vkcIvjXBBQhyDTv3rBEtJjwqI8RwMo07MVV1zU4kz9LQbvQQGXi3Yu7jlgwS0Il yRtj92DlgOtpdJwWfNL5y8a8xRiLo1CX0b6zBRmIfYoEWN9BDHyrUSeHK/IdKOKwicid qBz0jgDyZ0nKuihtCLYV6nkQRbDdJsLgJc/iGWiBSvBm7EexAtSjLBa491BHINjjjfSz kdMw== X-Gm-Message-State: ALyK8tLj/6ucyeI5CcdnyZlCw8RNbI1k0DNcYomsEuLmrGiPdwU5Rjn8SlguZhoetChKAg== X-Received: by 10.66.255.7 with SMTP id am7mr3861647pad.75.1467926446333; Thu, 07 Jul 2016 14:20:46 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id f138sm6396229pfa.17.2016.07.07.14.20.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 14:20:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B314EC5-DBA6-4E12-A64C-D48933B6D014" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <44F8B98A-507F-4314-93CF-D8DD3FDADB87@gmail.com> Date: Thu, 7 Jul 2016 14:20:44 -0700 Message-Id: <5E21D94A-1FC7-4889-8862-09A80379F2DE@gmail.com> References: <575C3AC4.9050407@tzi.org> <44F8B98A-507F-4314-93CF-D8DD3FDADB87@gmail.com> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource directory evolution X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 21:20:48 -0000 --Apple-Mail=_2B314EC5-DBA6-4E12-A64C-D48933B6D014 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think the representation should look more like: Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 60", ;rt=3D"core.rd-lookup";ct=3D"40 50", ;rt=3D"core.rd-group";ct=3D"40 50" which is in the document. I'll change the second format to something = different. MIchael > On Jul 7, 2016, at 2:16 PM, Michael Koster = wrote: >=20 > Hi Carsten, >=20 >> On Jun 11, 2016, at 9:22 AM, Carsten Bormann > wrote: >>=20 >> * We need to link the resources implicitly included in the current >> function sets (can be done in .well-known/core) >> * We need to annotate how to formulate the requests to these = resources >> (can be done with rt=3D for now, backed by the textual descriptions = we >> have in the RD specification) >> * We need to allow for additional lookup interfaces (can be done >> through additional rt=3D registrations, backed by the specifications >> referenced) >> * The registration interface would not change much, just support >> additional media types (containing collections of links, which >> need to be made available in link-format style to those consumers >> not familiar with the media type) >=20 > What we have now is similar to your description >=20 > -------------------- > Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* = >=20 > Res: 2.05 Content > ;rt=3D"core.rd";ct=3D40; ct=3D21225 > ;rt=3D"core.rd-lookup";ct=3D40; ct=3D21225 > ;rt=3D"core.rd-group";ct=3D40; ct=3D21225 > ---------------------- >=20 > We have links to function sets in .well-known/core that use rt=3D to = identify the function sets using IANA registered resource types >=20 > We also have content-format hints in the links (I added a second ct = to illustrate) >=20 > I will add something requiring ct=3D40 as a mandatory format, and = noting that any other format registered must have an equivalent = link-format representation >=20 > Is there anything you can think of to add at this point? >=20 > Best regards, >=20 > Michael >=20 --Apple-Mail=_2B314EC5-DBA6-4E12-A64C-D48933B6D014 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think the representation should look more like:

  =  Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd*

   Res: 2.05 = Content
  =  </rd>;rt=3D"core.rd";ct=3D"40 60",
 =  </rd-lookup>;rt=3D"core.rd-lookup";ct=3D"40 50",
   </rd-group>;rt=3D"core.rd-group";ct=3D"40 = 50"

which is = in the document. I'll change the second format to something = different.

MIchael

On Jul 7, 2016, at 2:16 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi = Carsten,

On Jun 11, 2016, at 9:22 AM, = Carsten Bormann <cabo@tzi.org> wrote:

* We need to link the resources implicitly = included in the current
 function sets (can = be done in .well-known/core)
* We need to annotate how = to formulate the requests to these resources
 (can be done with rt=3D for now, backed by = the textual descriptions we
 have in the RD = specification)
* We need to allow for = additional lookup interfaces (can be done
 through additional rt=3D registrations, = backed by the specifications
 referenced)
* The registration interface would not change = much, just support
 additional media = types (containing collections of links, which
 need to be made available in link-format = style to those consumers
 not familiar with = the media type)

What we have now is similar to your description

--------------------
   Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd*

   Res: 2.05 = Content
  =  </rd>;rt=3D"core.rd";ct=3D40; ct=3D21225
   </rd-lookup>;rt=3D"core.rd-lookup";ct=3D40; = ct=3D21225
  =  </rd-group>;rt=3D"core.rd-group";ct=3D40; = ct=3D21225
----------------------

We have links to function sets in = .well-known/core that use rt=3D to identify the function sets using IANA = registered resource types

We also have content-format hints in the links  (I added = a second ct to illustrate)

I will add something requiring ct=3D40 as a mandatory format, = and noting that any other format registered must have an equivalent = link-format representation

Is there anything you can think of to add at this = point?

Best = regards,

Michael


= --Apple-Mail=_2B314EC5-DBA6-4E12-A64C-D48933B6D014-- From nobody Thu Jul 7 15:54:20 2016 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 A947C12D67B for ; Thu, 7 Jul 2016 15:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_NEUTRAL=0.779] autolearn=ham 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 YALbE6_0lBes for ; Thu, 7 Jul 2016 15:54:17 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 3CAFA127071 for ; Thu, 7 Jul 2016 15:54:17 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id uj8so9697924pab.3 for ; Thu, 07 Jul 2016 15:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=EtVTz7oFDPu+U/QgfBe1kgvHvoF3ihbslU8R+0bwlFc=; b=JD5LyKbsQ5yzk14yDFkPlbK10u4bFhYvvVeCyjGJzwnzOrNlCMKEgRFscSEbW94ySt svO6jnLhL+4AvgYi0G4l3f+VyzI6gYBaMSwoMalUJlyyVA5TerjEBrqTq6pRFWBKAtj8 8lIE4GAQGYSGxiG7AuOaVthVbE4tos/nB6E1RDDBWtCG7LFHI61pLf2gIPEMm4YRyqzf ar0bdo6NUo68+Jfzv8Ob4vtC5s2J2JlFSWyJHzYzDaFpAXCyrrHik1Me5OmDbQA8o8o5 l6uugwHDoD9tUwinSTG3Ol305pH+miMu8DymDXAI6ZuFDYlqjj0DKb8hVTMKIy4wmMLb wHDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EtVTz7oFDPu+U/QgfBe1kgvHvoF3ihbslU8R+0bwlFc=; b=Y2fNnusqM+j8M4B2GrrAjxIS006pwa0vZxjk61hMztFo3uyvoOgeM8KzeHFWohzvnh 0ZwXQllGQ5o3bKfFTGTwcBjqIsFXGflc6Wn3tRotBN0Q5u8NBCgNnDNMgE2t34ixvHyc 0JZ6PblRVjWWxgAdWZ3xRVqoKLrw6jhG0qUnhD1r2HSudUsEp67ra60GlRTmCnrCS8vy 69Btd1jhfhRpCVG/UDnMMOdnasjDjFW1azSs/6FmnA258efJs6rFmKzjczrUY34qoVaa eupyO9nUp2AOzDtA7+tzpaRtswuKISlckgfAshbaTCcL8IHtIGGV2DsBmBNzhLbegtt4 1qIQ== X-Gm-Message-State: ALyK8tKgSc2zLE7jPYEApPKDAYs2I52btTix/Z0eyYEUMDO61ueqmHnmVpbMDrk26jD7dHx1 X-Received: by 10.66.161.73 with SMTP id xq9mr4451417pab.6.1467932056635; Thu, 07 Jul 2016 15:54:16 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id x68sm6586367pfb.88.2016.07.07.15.54.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 15:54:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4856301F-F7CF-4EBA-AA1D-157CD80CE8E9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> Date: Thu, 7 Jul 2016 15:54:09 -0700 Message-Id: References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> To: "draft-ietf-core-resource-directory@tools.ietf.org" , "core@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Oscar Novo , Hannes Tschofenig Subject: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 22:54:18 -0000 --Apple-Mail=_4856301F-F7CF-4EBA-AA1D-157CD80CE8E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have uploaded an updated RD draft to the core SVN repository, with = what I believe are all of the outstanding changes and comments. draft-ietf-core-resource-directory-xx.mkd draft-ietf-core-resource-directory-xx.xml draft-ietf-core-resource-directory-xx.txt The changelog describes the significant changes. I will submit this as version -08 tomorrow if there are no urgent = changes to make. Best regards, Michael= --Apple-Mail=_4856301F-F7CF-4EBA-AA1D-157CD80CE8E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I have uploaded an = updated RD draft to the core SVN repository, with what I believe are all = of the outstanding changes and comments.

draft-ietf-core-resource-directory-xx.mkd
draft-ietf-core-resource-directory-xx.xml
draft-ietf-core-resource-directory-xx.txt
The changelog describes the = significant changes.

I will submit this as version -08 tomorrow if there are no = urgent changes to make.

Best regards,

Michael
= --Apple-Mail=_4856301F-F7CF-4EBA-AA1D-157CD80CE8E9-- From nobody Thu Jul 7 18:55:03 2016 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 739AA12B022 for ; Thu, 7 Jul 2016 18:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 pVXM1SrIJYf8 for ; Thu, 7 Jul 2016 18:54:59 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3768B127078 for ; Thu, 7 Jul 2016 18:54:58 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 8 Jul 2016 03:54:49 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0301.000; Fri, 8 Jul 2016 03:54:56 +0200 From: "Kovatsch Matthias" To: Michael Koster , "draft-ietf-core-resource-directory@tools.ietf.org" , "core@ietf.org" Thread-Topic: CoRE RD update in SVN repository Thread-Index: AQHR2KJ/CrzUZclTrUKTU4/43KB1e6ANu7cq Date: Fri, 8 Jul 2016 01:54:55 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net>, In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.35.17.16] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B551DB4D46MBX110dethzch_" MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , Oscar Novo Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 01:55:02 -0000 --_000_55877B3AFB359744BA0F2140E36F52B551DB4D46MBX110dethzch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Michael I did a quick review of the draft. I know you are quite swamped, but maybe = we can get some updates in before publishing: 4.1. Resource Directory Address Option (RDAO) I am quite lost of the context here. There is only a quick hint in the bull= et point list in Section 4---best add parentheses and "see ..." there. Othe= rwise it is unclear what kind of option you are talking about. It is the only location where "6LR" is used without explanation. Furthermor= e, the endpoint could also be a 6LoWPAN host instead of a router... Why is the length always 3? Is that right? (I haven't read the ND spec...) 5. Simple Directory Discovery This is still called "Discovery" although it is "Simple Registration". It says "IP addresses of the directory server". I would change this to simp= ly "addresses of the", since the endpoint also needs a port. The example la= ter also shows a DNS name instead of IP literal. 5.2. Third-party registration The section mentions the Context parameter without reference to its definit= ion. 6.2. Discovery This appears to be a repetition (with some additional information) of Secti= on 4. Finding a Directory Server. I would integrate this into Section 4. 6.2. also uses the Content-Format ID 21225 without explaining what it is... 6.6. Read Endpoint Links Is there any functionality that is not provided through the lookup interfac= e (apart from a quicker ep selection)? As part of the RD evolution, a GET on the handle resource should primarily = return the forms to update and delete the registration. Forms that are pre-= filled with the endpoint information could enable a nice collection-based l= ookup for management. 6.7. Update Endpoint Links Shouldn't this be merged with Section 6.4. Registration Update? Best regards Matthias ________________________________ From: Michael Koster [michael.koster@smartthings.com] Sent: Friday, July 08, 2016 12:54 AM To: draft-ietf-core-resource-directory@tools.ietf.org; core@ietf.org Cc: consultancy@vanderstok.org; Kovatsch Matthias; Hannes Tschofenig; Oscar= Novo; Zach Shelby; Carsten Bormann Subject: CoRE RD update in SVN repository I have uploaded an updated RD draft to the core SVN repository, with what I= believe are all of the outstanding changes and comments. draft-ietf-core-resource-directory-xx.mkd draft-ietf-core-resource-directory-xx.xml draft-ietf-core-resource-directory-xx.txt The changelog describes the significant changes. I will submit this as version -08 tomorrow if there are no urgent changes t= o make. Best regards, Michael --_000_55877B3AFB359744BA0F2140E36F52B551DB4D46MBX110dethzch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Michael

I did a quick review of the draft. I know you are quite swamped, but maybe = we can get some updates in before publishing:
4.1.  Resource Directory Address Option (RDAO)
I am quite lost of the context here. There is only a quick hint in the bull= et point list in Section 4---best add parentheses and "see ..." t= here. Otherwise it is unclear what kind of option you are talking about.
It is the only location where "6LR" is used without explanation. = Furthermore, the endpoint could also be a 6LoWPAN host instead of a router.= ..

Why is the length always 3? Is that right? (I haven't read the ND spec...)<= br> 
5.  Simple Directory Discovery
This is still called "Discovery" although it is "Simple Regi= stration".

It says "IP addresses of the directory server". I would change th= is to simply "addresses of the", since the endpoint also needs a = port. The example later also shows a DNS name instead of IP literal.

5.2.  Third-party registration
The section mentions the Context parameter without reference to its definit= ion.

6.2.  Discovery
This appears to be a repetition (with some additional information) of Secti= on 4.  Finding a Directory Server.

I would integrate this into Section 4.

6.2. also uses the Content-Format ID 21225 without explaining what it is...= 

6.6.  Read Endpoint Links
Is there any functionality that is not provided through the lookup interfac= e (apart from a quicker ep selection)?

As part of the RD evolution, a GET on the handle resource should primarily = return the forms to update and delete the registration. Forms that are pre-= filled with the endpoint information could enable a nice collection-based l= ookup for management.

6.7.  Update Endpoint Links
Shouldn't this be merged with Section 6.4. Registration Update?


Best regards
Matthias


From: Michael Koster [michael.koster@smar= tthings.com]
Sent: Friday, July 08, 2016 12:54 AM
To: draft-ietf-core-resource-directory@tools.ietf.org; core@ietf.org=
Cc: consultancy@vanderstok.org; Kovatsch Matthias; Hannes Tschofenig= ; Oscar Novo; Zach Shelby; Carsten Bormann
Subject: CoRE RD update in SVN repository

I have uploaded an updated RD draft to the core SVN repository, with w= hat I believe are all of the outstanding changes and comments.

dra= ft-ietf-core-resource-directory-xx.mkd
draft-ietf-core-resource-directory-xx.= xml
dra= ft-ietf-core-resource-directory-xx.txt
The changelog describes the significant changes.

I will submit this as version -08 tomorrow if there are no = urgent changes to make.

Best regards,

Michael
--_000_55877B3AFB359744BA0F2140E36F52B551DB4D46MBX110dethzch_-- From nobody Fri Jul 8 00:04:22 2016 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 EF1FF12D0F5; Fri, 8 Jul 2016 00:04:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 b4ojey5kgNJS; Fri, 8 Jul 2016 00:04:09 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF0212D0B5; Fri, 8 Jul 2016 00:04:08 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-c7-577f506690be Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.F5.12516.6605F775; Fri, 8 Jul 2016 09:04:06 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 8 Jul 2016 09:03:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gYNDEmljfHWTfKJ756ZztZrO8Nrc/XTPp3bksEUa5uc=; b=fMq5V2uaBpFUFF80klap9juRS3GtfXjbs5SBveEdzbdXwo60Yl0nWXgJ1NGKR1w/O5buB//1tFQjyDgrZRML6b9EEjS6Jrlj01hdXtyCIYohcendpSeO70i8R9mTEyvlNrQMMqYNd9e+haDHh3fxRphYWSzmed3DU0g8PgITE6E= Received: from AMXPR07MB070.eurprd07.prod.outlook.com (10.242.70.148) by AMXPR07MB072.eurprd07.prod.outlook.com (10.242.70.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 8 Jul 2016 07:03:54 +0000 Received: from AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) by AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) with mapi id 15.01.0528.024; Fri, 8 Jul 2016 07:03:54 +0000 From: Francesca Palombini To: "core@ietf.org" , "cose@ietf.org" , "Ace@ietf.org" Thread-Topic: New Version Notification for draft-selander-ace-object-security-05.txt Thread-Index: AQHR2G3dJR4k7DwmmE2nHZmL8yaTPqAOF8bQ Date: Fri, 8 Jul 2016 07:03:54 +0000 Message-ID: References: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> In-Reply-To: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> 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=francesca.palombini@ericsson.com; x-originating-ip: [80.216.62.213] x-ms-office365-filtering-correlation-id: 2590db24-1cb4-4205-243d-08d3a6fe0643 x-microsoft-exchange-diagnostics: 1; AMXPR07MB072; 6:bBnM/fcF9RGtC1vszn4D3Cz0nSlUVlT8MtyWdtlqWtMm7ayWeIOqOFM8hurhFGKNgEvqXT8Mx9ZVtDU8DWQGh7L9nx0LqOMIYfG74UUub/zSFPDTPzqRpKsw5xzMFsra6Ad53K9ELtCikV87J2biYXPAaTs7Fsg7mwBmNCkLRlw4SwYNymzAQP4yf5nepCIbnTwiH4QW8xynK0SUmn5+PtlGSUvBk2Tfdd5cZddUH2CgDAXECWQCHmW1bV+B8suNx8hls0hFk2HKjqlfEzDn1fC2PFKrN1nuo4t8fwhYzsU=; 5:XDE4jW+6Y6JFeSxNSu8iCvUpnCH2t9ZUh2fwTesbTkv5jgoZvwB3sEl7eLmyvpUm2e4Ia2MGH1fqKkkz1jVYyfiBdzXB/34ilIsaZLXhs9OwAWaV1EPxZEZAjXqNhJFpdyXfmqd5IyfsiYr3a9rrXA==; 24:ayvostBFnEJeCBQ8wTf77dbSrXUzpqz+oeSPW50ibX1CfaOpFjBroKvILq1xQ5b6QUOfwfrSqhJpUF+LB69ur+ETq55rQW8Gmj0WPaVHabE=; 7:rZX2iCPCeQOuLK+GNcos+u0h/+v54XaVMWxfcTT/2emkR1aOsEL7dCY+BkDtEB1yyLbFGgmgJZEZDXPV2AEFz9+sT36IABbO5Id9i+iHt2e3841d5QPXAAskiLifOFqO6DbP+8Oh/s3YqJCoNhw/ov8JqcCUNjusUe70nMExzw9gVgGxo/SuszefB2bioCuduQ02lj9/JFRLSF3/6P3c3oNlk1wfTAb3tO+R0iKYMg+cSF4F0/EFv9a+LlKkm6ey x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB072; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMXPR07MB072; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB072; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377424004)(13464003)(199003)(76576001)(3846002)(5002640100001)(81166006)(2906002)(6116002)(105586002)(19580395003)(2201001)(189998001)(86362001)(81156014)(102836003)(10400500002)(586003)(15650500001)(107886002)(8676002)(87936001)(2900100001)(230783001)(2950100001)(15975445007)(97736004)(3660700001)(9686002)(11100500001)(92566002)(76176999)(66066001)(122556002)(101416001)(54356999)(8936002)(3280700002)(74316002)(50986999)(450100001)(33656002)(106116001)(19580405001)(305945005)(106356001)(5003600100003)(7846002)(2501003)(7696003)(7736002)(5001770100001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB072; H:AMXPR07MB070.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 07:03:54.3839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB072 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42KZGbE9RDctoD7cYOF9A4vv33qYLfa9Xc9s MW3rVFYHZo8lS34yBTBGcdmkpOZklqUW6dslcGWcf9XCXDBLumLR8ydsDYwHpLoYOTkkBEwk 5rxqYIewxSQu3FvP1sXIxSEkcIRR4l/TA3YI5zijxK7dm8AcFoFeZommu41gLUIClxklJh4z hqg6yijxZ9FKRpAEm4CNxIWH71lBbBGBVIkXFzaDxYUFQiV2Hj/A3MXIARQPkzg91xeixEji z/dVbCA2i4CKxNKFh5lAbF6BKImrW9+wgJQLCThK/L0cDxLmFHCS6P3bzAxiMwJd/f3UGrBy ZgFxiVtP5jNBfCMgsWTPeWYIW1Ti5eN/rBD1yRJXbvdBfawo8bVxLxvIeAkBX4l5fawgn0gI vGWTOPr3ABtEjavExFl7WSHsTIklPfdYIOpjJP4cEoOoX8so8fvyVBaIGhmJ429vMkLYXWwS y9rjIUGVKrF8bSs0FKQk7l7pZJzAqDULydmzgMYyC2hKrN+lDxFWlJjS/ZB9FjggBCVOznzC soCRZRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYLo4uOW37g7G1a8dDzEKcDAq8fAmONaH C7EmlhVX5h5ilOBgVhLh/eQNFOJNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1 tSC1CCbLxMEp1cCofzRxik9kzcoD71/stJVRn/bbej5vcafM1DVyTxd+jNqzwGbhevmXuqEJ Ugfj0ht+v/yz8cELPpM9HCIdDjlVj55dKjPT39N8ob7nztM/ix8XXs8/u3txsmHHCsnHgUe4 M4/KOZtZyT9yqiyb6J9dcan2/bFDfNd1TeIlp3UqHk3k3R+Zd8tbiaU4I9FQi7moOBEAV0n5 /xMDAAA= Archived-At: Subject: [core] FW: New Version Notification for draft-selander-ace-object-security-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 07:04:13 -0000 RGVhciBDb1JFLCBDT1NFIGFuZCBBQ0UgbWVtYmVycywNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYW4g dXBkYXRlIHRvIHRoZSBPU0NPQVAgZHJhZnQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNQ0KDQpGb3IgdGhvc2Ugd2hvIGRv buKAmXQga25vdywgT1NDT0FQIGlzIGFuIGFwcGxpY2F0aW9uIGxheWVyIHNlY3VyaXR5IHByb3Rv Y29sIGZvciBDb0FQLCBiYXNlZCBvbiB3cmFwcGluZyByZXF1ZXN0IGFuZCByZXNwb25zZSBtZXNz YWdlcyBpbiBDT1NFIG9iamVjdHMgd2hpY2ggYXJlIHNlbnQgaW4gYSBDb0FQIG1lc3NhZ2UgZXhj aGFuZ2UuDQoNCldpdGggdGhpcyB2ZXJzaW9uLCB3ZSBhaW1lZCBmb3IgaW1wcm92ZWQgcmVhZGFi aWxpdHkgYW5kIHdlIGFkZGVkIHRoZSBibG9ja3dpc2UgZnVuY3Rpb25hbGl0eSwgYXMgZGlzY3Vz c2VkIGR1cmluZyBsYXN0IGYyZiBtZWV0aW5nLg0KDQpXZSBhcmUgbm93IGxvb2tpbmcgZm9yIHJl dmlld3MuIEFueSBjb21tZW50IG9yIGZlZWRiYWNrIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0 ZWQhDQoNCkJlc3QgcmVnYXJkcywNCkZyYW5jZXNjYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSANClNlbnQ6IGRlbiA3IGp1bGkgMjAxNiAxODozNw0KVG86IEfDtnJhbiBT ZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPjsgTHVkd2lnIFNlaXR6IDxsdWR3 aWdAc2ljcy5zZT47IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPjsg R8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+OyBGcmFuY2VzY2Eg UGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1 cml0eS0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2VsYW5kZXItYWNl LW9iamVjdC1zZWN1cml0eS0wNS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgRnJhbmNlc2NhIFBhbG9tYmluaSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6CQlkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5DQpSZXZpc2lvbjoJ MDUNClRpdGxlOgkJT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAgKE9TQ09BUCkNCkRvY3VtZW50IGRh dGU6CTIwMTYtMDctMDcNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTM2 DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUudHh0DQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVj dC1zZWN1cml0eS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNQ0KRGlmZjogICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0 LXNlY3VyaXR5LTA1DQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIGRlZmluZXMgT2JqZWN0IFNl Y3VyaXR5IG9mIENvQVAgKE9TQ09BUCksIGEgbWV0aG9kIGZvcg0KICAgYXBwbGljYXRpb24gbGF5 ZXIgcHJvdGVjdGlvbiBvZiBtZXNzYWdlIGV4Y2hhbmdlcyB3aXRoIHRoZQ0KICAgQ29uc3RyYWlu ZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLCB1c2luZyB0aGUgQ0JPUiBPYmplY3QNCiAg IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24gKENPU0UpIGZvcm1hdC4gIE9TQ09BUCBwcm92aWRlcyBl bmQtdG8tZW5kDQogICBlbmNyeXB0aW9uLCBpbnRlZ3JpdHkgYW5kIHJlcGxheSBwcm90ZWN0aW9u IHRvIENvQVAgcGF5bG9hZCwgb3B0aW9ucywNCiAgIGFuZCBoZWFkZXIgZmllbGRzLCBhcyB3ZWxs IGFzIGEgc2VjdXJlIGJpbmRpbmcgYmV0d2VlbiBDb0FQIHJlcXVlc3QNCiAgIGFuZCByZXNwb25z ZSBtZXNzYWdlcy4gIFRoZSB1c2Ugb2YgT1NDT0FQIGlzIHNpZ25hbGVkIHdpdGggdGhlIENvQVAN CiAgIG9wdGlvbiBPYmplY3QtU2VjdXJpdHksIGFsc28gZGVmaW5lZCBpbiB0aGlzIG1lbW8uDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jul 8 03:20:35 2016 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 71F1D12D126 for ; Fri, 8 Jul 2016 03:20: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 Ol9R_xKZlF9E for ; Fri, 8 Jul 2016 03:20:31 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA37612D0B4 for ; Fri, 8 Jul 2016 03:20:30 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud3.xs4all.net with ESMTP id GALS1t00J4SmhUa01ALSMc; Fri, 08 Jul 2016 12:20:28 +0200 Received: from AMontpellier-654-1-199-225.w90-0.abo.wanadoo.fr ([90.0.226.225]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Jul 2016 12:20:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Jul 2016 12:20:26 +0200 From: peter van der Stok To: Oscar Novo Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> Message-ID: X-Sender: stokcons@xs4all.nl (DVxNg9O97+EfjkGbf4m/+nka/aBL19yh) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-resource-directory@tools.ietf.org, 'Michael Koster' , core@ietf.org, Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:20:33 -0000 > Req: POST coap://rd.example.com/rd-group?gp=lights > > ct: 40 > I think it needs to be removed. It is not defined in the URI-template From nobody Fri Jul 8 03:35:30 2016 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 426D912D825 for ; Fri, 8 Jul 2016 03:35:29 -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 An1HD1OdbtZn for ; Fri, 8 Jul 2016 03:35:28 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4300312D7F6 for ; Fri, 8 Jul 2016 03:35:25 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud3.xs4all.net with ESMTP id GAbQ1t00J4SmhUa01AbQPD; Fri, 08 Jul 2016 12:35:24 +0200 Received: from AMontpellier-654-1-199-225.w90-0.abo.wanadoo.fr ([90.0.226.225]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Jul 2016 12:35:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Jul 2016 12:35:24 +0200 From: peter van der Stok To: Kovatsch Matthias Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net>, <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> Message-ID: <3a09b9ae09badf97951adc0e8983ebdf@xs4all.nl> X-Sender: stokcons@xs4all.nl (9zFPnH1vSwlzgf3vKRml8OnfIDLHjZlP) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-resource-directory@tools.ietf.org, Oscar Novo , Michael Koster , core@ietf.org, Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:35:29 -0000 Hi Matthias, > I did a quick review of the draft. I know you are quite swamped, but > maybe we can get some updates in before publishing: Thanks, there is one point where I can be useful..... > > 4.1. Resource Directory Address Option (RDAO) > I am quite lost of the context here. There is only a quick hint in > the bullet point list in Section 4---best add parentheses and "see > ..." there. Otherwise it is unclear what kind of option you are > talking about. In the bullets of section 4 it is mentioned see section 4.1; I probably do not understand what you mean. > > It is the only location where "6LR" is used without explanation. > Furthermore, the endpoint could also be a 6LoWPAN host instead of a > router... Right, 6LR should be endpoint. > > Why is the length always 3? Is that right? (I haven't read the ND > spec...) > The length does not change; and is fixed to 3 * 8 bytes. (standard ND) cheerio, Peter From nobody Fri Jul 8 06:13:53 2016 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 E5AC812B058 for ; Fri, 8 Jul 2016 06:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 923mjYCN_Xqz for ; Fri, 8 Jul 2016 06:13:48 -0700 (PDT) Received: from mail-gw-out1.cc.tut.fi (mail-gw-out1.cc.tut.fi [130.230.160.32]) (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 9F2A612D110 for ; Fri, 8 Jul 2016 06:13:47 -0700 (PDT) X-AuditID: 82e6a020-f6fff700000009c2-98-577fa7019d07 Received: from mail2.tut.fi (mail2.tut.fi [130.230.162.20]) by (Symantec Messaging Gateway) with SMTP id F5.15.02498.107AF775; Fri, 8 Jul 2016 16:13:40 +0300 (EEST) Received: from webmail.intra.tut.fi (mail.intra.tut.fi [130.230.76.51]) by mail2.tut.fi (Postfix) with ESMTPS id 1FDA3211A6 for ; Fri, 8 Jul 2016 16:13:37 +0300 (EEST) Received: from MB2010-1.intra.tut.fi ([169.254.1.30]) by cas01.intra.tut.fi ([2002:82e6:4c33::82e6:4c33]) with mapi id 14.03.0294.000; Fri, 8 Jul 2016 16:13:37 +0300 From: Bilhanan Silverajan To: "core@ietf.org WG" Thread-Topic: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-03.txt Thread-Index: AQHR2ROVFJHpR+khEEOQPNgYQAUEd6AOgurW Date: Fri, 8 Jul 2016 13:13:35 +0000 Message-ID: <3AEFD1CC0904C24BB37C605174C890B427F226@mb2010-1.intra.tut.fi> References: <20160708122348.32099.42785.idtracker@ietfa.amsl.com> In-Reply-To: <20160708122348.32099.42785.idtracker@ietfa.amsl.com> Accept-Language: en-IE, fi-FI, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsXS9GyRiC7L8vpwg9nH2C32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK0HnrAVfOar+PPjGGsD4zKeLkZODgkBE4llm04xgdhCAisY JfZPBbK5gOzdjBI9N15COSsZJVYf3ccGUsUmYCbRtOoWC4gtIqAm0TrpFVhcWCBJ4sbDVkaI eLLExEt9TBC2kUTD9FNgNSwCKhJb3n0D6+UV8JJ40rsWqIYDaIGjxNr1/iBhTgEniRlvu1hA woxA5c1T3UDCzALiEk1fVrJC3CwgsWTPeWYIW1Ti5eN/rBA1BhJf3t9mgbC1JZYtfM0MsUlQ 4uTMJywTGEVmIRk1C0nLLCQts5C0LGBkWcUolpuYmaObXq6bX1piqJecrFdSWqKXlrmJERz6 CxR2ML6cpn+IUYCDUYmH10C8PlyINbGsuDL3EKMkB5OSKK9hAFCILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCG/yUqAcb0piZVVqUT5MSpqDRUmct9RfM0RIID2xJDU7NbUgtQgmK8PBoSTB2w7S KFiUmp5akZaZU4KQZuLgBBnOAzR8Ndjw4oLE3OLMdIj8KUZFKXHeQJCEAEgiozQPrheSmnyM XzGKA70izPscpIoHmNbgul8BDWYCGmwQADa4JBEhJdXAuHRVz+Ll9yJ2hqheEPX2vGOgukbc /kjilMTnJmqndlw/ev527SyRw6KL1/aXzP6x2+35hG2LtrenzlApbhB63Ggb8KDoRVqw17el Zn63V3cmFsfu4/q39HvJ15/yDsu+SWnx6QpnR+tu3juNXe2Gf84nlQjp0srnBt98BfZGruPX 3s21O2zzPSWW4oxEQy3mouJEAA1G4VEoAwAA Archived-At: Subject: [core] FW: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 13:13:52 -0000 Dear all, A new version of our draft on CoAP Protocol Negotiation was just submitted.= Details follow below. Best regards Bill ________________________________ From: internet-drafts@ietf.org Sent: =FD08/=FD07/=FD2016 15:23 To: Bilhanan Silverajan; Bilhanan Silver= ajan; Mert Ocak Subject: New Version Notification for draft-silverajan-core-coap-protocol-n= egotiation-03.txt A new version of I-D, draft-silverajan-core-coap-protocol-negotiation-03.tx= t has been successfully submitted by Bilhanan Silverajan and posted to the IETF repository. Name: draft-silverajan-core-coap-protocol-negotiation Revision: 03 Title: CoAP Protocol Negotiation Document date: 2016-07-08 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-silverajan-core-= coap-protocol-negotiation-03.txt Status: https://datatracker.ietf.org/doc/draft-silverajan-core-coap= -protocol-negotiation/ Htmlized: https://tools.ietf.org/html/draft-silverajan-core-coap-prot= ocol-negotiation-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-silverajan-core-c= oap-protocol-negotiation-03 Abstract: CoAP has been standardised as an application-level REST-based protocol. When multiple transport protocols exist for exchanging CoAP resource representations, this document introduces a way forward for CoAP endpoints as well as intermediaries to agree upon alternate transport and protocol configurations as well as URIs for CoAP messaging. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jul 8 06:39:09 2016 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 377BC12D135 for ; Fri, 8 Jul 2016 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 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_NEUTRAL=0.779] autolearn=ham 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 Xq7Wz4FEeuGy for ; Fri, 8 Jul 2016 06:39:05 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B05612D0DA for ; Fri, 8 Jul 2016 06:39:05 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id i123so13419140pfg.0 for ; Fri, 08 Jul 2016 06:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lZhD5biluODn1C/h3LBxktEqHY9pzEp3XL5F/zFWYPM=; b=DjgbAvv/ixHAwLe6cufMhJnGVnvjq+tokL46cLRwKVGrhxNbs2EzGyWTep07e4nv6n 8hCKTP0QnXfeuINFkwvpSJLR1w2WiDxPgjVu01SuA+p9ZJz/1vZ/YKBYug5kO1dF8FCD MwUYzRiy7mzboJAnlsfpsglTrW982AjS0qnk7RLm76u2AFvEMBUCGeQkqXknVVZdQdAr qS5aefp7BL4Omc3bOsSlr1Ff7ePWvh4OlmYrOVRUSRQud1g34LSNU2dBhlTxYGz38nf4 j/Y+I5c3JWvfSAM4qYZ4cJLBUEgoWb9d5+JUb+2XxWW0qjg7J+G1TzpdSPTwDvh+wVMx qthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lZhD5biluODn1C/h3LBxktEqHY9pzEp3XL5F/zFWYPM=; b=VTbVaL0k9A7SZ3uit1K71abrpFnAnQtRzIIJU/UliVw2az0jPHP+teDRmPia0H3Dig czugixLR0IwQDa+UaIikxXBf1joCDGF2J17pjO56rzClJyElm/4hvfVqEZreQ/NZdic0 fUNaRpUWdioOhUgAQtM8AQdgWkm8+Iq3Of2jg/9z0pIqJm9L9428RIegCbGA+SPySUOj msdtc7jJUdZT6WZeRg7Gj6yqFvqcWQrSf8VEMmecZsng0Bh7GMe9PKCxBIV6VNFTaY4q AmX05r4YGwMLTKsQFbSt4jOMqDQ3G2atsCG6gD4LM/qCvzb03G8cK/qKGq7mKuqb8yFn WwGQ== X-Gm-Message-State: ALyK8tL8TpkK1+o3f0xCBYipdvyrrJL1YwnIIjuA5ohHaOhkRdkqZ8L/tGZR+Bbob7Spja1g X-Received: by 10.98.65.2 with SMTP id o2mr10102416pfa.97.1467985144686; Fri, 08 Jul 2016 06:39:04 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id yt4sm5083808pab.26.2016.07.08.06.39.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 06:39:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Fri, 8 Jul 2016 06:39:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7781C6E3-8F43-4194-9F86-7C2A0D5FB00B@smartthings.com> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Hannes Tschofenig , draft-ietf-core-resource-directory@tools.ietf.org, Oscar Novo , core@ietf.org Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 13:39:07 -0000 That should be : Content-Format: application/link-format MIchael > On Jul 8, 2016, at 3:20 AM, peter van der Stok wrote: > > >> Req: POST coap://rd.example.com/rd-group?gp=lights >> ct: 40 > I think it needs to be removed. It is not defined in the URI-template > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Jul 8 07:06:34 2016 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 CE7E812D17E for ; Fri, 8 Jul 2016 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 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_NEUTRAL=0.779] autolearn=ham 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 27YJtqIBLGnx for ; Fri, 8 Jul 2016 07:06:22 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 E9F3512D73B for ; Fri, 8 Jul 2016 07:06:21 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id fi15so20533pac.1 for ; Fri, 08 Jul 2016 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=v6kJ8OxVbeAIKf7klqQHSFWqE+LeVmsNpNXpseh6XWs=; b=ckegVq9Hpzgk2nZNlqL4ISaMCtg9xRTepxrB1wYbfTpm8gOcKB57E2rprWU72pYO2T DsZqcfL1RJf6KKqNVBBXpOMafgVhU8AY5RvMAbS2qjeXJN6/1x/t1OXqcXibZ0+hfO88 +FyKy8AiaEnD5zlcxRlmKJX43IHURy87SZzw2T68hepxlUFTHrz/3e32KlhnPJM/uNXW 4+0S4Q46erZjn2zX9SW6bZ6reJMGDJNU7GL8shyQnFPcow04B4rWxDGSkZyvLqu6Apw1 YX5Q+SdQsXiJ1QrtM+KenyAtqEtbgxaa0eFm+QAl+Mf49cupMJ/fVpHPTD786qSSuyU+ K/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=v6kJ8OxVbeAIKf7klqQHSFWqE+LeVmsNpNXpseh6XWs=; b=BDnn3uvqodmqkBsEUWScoZbo1iQzqjdk7EXWurCyFyQssGH0NPxvHKwp9Tfc4MovBL VjzkXdDgQHee0OHIEQOR8KqMs/+1wuocJ2RN7VTQdE3g1UVz1jgVGskwC5We1Q0amKjF juxslrvQOD3pcgIw1dKSzYuski0lycfWJuZcs2smFeHlJSgr2UDvk8L35pH57HaDo/y1 lG/F54ivcE/7eZVKsLZnqx7imJhMvuzeMXE/OQSOo+R+E2Q6UdJPkbRBNIFB4hQ4modI JTSKXNaeQyXht+3WsdWLxG/wFgCLzoTpeTjtWgFscQ2O4qO3aB/TF3s5N/BdUsekbjBH n/xg== X-Gm-Message-State: ALyK8tKEYnSnhpTX8uT3RVEu9aal4sJjk3HdkImK/IaNn42hcGNf+eAnnreGYtYMt2XzfYNz X-Received: by 10.66.48.133 with SMTP id l5mr10180721pan.151.1467986781369; Fri, 08 Jul 2016 07:06:21 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id d2sm3994704pfc.37.2016.07.08.07.06.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 07:06:20 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_A66632D9-2056-410E-A9D8-F6AFC6754561" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <3a09b9ae09badf97951adc0e8983ebdf@xs4all.nl> Date: Fri, 8 Jul 2016 07:06:13 -0700 Message-Id: <42487053-B0F9-47C2-A7AE-7620EFECEBCA@smartthings.com> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> <3a09b9ae09badf97951adc0e8983ebdf@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-core-resource-directory@tools.ietf.org, Oscar Novo , core@ietf.org, Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 14:06:33 -0000 --Apple-Mail=_A66632D9-2056-410E-A9D8-F6AFC6754561 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, comments below=20 > On Jul 8, 2016, at 3:35 AM, peter van der Stok = wrote: >=20 > Hi Matthias, >=20 >=20 >> I did a quick review of the draft. I know you are quite swamped, but >> maybe we can get some updates in before publishing: >=20 > Thanks, there is one point where I can be useful..... >=20 >> 4.1. Resource Directory Address Option (RDAO) >> I am quite lost of the context here. There is only a quick hint in >> the bullet point list in Section 4---best add parentheses and "see >> ..." there. Otherwise it is unclear what kind of option you are >> talking about. >=20 > In the bullets of section 4 it is mentioned see section 4.1; I = probably do not understand what you mean. >=20 >> It is the only location where "6LR" is used without explanation. >> Furthermore, the endpoint could also be a 6LoWPAN host instead of a >> router... >=20 > Right, 6LR should be endpoint. Fixed. Also addressed some of Matthias comments --Apple-Mail=_A66632D9-2056-410E-A9D8-F6AFC6754561 Content-Disposition: attachment; filename=draft-ietf-core-resource-directory-xx.txt Content-Type: text/plain; name="draft-ietf-core-resource-directory-xx.txt" Content-Transfer-Encoding: quoted-printable CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster Expires: January 8, 2017 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant July 07, 2016 CoRE Resource Directory draft-ietf-core-resource-directory-08 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 resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Shelby, et al. Expires January 8, 2017 [Page 1] =0C Internet-Draft CoRE Resource Directory July 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 4. Finding a Directory Server . . . . . . . . . . . . . . . . . 8 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 9 5. Simple Registration . . . . . . . . . . . . . . . . . . . . . 10 5.1. Simple publishing to Resource Directory Server . . . . . 11 5.2. Third-party registration . . . . . . . . . . . . . . . . 12 6. Resource Directory Function Set . . . . . . . . . . . . . . . 12 6.1. Content Formats . . . . . . . . . . . . . . . . . . . . . 13 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Registration . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Registration Update . . . . . . . . . . . . . . . . . . . 17 6.5. Registration Removal . . . . . . . . . . . . . . . . . . 20 6.6. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 21 6.7. Update Endpoint Links . . . . . . . . . . . . . . . . . . 22 7. Group Function Set . . . . . . . . . . . . . . . . . . . . . 24 7.1. Register a Group . . . . . . . . . . . . . . . . . . . . 24 7.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 26 8. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 27 9. New Link-Format Attributes . . . . . . . . . . . . . . . . . 31 9.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 31 9.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 32 10. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. DNS-based Service discovery . . . . . . . . . . . . . . 32 10.2. mapping ins to . . . . . . . . . . . . . . . 33 10.3. Mapping rt to . . . . . . . . . . . . . . 34 10.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 34 Shelby, et al. Expires January 8, 2017 [Page 2] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings . . . . . . . . . . . . . . = 35 10.6. Importing resource links into DNS-SD . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11.1. Endpoint Identification and Authentication . . . . . . . 36 11.2. Access Control . . . . . . . . . . . . . . . . . . . . . 36 11.3. Denial of Service Attacks . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 37 12.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 37 12.3. IPv6 ND Resource Directory Address Option . . . . . . . 37 12.4. RD Parameter Registry . . . . . . . . . . . . . . . . . 37 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 13.1. Lighting Installation . . . . . . . . . . . . . . . . . 38 13.1.1. Installation Characteristics . . . . . . . . . . . . 39 13.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 40 13.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 43 13.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 43 13.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 44 13.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 45 13.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 47 13.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 47 13.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 47 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 16.1. Normative References . . . . . . . . . . . . . . . . . . 51 16.2. Informative References . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Linking [RFC5988]. The use of Web Linking for the description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format [RFC6690]. However, [RFC6690] only describes how to discover resources from the web server that hosts them by requesting "/.well-known/core". In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast Shelby, et al. Expires January 8, 2017 [Page 3] =0C Internet-Draft CoRE Resource Directory July 2016 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 a Resource Directory are defined. Although the examples in this document show the use of these interfaces with CoAP [RFC7252], they can be applied in an equivalent manner to HTTP [RFC7230]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "byte" is used in its now customary sense as a synonym for "octet". This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252]. To describe the REST interfaces defined in this specification, the URI Template format is used [RFC6570]. This specification makes use of the following additional terminology: Resource Directory A web entity that stores information about web resources and implements the REST interfaces defined in this specification for registration and lookup of those resources. Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Group In the context of a Resource Directory, a group is a logical grouping of endpoints for the purpose of group communications. All groups within a domain are unique. Endpoint Shelby, et al. Expires January 8, 2017 [Page 4] =0C Internet-Draft CoRE Resource Directory July 2016 Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. 3. Architecture and Use Cases The resource directory architecture is illustrated in Figure 1. A Resource Directory (RD) is used as a repository for Web Links [RFC5988] about resources hosted on other web servers, which are called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory entries), and for clients to lookup resources from the RD or maintain groups. Endpoints themselves can also act as clients. An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured by an outside entity. This information hierarchy is shown in Figure 2. Endpoints are assumed to proactively register and maintain resource directory entries on the RD, which are soft state and need to be periodically refreshed. An endpoint is provided with interfaces to register, update and remove a resource directory entry. Furthermore, a mechanism to discover an RD using the CoRE Link Format [RFC6690] is defined. It is also possible for an RD to proactively discover Web Links from endpoints and add them as resource directory entries. A lookup interface for discovering any of the Web Links held in the RD is provided using the CoRE Link Format. Shelby, et al. Expires January 8, 2017 [Page 5] =0C Internet-Draft CoRE Resource Directory July 2016 Registration Lookup, Group Interface Interfaces +----+ | | | EP |---- | | +----+ ---- | | --|- +------+ | +----+ | ----| | | +--------+ | EP | ---------|-----| RD |----|-----| Client | +----+ | ----| | | +--------+ --|- +------+ | +----+ ---- | | | EP |---- | | +----+ Figure 1: The resource directory architecture. +------------+ | Domain | <-- Name +------------+ | | | +------------+ | | Group | <-- Name, Scheme, IP, Port | +------------+ | | +------------+ | Endpoint | <-- Name, Scheme, IP, Port +------------+ | | +------------+ | Resource | <-- Target, Parameters +------------+ Figure 2: The resource directory information hierarchy. 3.1. Use Case: Cellular M2M Over the last few years, mobile operators around the world have focused on development of M2M solutions in order to expand the business to the new type of users: machines. The machines are connected directly to a mobile network using an appropriate embedded air interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and wide range wireless interfaces. =46rom the system design point = of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application Shelby, et al. Expires January 8, 2017 [Page 6] =0C Internet-Draft CoRE Resource Directory July 2016 requirements, thus avoiding silo like solutions. One of the crucial enablers of such design is the ability to discover resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities. Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs. The address of each (proxy) endpoint on this server is included in the resource description stored in the RD. The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database. Similarly, fleet management systems provide the appropriate link parameters to the RD to look up for EPs deployed on the vehicles the application is responsible for. 3.2. Use Case: Home and Building Automation Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. The exporting of resource information to other discovery systems is also important in these automation applications. In home automation there is a need to interact with other consumer electronics, which may already support DNS-SD, and in building automation DNS-SD in combination with resource directories can cover multiple buildings. 3.3. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted Shelby, et al. Expires January 8, 2017 [Page 7] =0C Internet-Draft CoRE Resource Directory July 2016 anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use the Resource Directory lookup function set to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in web link compatible representations are supplied by Resource Directories, which may be internally stored as triples, or relation/attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to common web linking formats for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms should generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. This provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. 4. Finding a Directory Server Endpoints that want to contact a directory server can obtain candidate IP addresses for such servers in a number of ways. In a 6LoWPAN, good candidates can be taken from: o specific static configuration (e.g., anycast addresses), if any, o the ABRO option of 6LoWPAN-ND [RFC6775], o other ND options that happen to point to servers (such as RDNSS), o DHCPv6 options that might be defined later. o The IPv6 Neighbor Discovery Resource Directory Address Option Section 4.1 Shelby, et al. Expires January 8, 2017 [Page 8] =0C Internet-Draft CoRE Resource Directory July 2016 In networks with more inexpensive use of multicast, the candidate IP address may be a well-known multicast address, i.e. directory servers are found by simply sending GET requests to that well-known multicast address (see Section 6.2). As some of these sources are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate- limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. 4.1. Resource Directory Address Option (RDAO) The Resource Directory Option (RDAO) using IPv6 neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with link-local multicast address because the endpoint and the RD are separated by a border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network. The presence and the use of the RD is essential during commissioning. The RDAO format is: Shelby, et al. Expires January 8, 2017 [Page 9] =0C Internet-Draft CoRE Resource Directory July 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length =3D 3 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RD Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 38 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this set of border router information is valid. A value of all zero bits (0x0) assumes a default value of 10,000 (~one week). Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. RD Address: IPv6 address of the RD. Figure 3: Resource Directory Address Option 5. Simple Registration Not all endpoints hosting resources are expected to know how to implement the Resource Directory Function Set (see Section 6) hence cannot register with a Resource Directory. Instead, simple endpoints can implement the generic Simple Directory Discovery approach described in this section. An RD implementing this specification MUST implement Simple Directory Discovery. However, there may be Shelby, et al. Expires January 8, 2017 [Page 10] =0C Internet-Draft CoRE Resource Directory July 2016 security reasons why this form of directory discovery would be disabled. This approach requires that the endpoint makes available the hosted resources that it wants to be discovered, as links on its "/.well- known/core" interface as specified in [RFC6690]. The endpoint then finds one or more addresses of the directory server as described in Section 4. An endpoint can send (a selection of) hosted resources to a directory server for publication as described in Section 5.1. The directory server integrates the information it received this way into its resource directory. It MAY make the information available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 5.1. Simple publishing to Resource Directory Server An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. The endpoint MAY include registration parameters in the POST request as per Section 6.3 The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. Shelby, et al. Expires January 8, 2017 [Page 11] =0C Internet-Draft CoRE Resource Directory July 2016 Req:(to RD server from [ff02::1]) POST coap://rd.example.com/.well-known/core?lt=3D6000 Content-Format: 40 payload: (empty payload) Res: 2.04 Changed (later) Req: (from RD server to [ff02::1]) GET coap://[ff02::1]/.well-known/core Accept: 40 Res: 2.05 Content payload: 5.2. Third-party registration For some applications, even Simple Directory Discovery may be too taxing for certain very constrained devices, in particular if the security requirements become too onerous. In a controlled environment (e.g. building control), the Resource Directory can be filled by a third device, called a commissioning tool. The commissioning tool can fill the Resource Directory from a database or other means. For that purpose the scheme, IP address and port of the registered device is indicated in the Context parameter of the registration Section 6.3. 6. Resource Directory Function Set This section defines the REST interfaces between an RD and endpoints, which is called the Resource Directory Function Set. Although the examples throughout this section assume the use of CoAP [RFC7252], these REST interfaces can also be realized using HTTP [RFC7230]. In all definitions in this section, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces defined in this section. Shelby, et al. Expires January 8, 2017 [Page 12] =0C Internet-Draft CoRE Resource Directory July 2016 Resource directory entries are designed to be easily exported to other discovery mechanisms such as DNS-SD. For that reason, parameters that would meaningfully be mapped to DNS SHOULD be limited to a maximum length of 63 bytes. 6.1. Content Formats Resource Directory implementations using this specification MUST support the application/link-format content format (ct=3D40). Resource Directories implementing this specification MAY support additional content formats. Any additional content format supported by a Resource Directory implementing this specification MUST have an equivalent serialization in the application/link-format content format. 6.2. Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the path of its RD Function Set. There can be several mechanisms for discovering the RD including assuming a default location (e.g. on an Edge Router in a LoWPAN), by assigning an anycast address to the RD, using DHCP, or by discovering the RD using the CoRE Link Format (see also Section 4). This section defines discovery of the RD using the well-known interface of the CoRE Link Format [RFC6690] as the required mechanism. It is however expected that RDs will also be discoverable via other methods depending on the deployment. Discovery of the RD function set is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup" is used to discover the RD Lookup Function Set. Upon success, the response will contain a payload with a link format entry for each RD discovered, with the URL indicating the root resource of the RD. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link attribute, as shown in the example below. Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. Shelby, et al. Expires January 8, 2017 [Page 13] =0C Internet-Draft CoRE Resource Directory July 2016 HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. An RD implementation of this specification MUST support query filtering for the rt parameter as defined in [RFC6690]. The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt :=3D Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : YES (Unicast only) The following example shows an endpoint discovering an RD using this interface, thus learning that the base RD resource is, in this Shelby, et al. Expires January 8, 2017 [Page 14] =0C Internet-Draft CoRE Resource Directory July 2016 example, at /rd and that the content_format delivered by the server hosting the resource is application.xml (ct=3D40). Note that it is = up to the RD to choose its base RD resource, although diagnostics and debugging is facilitated by using the base paths specified here where possible. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup";ct=3D40, ;rt=3D"core.rd-group";ct=3D40 The following example shows the way of indicating multiple values for Content-Format codes. The Content-Format code attribute "ct" MAY include a space-separated sequence of Content-Format codes as specified in [RFC7252], indicating that multiple content-formats are available. The example below shows the required ct=3D40 = (application/ link-format) as well as a vendor-specific content format. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 21225", ;rt=3D"core.rd-lookup";ct=3D"40 21225", ;rt=3D"core.rd-group";ct=3D"40 21225" 6.3. Registration After discovering the location of an RD Function Set, an endpoint MAY register its resources using the registration interface. This interface accepts a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link- format+json), or CBOR CoRE Link Format (application/link-format+cbor) [I-D.ietf-core-links-json], along with query string parameters indicating the name of the endpoint, its domain and the lifetime of the registration. All parameters except the endpoint name are optional. It is expected that other specifications will define further parameters (see Section 12.4). The RD then creates a new resource or updates an existing resource in the RD and returns its location. An endpoint MUST use that location when refreshing registrations using this interface. Endpoint resources in the RD are kept active for the period indicated by the lifetime parameter. The endpoint is responsible for refreshing the entry within this period using either the registration or update interface. The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameter does not create multiple RD Shelby, et al. Expires January 8, 2017 [Page 15] =0C Internet-Draft CoRE Resource Directory July 2016 entries. A new registration may be created at any time to supercede an existing registration, replacing the registration parameters and links. The registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd :=3D RD Function Set path (mandatory). This is the path of = the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10). et :=3D Endpoint Type (optional). The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor Shelby, et al. Expires January 8, 2017 [Page 16] =0C Internet-Draft CoRE Resource Directory July 2016 The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new resource entry for the endpoint. This Location MUST be a stable identifier generated by the RD as it is used for all subsequent operations on this registration. The resource returned in the Location is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered links, including updating and deleting links. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. The resulting location /rd/4521 is just an example of an RD generated location. Req: POST coap://rd.example.com/rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 Req: POST /rd?ep=3Dnode1 HTTP/1.1 Host : example.com Content-Format: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 6.4. Registration Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the resource returned in the Location option in the response to the first registration. Shelby, et al. Expires January 8, 2017 [Page 17] =0C Internet-Draft CoRE Resource Directory July 2016 An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 6.3 ) if they have changed since the last registration or update. Parameters that have not changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in {registration}. Upon receiving an update request, an RD MUST reset the timeout for that endpoint and update the scheme, IP address and port of the endpoint, using the source address of the update, or the context ("con") parameter if present. If the lifetime parameter "lt" is included in the received update request, the RD MUST update the lifetime of the registration and set the timeout equal to the new lifetime. An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if both the target URI and relation type match. In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 6.7. The update registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. Optional. In the absence of this parameter the scheme of the protocol, source IP address and source port used to register are assumed. This parameter is Shelby, et al. Expires January 8, 2017 [Page 18] =0C Internet-Draft CoRE Resource Directory July 2016 compulsory when the directory is filled by a third party such as a commissioning tool. Content-Format: application/link-format (mandatory) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint updating its registration at an RD using this interface. Req: POST /rd/4521 Res: 2.04 Changed The following example shows an endpoint updating its registration with a new lifetime and context, changing an existing link, and adding a new link using this interface. With the initial registration the client set the following values: o lifetime (lt)=3D500 o context (con)=3Dcoap://local-proxy-old.example.com:5683 o resource=3D ;ct=3D41;rt=3D"foobar";if=3D"sensor" Shelby, et al. Expires January 8, 2017 [Page 19] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST /rd/4521?lt=3D600&con=3D"coap://local-proxy.example.com:5683"= Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-f";if=3D"sensor", ;ct=3D41;rt=3D"door";if=3D"sensor" Res: 2.04 Changed 6.5. Registration Removal Although RD entries have soft state and will eventually timeout after their lifetime, an endpoint SHOULD explicitly remove its entry from the RD if it knows it will no longer be available (for example on shut-down). This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. The removal request interface is specified as follows: Interaction: EP -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the endpoint from the RD. Shelby, et al. Expires January 8, 2017 [Page 20] =0C Internet-Draft CoRE Resource Directory July 2016 Req: DELETE /rd/4521 Res: 2.02 Deleted 6.6. Read Endpoint Links Some endpoints may wish to manage their links as a collection, and may need to read the current set of links in order to determine link maintenance operations. One or more links MAY be selected by using query filtering as specified in [RFC6690] Section 4.1 The read request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" upon success with an "application/link-format", "application/link-format+cbor", or "application/link-format+json" payload. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires January 8, 2017 [Page 21] =0C Internet-Draft CoRE Resource Directory July 2016 The following examples show successful read of the endpoint links from the RD. Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" 6.7. Update Endpoint Links [This section will be removed before or as a result of a working- group last-call if the PATCH methods do not achieve the same level of consensus as the present document.] A PATCH update adds, removes or changes links for the endpoint by including link update information in the payload of the update as a merge-patch+json format [RFC7396] document. One or more links are selected for update by using query filtering as specified in [RFC6690] Section 4.1 The query filter selects the links to be modified or deleted, by matching the query parameter values to the values of the link attributes. When the query parameters are not present in the request, the payload specifies links to be added to the target document. When the query parameters are present, the attribute names and values in the query parameters select one or more links on which to apply the PATCH operation. If an attribute name specified in the PATCH document exists in any the set of selected links, all occurrences of the attribute value in the target document MUST be updated using the value from the PATCH payload. If the attribute name is not present in any selected links, the attribute MUST be added to the links. The update request interface is specified as follows: Interaction: EP -> RD Method: PATCH URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 22] =0C Internet-Draft CoRE Resource Directory July 2016 location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 Content-Format: application/merge-patch+json (mandatory) The following response codes are defined for this interface: Success: 2.04 "Changed" 0r 204 "No Content" in the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration resource does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show an endpoint adding , modifying , and removing links in RD using the Update Endpoint Links function. The following example shows an EP adding the link ;ct=3D41;rt=3D"humid-s";if=3D"sensor" to the collection of = links at the location /rd/4521. Req: PATCH /rd/4521 Payload: [{"href":"/sensors/humid","ct": 41, "rt": "humid-s", "if": "sensor"}] Content-Format: application/merge-patch+json Res: 2.04 Changed The following example shows an EP modifying all links at the location /rd/4521 which are identified by href=3D"/sensors/temp", from the initial link-value of ;rt=3D"temperature" to the new link-value ;rt=3D"temperature-c";if=3D"sensor" by = changing Shelby, et al. Expires January 8, 2017 [Page 23] =0C Internet-Draft CoRE Resource Directory July 2016 the value of the link attribute "rt" and adding the link attribute if=3D"sensor" using the PATCH operation with the supplied merge- patch+json document payload. Req: PATCH /rd/4521?href=3D"/sensors/temp" Payload: {"rt": "temperature-c", "if": "sensor"}, Content-Format: application/merge-patch+json Res: 2.04 Changed This example shows an EP removing all links at the location /rd/4521 which are identified by href=3D"/sensors/light". Req: PATCH /rd/4521?href=3D"/sensors/light" Payload: {null} Content-Format: application/merge-patch+json Res: 2.04 Changed 7. Group Function Set This section defines a function set for the creation of groups of endpoints for the purpose of managing and looking up endpoints for group operations. The group function set is similar to the resource directory function set, in that a group may be created or removed. However unlike an endpoint entry, a group entry consists of a list of endpoints and does not have a lifetime associated with it. In order to make use of multicast requests with CoAP, a group MAY have a multicast address associated with it. 7.1. Register a Group In order to create a group, a commissioning tool (CT) used to configure groups, makes a request to the RD indicating the name of the group to create (or update), optionally the domain the group belongs to, and optionally the multicast address of the group. The registration message includes the list of endpoints that belong to that group. Shelby, et al. Expires January 8, 2017 [Page 24] =0C Internet-Draft CoRE Resource Directory July 2016 All the endpoints in the group MUST be registered with the RD before registering a group. If an endpoint is not yet registered to the RD before registering the group, the registration message returns an error. The RD sends a blank target URI for every endpoint link when registering the group. Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. The registration request interface is specified as follows: Interaction: CT -> RD Method: POST URI Template: /{+rd-group}{?gp,d,con} URI Template Variables: rd-group :=3D RD Group Function Set path (mandatory). This is = the path of the RD Group Function Set. An RD SHOULD use the value "rd-group" for this variable whenever possible. gp :=3D Group Name (mandatory). The name of the group to be created or replaced, unique within that domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this group = belongs. The maximum length of this parameter is 63 bytes. Optional. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10) con :=3D Context (optional). This parameter is used to set the = IP multicast address at which this server is available in the form scheme://multicast-address:port. Optional. In the absence of this parameter no multicast address is configured. This parameter is compulsory when the directory is filled by a commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 25] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new group entry. This Location MUST be a stable identifier generated by the RD as it is used for delete operations on this registration. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". An Endpoint is not registered in the RD (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface. The resulting location /rd-group/12 is just an example of an RD generated group location. Req: POST coap://rd.example.com/rd-group?gp=3Dlights ct: 40 Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 2.01 Created Location: /rd-group/12 Req: POST /rd-group?gp=3Dlights HTTP/1.1 Host: example.com Accept: application/link-format Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 201 Created Location: /rd-group/12 7.2. Group Removal A group can be removed simply by sending a removal message to the location returned when registering the group. Removing a group MUST NOT remove the endpoints of the group from the RD. The removal request interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 26] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: CT -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful group registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the group from the RD. Req: DELETE /rd-group/12 Res: 2.02 Deleted 8. RD Lookup Function Set In order for an RD to be used for discovering resources registered with it, a lookup interface can be provided using this function set. This lookup interface is defined as a default, and it is assumed that RDs may also support lookups to return resource descriptions in alternative formats (e.g. Atom or HTML Link) or using more advanced interfaces (e.g. supporting context or semantic based lookup). This function set allows lookups for domains, groups, endpoints and resources using attributes defined in the RD Function Set and for use with the CoRE Link Format. The result of a lookup request is the list of links (if any) corresponding to the type of lookup. Thus, a domain lookup MUST return a list of domains, a group lookup MUST return a list of groups, an endpoint lookup MUST return a list of Shelby, et al. Expires January 8, 2017 [Page 27] =0C Internet-Draft CoRE Resource Directory July 2016 endpoints and a resource lookup MUST return a list of links to resources. Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. The target of these links SHOULD be the actual location of the domain, endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. The domain lookup returns every lookup domain with a "/rd" value encapsulated within angle brackets. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a "/rd-group" value encapsulated within angle brackets. Otherwise, the group lookup returns the multicast address of the group inside angle brackets. Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default) or its alternate content-formats ("application/link-format+json" or "application/link-format+cbor"). Multiple query parameters MAY be included in a lookup, all included parameters MUST match for a resource to be returned. The character'*' MAY be included at the end of a parameter value as a wildcard operator. The rd-lookup interface MAY use any set of query parameters to match the registered attributes and relations. In addition, this interface MAY be used with queries that specify domains, endpoints, and groups. For example, a domain lookup filtering on groups would return a list of domains that contain the specified groups. An endpoint lookup filtering on groups would return a list of endpoints that are in the specified groups. The lookup interface is specified as follows: Interaction: Client -> RD Method: GET URI Template: /{+rd-lookup-base}/{lookup- type}{?d,ep,gp,et,rt,page,count,resource-param} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 28] =0C Internet-Draft CoRE Resource Directory July 2016 rd-lookup-base :=3D RD Lookup Function Set path (mandatory). = This is the path of the RD Lookup Function Set. An RD SHOULD use the value "rd-lookup" for this variable whenever possible. lookup-type :=3D ("d", "ep", "res", "gp") (mandatory) This = variable is used to select the kind of lookup to perform (domain, endpoint, resource, or group). ep :=3D Endpoint name (optional). Used for endpoint, group and resource lookups. d :=3D Domain (optional). Used for domain, group, endpoint and resource lookups. res :=3D resource (optional). Used for domain, group, endpoint = and resource lookups. gp :=3D Group name (optional). Used for endpoint, group and resource lookups. page :=3D Page (optional). Parameter can not be used without the count parameter. Results are returned from result set in pages that contains 'count' results starting from index (page * count). count :=3D Count (optional). Number of results is limited to = this parameter value. If the parameter is not present, then an RD implementation specific default value SHOULD be used. rt :=3D Resource type (optional). Used for group, endpoint and resource lookups. et :=3D Endpoint type (optional). Used for group, endpoint and resource lookups. resource-param :=3D Link attribute parameters (optional). Any = link attribute as defined in Section 4.1 of [RFC6690], used for resource lookups. Content-Format: application/link-format (optional) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following responses codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 29] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.05 "Content" or 200 "OK" with an "application/link- format", "application/link-format+cbor", or "application/link- format+json" payload containing matching entries for the lookup. Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching entry is found for a unicast request. Failure: No error response to a multicast request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The examples in this section assume a CoAP host with IP address FDFD::123 and a default CoAP port 61616. HTTP hosts are possible and do not change the nature of the examples.\ The following example shows a client performing a resource lookup: Req: GET /rd-lookup/res?rt=3Dtemperature Res: 2.05 Content ;rt=3D"temperature" The following example shows a client performing an endpoint type lookup: Req: GET /rd-lookup/ep?et=3Dpower-node Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" The following example shows a client performing a domain lookup: Req: GET /rd-lookup/d Res: 2.05 Content <>;d=3D"domain1", <>;d=3D"domain2" The following example shows a client performing a group lookup for all groups: Shelby, et al. Expires January 8, 2017 [Page 30] =0C Internet-Draft CoRE Resource Directory July 2016 Req: GET /rd-lookup/gp Res: 2.05 Content <>;gp=3D"lights1";d=3D"example.com" <>;gp=3D"lights2";d=3D"ecample.com" The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rd-lookup/ep?gp=3Dlights1 Res: 2.05 Content ;ep=3D"node1", ;ep=3D"node2" The following example shows a client performing a lookup for all groups an endpoint belongs to: Req: GET /rd-lookup/gp?ep=3Dnode1 Res: 2.05 Content <>;gp=3D"lights1" 9. New Link-Format Attributes When using the CoRE Link Format to describe resources being discovered by or posted to a resource directory service, additional information about those resources is useful. This specification defines the following new attributes for use in the CoRE Link Format [RFC6690]: link-extension =3D ( "ins" "=3D" quoted-string ) ; Max 63 bytes link-extension =3D ( "exp" ) 9.1. Resource Instance attribute 'ins' The Resource Instance "ins" attribute is an identifier for this resource, which makes it possible to distinguish it from other similar resources. This attribute is similar in use to the portion of a DNS-SD record (see Section 10.1, and SHOULD be unique across resources with the same Resource Type attribute in the domain it is used. A Resource Instance might be a descriptive string like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID or iNumber. This attribute is used by a Resource Directory to distinguish between multiple instances of the same resource type within the directory. Shelby, et al. Expires January 8, 2017 [Page 31] =0C Internet-Draft CoRE Resource Directory July 2016 This attribute MUST be no more than 63 bytes in length. The resource identifier attribute MUST NOT appear more than once in a link description. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 9.2. Export attribute 'exp' The Export "exp" attribute is used as a flag to indicate that a link description MAY be exported by a resource directory to external directories. The CoRE Link Format is used for many purposes between CoAP endpoints. Some are useful mainly locally, for example checking the observability of a resource before accessing it, determining the size of a resource, or traversing dynamic resource structures. However, other links are very useful to be exported to other directories, for example the entry point resource to a functional service. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 10. DNS-SD Mapping CoRE Resource Discovery is intended to support fine-grained discovery of hosted resources, their attributes, and possibly other resource relations [RFC6690]. In contrast, service discovery generally refers to a coarse-grained resolution of an endpoint's IP address, port number, and protocol. Resource and service discovery are complementary in the case of large networks, where the latter can facilitate scaling. This document defines a mapping between CoRE Link Format attributes and DNS-Based Service Discovery [RFC6763] fields that permits discovery of CoAP services by either method. 10.1. DNS-based Service discovery DNS-Based Service Discovery (DNS-SD) defines a conventional method of configuring DNS PTR, SRV, and TXT resource records to facilitate discovery of services (such as CoAP servers in a subdomain) using the existing DNS infrastructure. This section gives a brief overview of DNS-SD; see [RFC6763] for a detailed specification. DNS-SD service names are limited to 255 octets and are of the form: Service Name =3D ... Shelby, et al. Expires January 8, 2017 [Page 32] =0C Internet-Draft CoRE Resource Directory July 2016 The service name is the label of SRV/TXT resource records. The SRV RR specifies the host and the port of the endpoint. The TXT RR provides additional information in the form of key/value pairs. The part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify servers or groups of servers. The part is composed of at least two labels. The first label of the pair is the application protocol name [RFC6335] preceded by an underscore character. The second label indicates the transport and is always "_udp" for UDP-based CoAP services. In cases where narrowing the scope of the search may be useful, these labels may be optionally preceded by a subtype name followed by the "_sub" label. An example of this more specific is "light._sub._dali._udp". A default part of the service name may be set at the factory or during the commissioning process. It SHOULD uniquely identify an instance of within a . Taken together, these three elements comprise a unique name for an SRV/ TXT record pair within the DNS subdomain. The granularity of a service name MAY be that of a host or group, or it could represent a particular resource within a CoAP server. The SRV record contains the host name (AAAA record name) and port of the service while protocol is part of the service name. In the case where a service name identifies a particular resource, the path part of the URI must be carried in a corresponding TXT record. A DNS TXT record is in practice limited to a few hundred octets in length, which is indicated in the resource record header in the DNS response message. The data consists of one or more strings comprising a key=3Dvalue pair. By convention, the first pair is txtver=3D (to support different versions of a service description). 10.2. mapping ins to The Resource Instance "ins" attribute maps to the part of a DNS-SD service name. It is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. However, to the extent that the "ins" attribute may be chosen to match the DNS host name of a service, it SHOULD use the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. Shelby, et al. Expires January 8, 2017 [Page 33] =0C Internet-Draft CoRE Resource Directory July 2016 The part of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can allow the device or service to be accessed in many cases without any manual configuration at all. The default name should be short and descriptive, and MAY include a collision-resistant substring such as the lower bits of the device's MAC address, serial number, fingerprint, or other identifier in an attempt to make the name relatively unique. DNS labels are currently limited to 63 octets in length and the entire service name may not exceed 255 octets. 10.3. Mapping rt to The resource type "rt" attribute is mapped into the part of a DNS-SD service name and SHOULD conform to the reg-rel-type production of the Link Format defined in Section 2 of [RFC6690]. The "rt" attribute MUST be composed of at least a single Net-Unicode text string, without underscore '_' or period '.' and limited to 15 octets in length, which represents the application protocol name. This string is mapped to the DNS-SD by prepending an underscore and appending a period followed by the "_udp" label. For example, rt=3D"dali" is mapped into "_dali._udp". The application protocol name may be optionally followed by a period and a service subtype name consisting of a Net-Unicode text string, without underscore or period and limited to 63 octets. This string is mapped to the DNS-SD by appending a period followed by the "_sub" label and then appending a period followed by the service type label pair derived as in the previous paragraph. For example, rt=3D"dali.light" is mapped into "light._sub._dali._udp". The resulting string is used to form labels for DNS-SD records which are stored directly in the DNS. 10.4. Domain mapping DNS domains may be derived from the "d" attribute. The domain attribute may be suffixed with the zone name of the authoritative DNS server to generate the domain name. The "ep" attribute is prefixed to the domain name to generate the FQDN to be stored into DNS with an AAAA RR. Shelby, et al. Expires January 8, 2017 [Page 34] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings A number of [RFC6763] key/value pairs are derived from link-format information, to be exported in the DNS-SD as key=3Dvalue strings in a TXT record ([RFC6763], Section 6.3). The resource is exported as key/value pair "path=3D". The Interface Description "if" attribute is exported as key/value pair "if=3D". The DNS TXT record can be further populated by importing any other resource description attributes as they share the same key=3Dvalue format specified in Section 6 of [RFC6763]. 10.6. Importing resource links into DNS-SD Assuming the ability to query a Resource Directory or multicast a GET (?exp) over the local link, CoAP resource discovery may be used to populate the DNS-SD database in an automated fashion. CoAP resource descriptions (links) can be exported to DNS-SD for exposure to service discovery by using the Resource Instance attribute as the basis for a unique service name, composed with the Resource Type as the , and registered in the correct . The agent responsible for exporting records to the DNS zone file SHOULD be authenticated to the DNS server. The following example shows an agent discovering a resource to be exported: Req: GET /rd-lookup/res?exp Res: 2.05 Content ; exp;rt=3D"dali.light";ins=3D"Spot"; d=3D"office";ep=3D"node1" The agent subsequently registers the following DNS-SD RRs, assuming a zone name "example.com" prefixed with "office": node1.office.example.com. IN AAAA FDFD::1234 _dali._udp.office.example.com IN PTR Spot._dali._udp.office.example.com light._sub._dali._udp.example.com IN PTR Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com IN SRV 0 0 5683 node1.office.example.com. Spot._dali._udp.office.example.com IN TXT txtver=3D1;path=3D/light/1 Shelby, et al. Expires January 8, 2017 [Page 35] =0C Internet-Draft CoRE Resource Directory July 2016 In the above figure the Service Name is chosen as Spot._dali._udp.office.example.com without the light._sub service prefix. An alternative Service Name would be: Spot.light._sub._dali._udp.office.example.com. 11. Security Considerations The security considerations as described in Section 7 of [RFC5988] and Section 6 of [RFC6690] apply. The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described in [RFC7252]. DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. 11.1. Endpoint Identification and Authentication An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. 11.2. Access Control Access control SHOULD be performed separately for the RD Function Set and the RD Lookup Function Set, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. 11.3. Denial of Service Attacks Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the Shelby, et al. Expires January 8, 2017 [Page 36] =0C Internet-Draft CoRE Resource Directory July 2016 request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than requests, RDs can unknowingly become part of a DDoS amplification attack. Therefore, it is RECOMMENDED that implementations ensure return routability. This can be done, for example by responding to wild card lookups only over DTLS or TLS or TCP. 12. IANA Considerations 12.1. Resource Types "core.rd", "core.rd-group" and "core.rd-lookup" resource types need to be registered with the resource type registry defined by [RFC6690]. 12.2. Link Extension The "exp" and "ins" attributes need to be registered when a future Web Linking link-extension registry is created (e.g. in RFC5988bis). 12.3. IPv6 ND Resource Directory Address Option This document registers one new ND option type under the subregistry "IPv6 Neighbor Discovery Option Formats": o Resource Directory address Option (38) 12.4. RD Parameter Registry This specification defines a new sub-registry for registration and lookup parameters called "RD Parameters" under "CoRE Parameters". Although this specification defines a basic set of parameters, it is expected that other standards that make use of this interface will define new ones. Each entry in the registry must include the human readable name of the parameter, the query parameter, validity requirements if any and a description. The query parameter MUST be a valid URI query key [RFC3986]. Shelby, et al. Expires January 8, 2017 [Page 37] =0C Internet-Draft CoRE Resource Directory July 2016 Initial entries in this sub-registry are as follows: +-----------+-------+---------------+-------------------------------+ | Name | Query | Validity | Description | +-----------+-------+---------------+-------------------------------+ | Endpoint | ep | | Name of the endpoint, max 63 | | Name | | | bytes | | Lifetime | lt | 60-4294967295 | Lifetime of the registration | | | | | in seconds | | Domain | d | | Domain to which this endpoint | | | | | belongs | | Endpoint | et | | Semantic name of the endpoint | | Type | | | | | Context | con | URI | The scheme, address and port | | | | | at which this server is | | | | | available | | Resource | res | | Name of the resource | | Name | | | | | Group | gp | | Name of a group in the RD | | Name | | | | | Page | page | Integer | Used for pagination | | Count | count | Integer | Used for pagination | | Resource | ins | | Instance Identifier | | Instance | | | | | Export | exp | | A link MAY be exported to | | | | | another Resource Directory | +-----------+-------+---------------+-------------------------------+ Table 1: RD Parameters The IANA policy for future additions to the sub-registry is "Expert Review" as described in [RFC5226]. 13. Examples Examples are added here. 13.1. Lighting Installation This example shows a simplified lighting installation which makes use of the Resource Directory (RD) with a CoAP interface to facilitate the installation and start up of the application code in the lights and sensors. In particular, the example leads to the definition of a group and the enabling of the corresponding multicast address. No conclusions must be drawn on the realization of actual installation or naming procedures, because the example only "emphasizes" some of the issues that may influence the use of the RD and does not pretend to be normative. Shelby, et al. Expires January 8, 2017 [Page 38] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.1. Installation Characteristics The example assumes that the installation is managed. That means that a Commissioning Tool (CT) is used to authorize the addition of nodes, name them, and name their services. The CT can be connected to the installation in many ways: the CT can be part of the installation network, connected by WiFi to the installation network, or connected via GPRS link, or other method. It is assumed that there are two naming authorities for the installation: (1) the network manager that is responsible for the correct operation of the network and the connected interfaces, and (2) the lighting manager that is responsible for the correct functioning of networked lights and sensors. The result is the existence of two naming schemes coming from the two managing entities. The example installation consists of one presence sensor, and two luminaries, luminary1 and luminary2, each with their own wireless interface. Each luminary contains three lamps: left, right and middle. Each luminary is accessible through one endpoint. For each lamp a resource exists to modify the settings of a lamp in a luminary. The purpose of the installation is that the presence sensor notifies the presence of persons to a group of lamps. The group of lamps consists of: middle and left lamps of luminary1 and right lamp of luminary2. Before commissioning by the lighting manager, the network is installed and access to the interfaces is proven to work by the network manager. At the moment of installation, the network under installation is not necessarily connected to the DNS infra structure. Therefore, SLAAC IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in Table 2 below: +--------------------+--------------+ | Name | IPv6 address | +--------------------+--------------+ | luminary1 | FDFD::ABCD:1 | | luminary2 | FDFD::ABCD:2 | | Presence sensor | FDFD::ABCD:3 | | Resource directory | FDFD::ABCD:0 | +--------------------+--------------+ Table 2: interface SLAAC addresses Shelby, et al. Expires January 8, 2017 [Page 39] =0C Internet-Draft CoRE Resource Directory July 2016 In Section 13.1.2 the use of resource directory during installation is presented. In Section 13.1.3 the connection to DNS is discussed. 13.1.2. RD entries It is assumed that access to the DNS infrastructure is not always possible during installation. Therefore, the SLAAC addresses are used in this section. For discovery, the resource types (rt) of the devices are important. The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor. The endpoints have names which are relevant to the light installation manager. In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door. The endpoint names reflect this physical location. The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively. The identifiers relevant to the Resource Directory are shown in Table 3 below: +----------------+------------------+---------------+---------------+ | Name | endpoint | resource path | resource type | +----------------+------------------+---------------+---------------+ | luminary1 | lm_R2-4-015_wndw | /light/left | light | | luminary1 | lm_R2-4-015_wndw | /light/middle | light | | luminary1 | lm_R2-4-015_wndw | /light/right | light | | luminary2 | lm_R2-4-015_door | /light/left | light | | luminary2 | lm_R2-4-015_door | /light/middle | light | | luminary2 | lm_R2-4-015_door | /light/right | light | | Presence | ps_R2-4-015_door | /ps | p-sensor | | sensor | | | | +----------------+------------------+---------------+---------------+ Table 3: Resource Directory identifiers The CT inserts the endpoints of the luminaries and the sensor in the RD using the Context parameter (con) to specify the interface address: Shelby, et al. Expires January 8, 2017 [Page 40] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_wndw&con=3Dcoap://[FDFD::ABCD:1] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light";d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4521 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:2] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4522 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dps_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:3] Payload: ;rt=3D"p-sensor"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4523 The domain name d=3D"R2-4-015" has been added for an efficient lookup because filtering on "ep" name is more awkward. The same domain name is communicated to the two luminaries and the presence sensor by the CT. The group is specified in the RD. The Context parameter is set to the site-local multicast address allocated to the group. In the POST in the example below, these two endpoints and the endpoint of the presence sensor are registered as members of the group. Req: POST coap://[FDFD::ABCD:0]/rd-group ?gp=3Dgrp_R2-4-015;con=3D"coap//[FF05::1]";exp;ins=3D"grp1234" Payload: <>ep=3Dlm_R2-4-015_wndw, <>ep=3Dlm_R2-4-015_door, <>ep=3Dps_R2-4-015_door Res: 2.01 Created Location: /rd-group/501 Shelby, et al. Expires January 8, 2017 [Page 41] =0C Internet-Draft CoRE Resource Directory July 2016 After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. The luminary, knowing its domain, queries the RD for the endpoint with rt=3Dlight and d=3DR2-4-015. The RD returns all endpoints in = the domain. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep ?d=3DR2-4-015;rt=3Dlight Res: 2.05 Content ; ep=3D"lm_R2-4-015_wndw", ; ep=3D"lm_R2-4-015_door" Knowing its own IPv6 address, the luminary discovers its endpoint name. With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp ?ep=3Dlm_R2-4-015_wndw Res: 2.05 Content ;gp=3D"grp_R2-4-015" =46rom the context parameter value, the luminary learns the multicast address of the multicast group. Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in [RFC7390]. Req: POST //[FDFD::ABCD:1]/coap-group Content-Format: application/coap-group+json { "a": "[FF05::1]", "n": "grp_R2-4-015"} Res: 2.01 Created Location-Path: /coap-group/1 Dependent on the situation only the address ,"a", or the name, "n", is specified in the coap-group resource. Shelby, et al. Expires January 8, 2017 [Page 42] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.3. DNS entries It may be profitable to discover the light groups for applications, which are unaware ot the existence of the RD. An agent needs to query the RD to return all groups which are exported to be inserted into DNS. Req: GET /rd-lookup/gp?exp Res: 2.05 Content ;exp;gp=3D"grp_R2-4-015;ins=3D"grp1234"; ep=3D"lm_R2-4-015_wndw"; ep=3D"lm_R2-4-015_door The group with FQDN grp_R2-4-015.bc.example.com can be entered into the DNS by the agent. The accompanying instance name is grp1234. The is chosen to be _group._udp. The agent enters the following RRs into the DNS. grp_R2-4-015.bc.example.com. IN AAAA FF05::1 _group._udp.bc.example.com IN PTR grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com IN SRV 0 0 5683 grp_R2-4-015_door.bc.example.com. grp1234._group._udp.bc.example.com IN TXT txtver=3D1;path=3D/light/grp1 =46rom then on applications, not familiar with the existence of the = RD, can use DNS to access the lighting group. 13.2. OMA Lightweight M2M (LWM2M) Example This example shows how the OMA LWM2M specification makes use of Resource Directory (RD). OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority). LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing a Resource Directory along with other LWM2M interfaces defined by the LWM2M specification. CoRE Resource Directory (RD) is used to provide the LWM2M Registration interface. Shelby, et al. Expires January 8, 2017 [Page 43] =0C Internet-Draft CoRE Resource Directory July 2016 LWM2M does not provide for registration domains and does not currently use the rd-group or rd-lookup interfaces. The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server. Other interfaces, proxies, applications, and function sets are currently out of scope for LWM2M. The location of the LWM2M Server and RD Function Set is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD function set is used. LWM2M Servers and endpoints are not required to implement the ./well-known/core resource. 13.2.1. The LWM2M Object Model The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. An LWM2M Object is a resource template and container type that encapsulates a set of related resources. An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings. base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined". As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". [_TEMPLATE_TODO] Shelby, et al. Expires January 8, 2017 [Page 44] =0C Internet-Draft CoRE Resource Directory July 2016 base-uri :=3D Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id :=3D OMNA (OMA Name Authority) registered object ID = (0-65535) object-instance :=3D Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id :=3D OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance :=3D Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings. For example, a LWM2M URI might be: /1/0/1 The base uri is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined". This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 13.2.2. LWM2M Register Endpoint LWM2M defines a registration interface based on the Resource Directory Function Set, described in Section 6. The URI of the LWM2M Resource Directory function set is specified to be "/rd" as recommended in Section 6.3. LWM2M endpoints register object IDs, for example , to indicate that a particular object type is supported, and register object instances, for example , to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format. Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. Shelby, et al. Expires January 8, 2017 [Page 45] =0C Internet-Draft CoRE Resource Directory July 2016 When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in Table 1 : ep - Endpoint Name lt - registration lifetime Endpoint Name is mandatory, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 4: LWM2M Additional Registration Parameters The following RD registration parameters are not currently specified for use in LWM2M: et - Endpoint Type con - Context The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: ,,, This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. Shelby, et al. Expires January 8, 2017 [Page 46] =0C Internet-Draft CoRE Resource Directory July 2016 13.2.3. Alternate Base URI If the LWM2M endpoint exposes objects at a base URI other than the default empty base path, the endpoint must register the base URI using rt=3D"oma.lwm2m". An example link payload using alternate base URI would be: ;rt=3D"oma.lwm2m",,, This link payload indicates that the lwm2m objects will be placed under the base URI "/my_lwm2m" and that object ID 1 (server) is supported, with a single instance 0 existing, and object 5 (firmware update) is supported. 13.2.4. LWM2M Update Endpoint Registration An LWM2M Registration update proceeds as described in Section 6.4, and adds some optional parameter updates: lt - Registration Lifetime b - Protocol Binding sms - MSISDN link payload - new or modified links A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. 13.2.5. LWM2M De-Register Endpoint LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation. LWM2M de- registration proceeds as described in Section 6.5. 14. Acknowledgments Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided helpful comments, discussions and ideas to improve and shape this document. Section 9 is based on an earlier draft by Kerry Lynn. Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. Shelby, et al. Expires January 8, 2017 [Page 47] =0C Internet-Draft CoRE Resource Directory July 2016 15. Changelog changes from -07 to -08 o removed link target value returned from domain and group lookup types o Maximum length of domain parameter 63 bytes for consistency with group o removed option for simple POST of link data, don't require a .well-known/core resource to accept POST data and handle it in a special way; we already have /rd for that o add IPv6 ND Option for discovery of an RD o clarify group configuration section 6.1 that endpoints must be registered before including them in a group o removed all superfluous client-server diagrams o simplified lighting example o introduced Commissioning Tool o RD-Look-up text is extended. changes from -06 to -07 o added text in the discovery section to allow content format hints to be exposed in the discovery link attributes o editorial updates to section 9 o update author information o minor text corrections Changes from -05 to -06 o added note that the PATCH section is contingent on the progress of the PATCH method changes from -04 to -05 o added Update Endpoint Links using PATCH o http access made explicit in interface specification Shelby, et al. Expires January 8, 2017 [Page 48] =0C Internet-Draft CoRE Resource Directory July 2016 o Added http examples Changes from -03 to -04: o Added http response codes o Clarified endpoint name usage o Add application/link-format+cbor content-format Changes from -02 to -03: o Added an example for lighting and DNS integration o Added an example for RD use in OMA LWM2M o Added Read Links operation for link inspection by endpoints o Expanded DNS-SD section o Added draft authors Peter van der Stok and Michael Koster Changes from -01 to -02: o Added a catalogue use case. o Changed the registration update to a POST with optional link format payload. Removed the endpoint type update from the update. o Additional examples section added for more complex use cases. o New DNS-SD mapping section. o Added text on endpoint identification and authentication. o Error code 4.04 added to Registration Update and Delete requests. o Made 63 bytes a SHOULD rather than a MUST for endpoint name and resource type parameters. Changes from -00 to -01: o Removed the ETag validation feature. o Place holder for the DNS-SD mapping section. o Explicitly disabled GET or POST on returned Location. Shelby, et al. Expires January 8, 2017 [Page 49] =0C Internet-Draft CoRE Resource Directory July 2016 o New registry for RD parameters. o Added support for the JSON Link Format. o Added reference to the Groupcomm WG draft. Changes from -05 to WG Document -00: o Updated the version and date. Changes from -04 to -05: o Restricted Update to parameter updates. o Added pagination support for the Lookup interface. o Minor editing, bug fixes and reference updates. o Added group support. o Changed rt to et for the registration and update interface. Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten. o Editorial improvements. o Fixed the use of ETags. o Fixed tickets 383 and 372 Changes from -02 to -03: o Changed the endpoint name back to a single registration parameter ep=3D and removed the h=3D and ins=3D parameters. o Updated REST interface descriptions to use RFC6570 URI Template format. o Introduced an improved RD Lookup design as its own function set. o Improved the security considerations section. o Made the POST registration interface idempotent by requiring the ep=3D parameter to be present. Shelby, et al. Expires January 8, 2017 [Page 50] =0C Internet-Draft CoRE Resource Directory July 2016 Changes from -01 to -02: o Added a terminology section. o Changed the inclusion of an ETag in registration or update to a MAY. o Added the concept of an RD Domain and a registration parameter for it. o Recommended the Location returned from a registration to be stable, allowing for endpoint and Domain information to be changed during updates. o Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 16. References 16.1. Normative References [I-D.ietf-core-links-json] Li, K., Rahman, A., and D. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-05 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . Shelby, et al. Expires January 8, 2017 [Page 51] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . 16.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Shelby, et al. Expires January 8, 2017 [Page 52] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . Editorial Comments [_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert. Authors' Addresses Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Michael Koster SmartThings 665 Clyde Avenue Mountain View 94043 USA Phone: +1-707-502-5136 Email: Michael.Koster@smartthings.com Shelby, et al. Expires January 8, 2017 [Page 53] =0C Internet-Draft CoRE Resource Directory July 2016 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Shelby, et al. Expires January 8, 2017 [Page 54] --Apple-Mail=_A66632D9-2056-410E-A9D8-F6AFC6754561 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_A66632D9-2056-410E-A9D8-F6AFC6754561-- From nobody Fri Jul 8 07:16:24 2016 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 BF3D312D518 for ; Fri, 8 Jul 2016 07:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 xhSpfZ-fMFmV for ; Fri, 8 Jul 2016 07:16:17 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 E5AF912B05A for ; Fri, 8 Jul 2016 07:16:16 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c2so13611894pfa.2 for ; Fri, 08 Jul 2016 07:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=o97FaGCe3BsP1Mz8TKiGtax9ElHLtDlUr7wX+VEvOx8=; b=HypsWOSEG8lKIz1CO67I84WbW39WTFgqqqkV+qQMkorxmXFO71gsPoJTv/agUciIry xBekPiBUR79d7AxbccVaLcfM1M1EcUGTELKoqfcGDq1kMXYDDTsgDILtQuiMLsENdSDx YH4evOPL4WixX2xsZxuV/8KZtpn10ufGbRZrCf86maGSL/AKPeDg6hf337nbWrlVmo53 DOfE9zygwkbyMxIJBZCzf3mrdjWkyZ/ri3AdHt/zIiU5T77UXPIZon23F1oVUp5HuzvI qEL/yoeD2f9f7nHSf6kCWfWAH+fVIv4desZ2cHHsxIzcgSLZnORm4NBpRssmN36JsD30 IIZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=o97FaGCe3BsP1Mz8TKiGtax9ElHLtDlUr7wX+VEvOx8=; b=ITkL4GMlyy23gFMpY1vN0ZqhkNCr/g20UY4opn+vQMJMEKmvCW1c31M46slr7cNxX+ VhC1ubAI01SGLu9P0d6ljg7ZX1HqcnxzJItMAWLnW2NHMKva/3y1TvepObJn5TDxsIjE 8pUCflTiqQQUoa0iik7kBSdVVu8yOJUwlImJ2ZQZCaKXbuIZlullVNJ80MwtswhsXEzd 2H7YzKZWTnmGWSmGDKfu0a3MYPUovCiNSNg21m3scqCKTJNe9fqNTE1WkUFh0z8gegI8 shW3rQJHfIIpSk39g9gJ5ehYvVU1aHm5m7qrwYNaPJxB1NuFqO45xUPFxMLDLnzoFg/s /ehg== X-Gm-Message-State: ALyK8tKatUt/U2ypxlVuh8zhq/g2ztcJ4DWuzscsmDKjqGuPvCp37fBqpQ8ciowwMAp2T7B8 X-Received: by 10.98.25.66 with SMTP id 63mr10478999pfz.94.1467987376402; Fri, 08 Jul 2016 07:16:16 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id g189sm4906013pfc.46.2016.07.08.07.16.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 07:16:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_914BB970-8729-4CDC-A478-D2773D077815" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <42487053-B0F9-47C2-A7AE-7620EFECEBCA@smartthings.com> Date: Fri, 8 Jul 2016 07:16:08 -0700 Message-Id: <5842B777-85BC-4BAF-850B-1C6F9978801C@smartthings.com> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> <3a09b9ae09badf97951adc0e8983ebdf@xs4all.nl> <42487053-B0F9-47C2-A7AE-7620EFECEBCA@smartthings.com> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-core-resource-directory@tools.ietf.org, Oscar Novo , "core@ietf.org WG" , Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 14:16:23 -0000 --Apple-Mail=_914BB970-8729-4CDC-A478-D2773D077815 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here's another update. I went through and made the Content-Format = options in the examplr consistent. The CoAP ecamples are Content-Format = with numeric types where there is a type assigned, and the HTTP examples = use Content-Type and a media type string. When referring to Content = Formats in general, I use the string for human readability. > On Jul 8, 2016, at 7:06 AM, Michael Koster = wrote: >=20 > Hi, >=20 > comments below=20 >> On Jul 8, 2016, at 3:35 AM, peter van der Stok = wrote: >>=20 >> Hi Matthias, >>=20 >>=20 >>> I did a quick review of the draft. I know you are quite swamped, but >>> maybe we can get some updates in before publishing: >>=20 >> Thanks, there is one point where I can be useful..... >>=20 >>> 4.1. Resource Directory Address Option (RDAO) >>> I am quite lost of the context here. There is only a quick hint in >>> the bullet point list in Section 4---best add parentheses and "see >>> ..." there. Otherwise it is unclear what kind of option you are >>> talking about. >>=20 >> In the bullets of section 4 it is mentioned see section 4.1; I = probably do not understand what you mean. >>=20 >>> It is the only location where "6LR" is used without explanation. >>> Furthermore, the endpoint could also be a 6LoWPAN host instead of a >>> router... >>=20 >> Right, 6LR should be endpoint. >=20 > Fixed. >=20 > Also addressed some of Matthias comments >=20 > --Apple-Mail=_914BB970-8729-4CDC-A478-D2773D077815 Content-Type: multipart/mixed; boundary="Apple-Mail=_ABD19AB8-011C-4B10-ADA1-B47E9441EB3C" --Apple-Mail=_ABD19AB8-011C-4B10-ADA1-B47E9441EB3C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Here's another update. I went through and made the Content-Format options in the examplr consistent. The CoAP ecamples are Content-Format with numeric types where there is a type assigned, and the HTTP examples use Content-Type and a media type string. When referring to Content Formats in general, I use the string for human readability.

--Apple-Mail=_ABD19AB8-011C-4B10-ADA1-B47E9441EB3C Content-Disposition: attachment; filename=draft-ietf-core-resource-directory-xx.txt Content-Type: text/plain; name="draft-ietf-core-resource-directory-xx.txt" Content-Transfer-Encoding: quoted-printable CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster Expires: January 8, 2017 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant July 07, 2016 CoRE Resource Directory draft-ietf-core-resource-directory-08 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 resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Shelby, et al. Expires January 8, 2017 [Page 1] =0C Internet-Draft CoRE Resource Directory July 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 4. Finding a Directory Server . . . . . . . . . . . . . . . . . 8 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 9 5. Simple Registration . . . . . . . . . . . . . . . . . . . . . 10 5.1. Simple publishing to Resource Directory Server . . . . . 11 5.2. Third-party registration . . . . . . . . . . . . . . . . 12 6. Resource Directory Function Set . . . . . . . . . . . . . . . 12 6.1. Content Formats . . . . . . . . . . . . . . . . . . . . . 13 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Registration . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Registration Update . . . . . . . . . . . . . . . . . . . 17 6.5. Registration Removal . . . . . . . . . . . . . . . . . . 20 6.6. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 21 6.7. Update Endpoint Links . . . . . . . . . . . . . . . . . . 22 7. Group Function Set . . . . . . . . . . . . . . . . . . . . . 24 7.1. Register a Group . . . . . . . . . . . . . . . . . . . . 24 7.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 26 8. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 27 9. New Link-Format Attributes . . . . . . . . . . . . . . . . . 31 9.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 31 9.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 32 10. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. DNS-based Service discovery . . . . . . . . . . . . . . 32 10.2. mapping ins to . . . . . . . . . . . . . . . 33 10.3. Mapping rt to . . . . . . . . . . . . . . 34 10.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 34 Shelby, et al. Expires January 8, 2017 [Page 2] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings . . . . . . . . . . . . . . = 35 10.6. Importing resource links into DNS-SD . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11.1. Endpoint Identification and Authentication . . . . . . . 36 11.2. Access Control . . . . . . . . . . . . . . . . . . . . . 36 11.3. Denial of Service Attacks . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 37 12.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 37 12.3. IPv6 ND Resource Directory Address Option . . . . . . . 37 12.4. RD Parameter Registry . . . . . . . . . . . . . . . . . 37 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 13.1. Lighting Installation . . . . . . . . . . . . . . . . . 38 13.1.1. Installation Characteristics . . . . . . . . . . . . 39 13.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 40 13.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 43 13.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 43 13.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 44 13.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 45 13.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 47 13.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 47 13.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 47 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 16.1. Normative References . . . . . . . . . . . . . . . . . . 51 16.2. Informative References . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Linking [RFC5988]. The use of Web Linking for the description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format [RFC6690]. However, [RFC6690] only describes how to discover resources from the web server that hosts them by requesting "/.well-known/core". In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast Shelby, et al. Expires January 8, 2017 [Page 3] =0C Internet-Draft CoRE Resource Directory July 2016 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 a Resource Directory are defined. Although the examples in this document show the use of these interfaces with CoAP [RFC7252], they can be applied in an equivalent manner to HTTP [RFC7230]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "byte" is used in its now customary sense as a synonym for "octet". This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252]. To describe the REST interfaces defined in this specification, the URI Template format is used [RFC6570]. This specification makes use of the following additional terminology: Resource Directory A web entity that stores information about web resources and implements the REST interfaces defined in this specification for registration and lookup of those resources. Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Group In the context of a Resource Directory, a group is a logical grouping of endpoints for the purpose of group communications. All groups within a domain are unique. Endpoint Shelby, et al. Expires January 8, 2017 [Page 4] =0C Internet-Draft CoRE Resource Directory July 2016 Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. 3. Architecture and Use Cases The resource directory architecture is illustrated in Figure 1. A Resource Directory (RD) is used as a repository for Web Links [RFC5988] about resources hosted on other web servers, which are called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory entries), and for clients to lookup resources from the RD or maintain groups. Endpoints themselves can also act as clients. An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured by an outside entity. This information hierarchy is shown in Figure 2. Endpoints are assumed to proactively register and maintain resource directory entries on the RD, which are soft state and need to be periodically refreshed. An endpoint is provided with interfaces to register, update and remove a resource directory entry. Furthermore, a mechanism to discover an RD using the CoRE Link Format [RFC6690] is defined. It is also possible for an RD to proactively discover Web Links from endpoints and add them as resource directory entries. A lookup interface for discovering any of the Web Links held in the RD is provided using the CoRE Link Format. Shelby, et al. Expires January 8, 2017 [Page 5] =0C Internet-Draft CoRE Resource Directory July 2016 Registration Lookup, Group Interface Interfaces +----+ | | | EP |---- | | +----+ ---- | | --|- +------+ | +----+ | ----| | | +--------+ | EP | ---------|-----| RD |----|-----| Client | +----+ | ----| | | +--------+ --|- +------+ | +----+ ---- | | | EP |---- | | +----+ Figure 1: The resource directory architecture. +------------+ | Domain | <-- Name +------------+ | | | +------------+ | | Group | <-- Name, Scheme, IP, Port | +------------+ | | +------------+ | Endpoint | <-- Name, Scheme, IP, Port +------------+ | | +------------+ | Resource | <-- Target, Parameters +------------+ Figure 2: The resource directory information hierarchy. 3.1. Use Case: Cellular M2M Over the last few years, mobile operators around the world have focused on development of M2M solutions in order to expand the business to the new type of users: machines. The machines are connected directly to a mobile network using an appropriate embedded air interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and wide range wireless interfaces. =46rom the system design point = of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application Shelby, et al. Expires January 8, 2017 [Page 6] =0C Internet-Draft CoRE Resource Directory July 2016 requirements, thus avoiding silo like solutions. One of the crucial enablers of such design is the ability to discover resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities. Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs. The address of each (proxy) endpoint on this server is included in the resource description stored in the RD. The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database. Similarly, fleet management systems provide the appropriate link parameters to the RD to look up for EPs deployed on the vehicles the application is responsible for. 3.2. Use Case: Home and Building Automation Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. The exporting of resource information to other discovery systems is also important in these automation applications. In home automation there is a need to interact with other consumer electronics, which may already support DNS-SD, and in building automation DNS-SD in combination with resource directories can cover multiple buildings. 3.3. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted Shelby, et al. Expires January 8, 2017 [Page 7] =0C Internet-Draft CoRE Resource Directory July 2016 anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use the Resource Directory lookup function set to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in web link compatible representations are supplied by Resource Directories, which may be internally stored as triples, or relation/attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to common web linking formats for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms should generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. This provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. 4. Finding a Directory Server Endpoints that want to contact a directory server can obtain candidate IP addresses for such servers in a number of ways. In a 6LoWPAN, good candidates can be taken from: o specific static configuration (e.g., anycast addresses), if any, o the ABRO option of 6LoWPAN-ND [RFC6775], o other ND options that happen to point to servers (such as RDNSS), o DHCPv6 options that might be defined later. o The IPv6 Neighbor Discovery Resource Directory Address Option Section 4.1 Shelby, et al. Expires January 8, 2017 [Page 8] =0C Internet-Draft CoRE Resource Directory July 2016 In networks with more inexpensive use of multicast, the candidate IP address may be a well-known multicast address, i.e. directory servers are found by simply sending GET requests to that well-known multicast address (see Section 6.2). As some of these sources are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate- limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. 4.1. Resource Directory Address Option (RDAO) The Resource Directory Option (RDAO) using IPv6 neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with link-local multicast address because the endpoint and the RD are separated by a border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network. The presence and the use of the RD is essential during commissioning. The RDAO format is: Shelby, et al. Expires January 8, 2017 [Page 9] =0C Internet-Draft CoRE Resource Directory July 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length =3D 3 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RD Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 38 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this set of border router information is valid. A value of all zero bits (0x0) assumes a default value of 10,000 (~one week). Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. RD Address: IPv6 address of the RD. Figure 3: Resource Directory Address Option 5. Simple Registration Not all endpoints hosting resources are expected to know how to implement the Resource Directory Function Set (see Section 6) hence cannot register with a Resource Directory. Instead, simple endpoints can implement the generic Simple Directory Discovery approach described in this section. An RD implementing this specification MUST implement Simple Directory Discovery. However, there may be Shelby, et al. Expires January 8, 2017 [Page 10] =0C Internet-Draft CoRE Resource Directory July 2016 security reasons why this form of directory discovery would be disabled. This approach requires that the endpoint makes available the hosted resources that it wants to be discovered, as links on its "/.well- known/core" interface as specified in [RFC6690]. The endpoint then finds one or more addresses of the directory server as described in Section 4. An endpoint can send (a selection of) hosted resources to a directory server for publication as described in Section 5.1. The directory server integrates the information it received this way into its resource directory. It MAY make the information available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 5.1. Simple publishing to Resource Directory Server An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. The endpoint MAY include registration parameters in the POST request as per Section 6.3 The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. Shelby, et al. Expires January 8, 2017 [Page 11] =0C Internet-Draft CoRE Resource Directory July 2016 Req:(to RD server from [ff02::1]) POST coap://rd.example.com/.well-known/core?lt=3D6000 Content-Format: 40 payload: (empty payload) Res: 2.04 Changed (later) Req: (from RD server to [ff02::1]) GET coap://[ff02::1]/.well-known/core Accept: 40 Res: 2.05 Content payload: 5.2. Third-party registration For some applications, even Simple Directory Discovery may be too taxing for certain very constrained devices, in particular if the security requirements become too onerous. In a controlled environment (e.g. building control), the Resource Directory can be filled by a third device, called a commissioning tool. The commissioning tool can fill the Resource Directory from a database or other means. For that purpose the scheme, IP address and port of the registered device is indicated in the Context parameter of the registration Section 6.3. 6. Resource Directory Function Set This section defines the REST interfaces between an RD and endpoints, which is called the Resource Directory Function Set. Although the examples throughout this section assume the use of CoAP [RFC7252], these REST interfaces can also be realized using HTTP [RFC7230]. In all definitions in this section, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces defined in this section. Shelby, et al. Expires January 8, 2017 [Page 12] =0C Internet-Draft CoRE Resource Directory July 2016 Resource directory entries are designed to be easily exported to other discovery mechanisms such as DNS-SD. For that reason, parameters that would meaningfully be mapped to DNS SHOULD be limited to a maximum length of 63 bytes. 6.1. Content Formats Resource Directory implementations using this specification MUST support the application/link-format content format (ct=3D40). Resource Directories implementing this specification MAY support additional content formats. Any additional content format supported by a Resource Directory implementing this specification MUST have an equivalent serialization in the application/link-format content format. 6.2. Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the path of its RD Function Set. There can be several mechanisms for discovering the RD including assuming a default location (e.g. on an Edge Router in a LoWPAN), by assigning an anycast address to the RD, using DHCP, or by discovering the RD using the CoRE Link Format (see also Section 4). This section defines discovery of the RD using the well-known interface of the CoRE Link Format [RFC6690] as the required mechanism. It is however expected that RDs will also be discoverable via other methods depending on the deployment. Discovery of the RD function set is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup" is used to discover the RD Lookup Function Set. Upon success, the response will contain a payload with a link format entry for each RD discovered, with the URL indicating the root resource of the RD. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link attribute, as shown in the example below. Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. Shelby, et al. Expires January 8, 2017 [Page 13] =0C Internet-Draft CoRE Resource Directory July 2016 HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. An RD implementation of this specification MUST support query filtering for the rt parameter as defined in [RFC6690]. The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt :=3D Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : YES (Unicast only) The following example shows an endpoint discovering an RD using this interface, thus learning that the base RD resource is, in this Shelby, et al. Expires January 8, 2017 [Page 14] =0C Internet-Draft CoRE Resource Directory July 2016 example, at /rd and that the content_format delivered by the server hosting the resource is application.xml (ct=3D40). Note that it is = up to the RD to choose its base RD resource, although diagnostics and debugging is facilitated by using the base paths specified here where possible. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup";ct=3D40, ;rt=3D"core.rd-group";ct=3D40 The following example shows the way of indicating multiple values for Content-Format codes. The Content-Format code attribute "ct" MAY include a space-separated sequence of Content-Format codes as specified in [RFC7252], indicating that multiple content-formats are available. The example below shows the required ct=3D40 = (application/ link-format) as well as a vendor-specific content format. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 21225", ;rt=3D"core.rd-lookup";ct=3D"40 21225", ;rt=3D"core.rd-group";ct=3D"40 21225" 6.3. Registration After discovering the location of an RD Function Set, an endpoint MAY register its resources using the registration interface. This interface accepts a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link- format+json), or CBOR CoRE Link Format (application/link-format+cbor) [I-D.ietf-core-links-json], along with query string parameters indicating the name of the endpoint, its domain and the lifetime of the registration. All parameters except the endpoint name are optional. It is expected that other specifications will define further parameters (see Section 12.4). The RD then creates a new resource or updates an existing resource in the RD and returns its location. An endpoint MUST use that location when refreshing registrations using this interface. Endpoint resources in the RD are kept active for the period indicated by the lifetime parameter. The endpoint is responsible for refreshing the entry within this period using either the registration or update interface. The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameter does not create multiple RD Shelby, et al. Expires January 8, 2017 [Page 15] =0C Internet-Draft CoRE Resource Directory July 2016 entries. A new registration may be created at any time to supercede an existing registration, replacing the registration parameters and links. The registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd :=3D RD Function Set path (mandatory). This is the path of = the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10). et :=3D Endpoint Type (optional). The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor Shelby, et al. Expires January 8, 2017 [Page 16] =0C Internet-Draft CoRE Resource Directory July 2016 The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new resource entry for the endpoint. This Location MUST be a stable identifier generated by the RD as it is used for all subsequent operations on this registration. The resource returned in the Location is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered links, including updating and deleting links. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. The resulting location /rd/4521 is just an example of an RD generated location. Req: POST coap://rd.example.com/rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 Req: POST /rd?ep=3Dnode1 HTTP/1.1 Host : example.com Content-Type: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 6.4. Registration Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the resource returned in the Location option in the response to the first registration. Shelby, et al. Expires January 8, 2017 [Page 17] =0C Internet-Draft CoRE Resource Directory July 2016 An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 6.3 ) if they have changed since the last registration or update. Parameters that have not changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in {registration}. Upon receiving an update request, an RD MUST reset the timeout for that endpoint and update the scheme, IP address and port of the endpoint, using the source address of the update, or the context ("con") parameter if present. If the lifetime parameter "lt" is included in the received update request, the RD MUST update the lifetime of the registration and set the timeout equal to the new lifetime. An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if both the target URI and relation type match. In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 6.7. The update registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. Optional. In the absence of this parameter the scheme of the protocol, source IP address and source port used to register are assumed. This parameter is Shelby, et al. Expires January 8, 2017 [Page 18] =0C Internet-Draft CoRE Resource Directory July 2016 compulsory when the directory is filled by a third party such as a commissioning tool. Content-Format: application/link-format (mandatory) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint updating its registration at an RD using this interface. Req: POST /rd/4521 Res: 2.04 Changed The following example shows an endpoint updating its registration with a new lifetime and context, changing an existing link, and adding a new link using this interface. With the initial registration the client set the following values: o lifetime (lt)=3D500 o context (con)=3Dcoap://local-proxy-old.example.com:5683 o resource=3D ;ct=3D41;rt=3D"foobar";if=3D"sensor" Shelby, et al. Expires January 8, 2017 [Page 19] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST /rd/4521?lt=3D600&con=3D"coap://local-proxy.example.com:5683"= Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-f";if=3D"sensor", ;ct=3D41;rt=3D"door";if=3D"sensor" Res: 2.04 Changed 6.5. Registration Removal Although RD entries have soft state and will eventually timeout after their lifetime, an endpoint SHOULD explicitly remove its entry from the RD if it knows it will no longer be available (for example on shut-down). This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. The removal request interface is specified as follows: Interaction: EP -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the endpoint from the RD. Shelby, et al. Expires January 8, 2017 [Page 20] =0C Internet-Draft CoRE Resource Directory July 2016 Req: DELETE /rd/4521 Res: 2.02 Deleted 6.6. Read Endpoint Links Some endpoints may wish to manage their links as a collection, and may need to read the current set of links in order to determine link maintenance operations. One or more links MAY be selected by using query filtering as specified in [RFC6690] Section 4.1 The read request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" upon success with an "application/link-format", "application/link-format+cbor", or "application/link-format+json" payload. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires January 8, 2017 [Page 21] =0C Internet-Draft CoRE Resource Directory July 2016 The following examples show successful read of the endpoint links from the RD. Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" 6.7. Update Endpoint Links [This section will be removed before or as a result of a working- group last-call if the PATCH methods do not achieve the same level of consensus as the present document.] A PATCH update adds, removes or changes links for the endpoint by including link update information in the payload of the update as a merge-patch+json format [RFC7396] document. One or more links are selected for update by using query filtering as specified in [RFC6690] Section 4.1 The query filter selects the links to be modified or deleted, by matching the query parameter values to the values of the link attributes. When the query parameters are not present in the request, the payload specifies links to be added to the target document. When the query parameters are present, the attribute names and values in the query parameters select one or more links on which to apply the PATCH operation. If an attribute name specified in the PATCH document exists in any the set of selected links, all occurrences of the attribute value in the target document MUST be updated using the value from the PATCH payload. If the attribute name is not present in any selected links, the attribute MUST be added to the links. The update request interface is specified as follows: Interaction: EP -> RD Method: PATCH URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 22] =0C Internet-Draft CoRE Resource Directory July 2016 location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 Content-Format: application/merge-patch+json (mandatory) The following response codes are defined for this interface: Success: 2.04 "Changed" 0r 204 "No Content" in the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration resource does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show an endpoint adding , modifying , and removing links in RD using the Update Endpoint Links function. The following example shows an EP adding the link ;ct=3D41;rt=3D"humid-s";if=3D"sensor" to the collection of = links at the location /rd/4521. Req: PATCH /rd/4521 Payload: [{"href":"/sensors/humid","ct": 41, "rt": "humid-s", "if": "sensor"}] Content-Format: application/merge-patch+json Res: 2.04 Changed The following example shows an EP modifying all links at the location /rd/4521 which are identified by href=3D"/sensors/temp", from the initial link-value of ;rt=3D"temperature" to the new link-value ;rt=3D"temperature-c";if=3D"sensor" by = changing Shelby, et al. Expires January 8, 2017 [Page 23] =0C Internet-Draft CoRE Resource Directory July 2016 the value of the link attribute "rt" and adding the link attribute if=3D"sensor" using the PATCH operation with the supplied merge- patch+json document payload. Req: PATCH /rd/4521?href=3D"/sensors/temp" Payload: {"rt": "temperature-c", "if": "sensor"}, Content-Format: application/merge-patch+json Res: 2.04 Changed This example shows an EP removing all links at the location /rd/4521 which are identified by href=3D"/sensors/light". Req: PATCH /rd/4521?href=3D"/sensors/light" Payload: {null} Content-Format: application/merge-patch+json Res: 2.04 Changed 7. Group Function Set This section defines a function set for the creation of groups of endpoints for the purpose of managing and looking up endpoints for group operations. The group function set is similar to the resource directory function set, in that a group may be created or removed. However unlike an endpoint entry, a group entry consists of a list of endpoints and does not have a lifetime associated with it. In order to make use of multicast requests with CoAP, a group MAY have a multicast address associated with it. 7.1. Register a Group In order to create a group, a commissioning tool (CT) used to configure groups, makes a request to the RD indicating the name of the group to create (or update), optionally the domain the group belongs to, and optionally the multicast address of the group. The registration message includes the list of endpoints that belong to that group. Shelby, et al. Expires January 8, 2017 [Page 24] =0C Internet-Draft CoRE Resource Directory July 2016 All the endpoints in the group MUST be registered with the RD before registering a group. If an endpoint is not yet registered to the RD before registering the group, the registration message returns an error. The RD sends a blank target URI for every endpoint link when registering the group. Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. The registration request interface is specified as follows: Interaction: CT -> RD Method: POST URI Template: /{+rd-group}{?gp,d,con} URI Template Variables: rd-group :=3D RD Group Function Set path (mandatory). This is = the path of the RD Group Function Set. An RD SHOULD use the value "rd-group" for this variable whenever possible. gp :=3D Group Name (mandatory). The name of the group to be created or replaced, unique within that domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this group = belongs. The maximum length of this parameter is 63 bytes. Optional. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10) con :=3D Context (optional). This parameter is used to set the = IP multicast address at which this server is available in the form scheme://multicast-address:port. Optional. In the absence of this parameter no multicast address is configured. This parameter is compulsory when the directory is filled by a commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 25] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new group entry. This Location MUST be a stable identifier generated by the RD as it is used for delete operations on this registration. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". An Endpoint is not registered in the RD (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface. The resulting location /rd-group/12 is just an example of an RD generated group location. Req: POST coap://rd.example.com/rd-group?gp=3Dlights Content-Format: 40 Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 2.01 Created Location: /rd-group/12 Req: POST /rd-group?gp=3Dlights HTTP/1.1 Host: example.com Content-Type: application/link-format Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 201 Created Location: /rd-group/12 7.2. Group Removal A group can be removed simply by sending a removal message to the location returned when registering the group. Removing a group MUST NOT remove the endpoints of the group from the RD. The removal request interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 26] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: CT -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful group registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the group from the RD. Req: DELETE /rd-group/12 Res: 2.02 Deleted 8. RD Lookup Function Set In order for an RD to be used for discovering resources registered with it, a lookup interface can be provided using this function set. This lookup interface is defined as a default, and it is assumed that RDs may also support lookups to return resource descriptions in alternative formats (e.g. Atom or HTML Link) or using more advanced interfaces (e.g. supporting context or semantic based lookup). This function set allows lookups for domains, groups, endpoints and resources using attributes defined in the RD Function Set and for use with the CoRE Link Format. The result of a lookup request is the list of links (if any) corresponding to the type of lookup. Thus, a domain lookup MUST return a list of domains, a group lookup MUST return a list of groups, an endpoint lookup MUST return a list of Shelby, et al. Expires January 8, 2017 [Page 27] =0C Internet-Draft CoRE Resource Directory July 2016 endpoints and a resource lookup MUST return a list of links to resources. Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. The target of these links SHOULD be the actual location of the domain, endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. The domain lookup returns every lookup domain with a "/rd" value encapsulated within angle brackets. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a "/rd-group" value encapsulated within angle brackets. Otherwise, the group lookup returns the multicast address of the group inside angle brackets. Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default) or its alternate content-formats ("application/link-format+json" or "application/link-format+cbor"). Multiple query parameters MAY be included in a lookup, all included parameters MUST match for a resource to be returned. The character'*' MAY be included at the end of a parameter value as a wildcard operator. The rd-lookup interface MAY use any set of query parameters to match the registered attributes and relations. In addition, this interface MAY be used with queries that specify domains, endpoints, and groups. For example, a domain lookup filtering on groups would return a list of domains that contain the specified groups. An endpoint lookup filtering on groups would return a list of endpoints that are in the specified groups. The lookup interface is specified as follows: Interaction: Client -> RD Method: GET URI Template: /{+rd-lookup-base}/{lookup- type}{?d,ep,gp,et,rt,page,count,resource-param} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 28] =0C Internet-Draft CoRE Resource Directory July 2016 rd-lookup-base :=3D RD Lookup Function Set path (mandatory). = This is the path of the RD Lookup Function Set. An RD SHOULD use the value "rd-lookup" for this variable whenever possible. lookup-type :=3D ("d", "ep", "res", "gp") (mandatory) This = variable is used to select the kind of lookup to perform (domain, endpoint, resource, or group). ep :=3D Endpoint name (optional). Used for endpoint, group and resource lookups. d :=3D Domain (optional). Used for domain, group, endpoint and resource lookups. res :=3D resource (optional). Used for domain, group, endpoint = and resource lookups. gp :=3D Group name (optional). Used for endpoint, group and resource lookups. page :=3D Page (optional). Parameter can not be used without the count parameter. Results are returned from result set in pages that contains 'count' results starting from index (page * count). count :=3D Count (optional). Number of results is limited to = this parameter value. If the parameter is not present, then an RD implementation specific default value SHOULD be used. rt :=3D Resource type (optional). Used for group, endpoint and resource lookups. et :=3D Endpoint type (optional). Used for group, endpoint and resource lookups. resource-param :=3D Link attribute parameters (optional). Any = link attribute as defined in Section 4.1 of [RFC6690], used for resource lookups. Content-Format: application/link-format (optional) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following responses codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 29] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.05 "Content" or 200 "OK" with an "application/link- format", "application/link-format+cbor", or "application/link- format+json" payload containing matching entries for the lookup. Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching entry is found for a unicast request. Failure: No error response to a multicast request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The examples in this section assume a CoAP host with IP address FDFD::123 and a default CoAP port 61616. HTTP hosts are possible and do not change the nature of the examples.\ The following example shows a client performing a resource lookup: Req: GET /rd-lookup/res?rt=3Dtemperature Res: 2.05 Content ;rt=3D"temperature" The following example shows a client performing an endpoint type lookup: Req: GET /rd-lookup/ep?et=3Dpower-node Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" The following example shows a client performing a domain lookup: Req: GET /rd-lookup/d Res: 2.05 Content <>;d=3D"domain1", <>;d=3D"domain2" The following example shows a client performing a group lookup for all groups: Shelby, et al. Expires January 8, 2017 [Page 30] =0C Internet-Draft CoRE Resource Directory July 2016 Req: GET /rd-lookup/gp Res: 2.05 Content <>;gp=3D"lights1";d=3D"example.com" <>;gp=3D"lights2";d=3D"ecample.com" The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rd-lookup/ep?gp=3Dlights1 Res: 2.05 Content ;ep=3D"node1", ;ep=3D"node2" The following example shows a client performing a lookup for all groups an endpoint belongs to: Req: GET /rd-lookup/gp?ep=3Dnode1 Res: 2.05 Content <>;gp=3D"lights1" 9. New Link-Format Attributes When using the CoRE Link Format to describe resources being discovered by or posted to a resource directory service, additional information about those resources is useful. This specification defines the following new attributes for use in the CoRE Link Format [RFC6690]: link-extension =3D ( "ins" "=3D" quoted-string ) ; Max 63 bytes link-extension =3D ( "exp" ) 9.1. Resource Instance attribute 'ins' The Resource Instance "ins" attribute is an identifier for this resource, which makes it possible to distinguish it from other similar resources. This attribute is similar in use to the portion of a DNS-SD record (see Section 10.1, and SHOULD be unique across resources with the same Resource Type attribute in the domain it is used. A Resource Instance might be a descriptive string like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID or iNumber. This attribute is used by a Resource Directory to distinguish between multiple instances of the same resource type within the directory. Shelby, et al. Expires January 8, 2017 [Page 31] =0C Internet-Draft CoRE Resource Directory July 2016 This attribute MUST be no more than 63 bytes in length. The resource identifier attribute MUST NOT appear more than once in a link description. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 9.2. Export attribute 'exp' The Export "exp" attribute is used as a flag to indicate that a link description MAY be exported by a resource directory to external directories. The CoRE Link Format is used for many purposes between CoAP endpoints. Some are useful mainly locally, for example checking the observability of a resource before accessing it, determining the size of a resource, or traversing dynamic resource structures. However, other links are very useful to be exported to other directories, for example the entry point resource to a functional service. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 10. DNS-SD Mapping CoRE Resource Discovery is intended to support fine-grained discovery of hosted resources, their attributes, and possibly other resource relations [RFC6690]. In contrast, service discovery generally refers to a coarse-grained resolution of an endpoint's IP address, port number, and protocol. Resource and service discovery are complementary in the case of large networks, where the latter can facilitate scaling. This document defines a mapping between CoRE Link Format attributes and DNS-Based Service Discovery [RFC6763] fields that permits discovery of CoAP services by either method. 10.1. DNS-based Service discovery DNS-Based Service Discovery (DNS-SD) defines a conventional method of configuring DNS PTR, SRV, and TXT resource records to facilitate discovery of services (such as CoAP servers in a subdomain) using the existing DNS infrastructure. This section gives a brief overview of DNS-SD; see [RFC6763] for a detailed specification. DNS-SD service names are limited to 255 octets and are of the form: Service Name =3D ... Shelby, et al. Expires January 8, 2017 [Page 32] =0C Internet-Draft CoRE Resource Directory July 2016 The service name is the label of SRV/TXT resource records. The SRV RR specifies the host and the port of the endpoint. The TXT RR provides additional information in the form of key/value pairs. The part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify servers or groups of servers. The part is composed of at least two labels. The first label of the pair is the application protocol name [RFC6335] preceded by an underscore character. The second label indicates the transport and is always "_udp" for UDP-based CoAP services. In cases where narrowing the scope of the search may be useful, these labels may be optionally preceded by a subtype name followed by the "_sub" label. An example of this more specific is "light._sub._dali._udp". A default part of the service name may be set at the factory or during the commissioning process. It SHOULD uniquely identify an instance of within a . Taken together, these three elements comprise a unique name for an SRV/ TXT record pair within the DNS subdomain. The granularity of a service name MAY be that of a host or group, or it could represent a particular resource within a CoAP server. The SRV record contains the host name (AAAA record name) and port of the service while protocol is part of the service name. In the case where a service name identifies a particular resource, the path part of the URI must be carried in a corresponding TXT record. A DNS TXT record is in practice limited to a few hundred octets in length, which is indicated in the resource record header in the DNS response message. The data consists of one or more strings comprising a key=3Dvalue pair. By convention, the first pair is txtver=3D (to support different versions of a service description). 10.2. mapping ins to The Resource Instance "ins" attribute maps to the part of a DNS-SD service name. It is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. However, to the extent that the "ins" attribute may be chosen to match the DNS host name of a service, it SHOULD use the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. Shelby, et al. Expires January 8, 2017 [Page 33] =0C Internet-Draft CoRE Resource Directory July 2016 The part of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can allow the device or service to be accessed in many cases without any manual configuration at all. The default name should be short and descriptive, and MAY include a collision-resistant substring such as the lower bits of the device's MAC address, serial number, fingerprint, or other identifier in an attempt to make the name relatively unique. DNS labels are currently limited to 63 octets in length and the entire service name may not exceed 255 octets. 10.3. Mapping rt to The resource type "rt" attribute is mapped into the part of a DNS-SD service name and SHOULD conform to the reg-rel-type production of the Link Format defined in Section 2 of [RFC6690]. The "rt" attribute MUST be composed of at least a single Net-Unicode text string, without underscore '_' or period '.' and limited to 15 octets in length, which represents the application protocol name. This string is mapped to the DNS-SD by prepending an underscore and appending a period followed by the "_udp" label. For example, rt=3D"dali" is mapped into "_dali._udp". The application protocol name may be optionally followed by a period and a service subtype name consisting of a Net-Unicode text string, without underscore or period and limited to 63 octets. This string is mapped to the DNS-SD by appending a period followed by the "_sub" label and then appending a period followed by the service type label pair derived as in the previous paragraph. For example, rt=3D"dali.light" is mapped into "light._sub._dali._udp". The resulting string is used to form labels for DNS-SD records which are stored directly in the DNS. 10.4. Domain mapping DNS domains may be derived from the "d" attribute. The domain attribute may be suffixed with the zone name of the authoritative DNS server to generate the domain name. The "ep" attribute is prefixed to the domain name to generate the FQDN to be stored into DNS with an AAAA RR. Shelby, et al. Expires January 8, 2017 [Page 34] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings A number of [RFC6763] key/value pairs are derived from link-format information, to be exported in the DNS-SD as key=3Dvalue strings in a TXT record ([RFC6763], Section 6.3). The resource is exported as key/value pair "path=3D". The Interface Description "if" attribute is exported as key/value pair "if=3D". The DNS TXT record can be further populated by importing any other resource description attributes as they share the same key=3Dvalue format specified in Section 6 of [RFC6763]. 10.6. Importing resource links into DNS-SD Assuming the ability to query a Resource Directory or multicast a GET (?exp) over the local link, CoAP resource discovery may be used to populate the DNS-SD database in an automated fashion. CoAP resource descriptions (links) can be exported to DNS-SD for exposure to service discovery by using the Resource Instance attribute as the basis for a unique service name, composed with the Resource Type as the , and registered in the correct . The agent responsible for exporting records to the DNS zone file SHOULD be authenticated to the DNS server. The following example shows an agent discovering a resource to be exported: Req: GET /rd-lookup/res?exp Res: 2.05 Content ; exp;rt=3D"dali.light";ins=3D"Spot"; d=3D"office";ep=3D"node1" The agent subsequently registers the following DNS-SD RRs, assuming a zone name "example.com" prefixed with "office": node1.office.example.com. IN AAAA FDFD::1234 _dali._udp.office.example.com IN PTR Spot._dali._udp.office.example.com light._sub._dali._udp.example.com IN PTR Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com IN SRV 0 0 5683 node1.office.example.com. Spot._dali._udp.office.example.com IN TXT txtver=3D1;path=3D/light/1 Shelby, et al. Expires January 8, 2017 [Page 35] =0C Internet-Draft CoRE Resource Directory July 2016 In the above figure the Service Name is chosen as Spot._dali._udp.office.example.com without the light._sub service prefix. An alternative Service Name would be: Spot.light._sub._dali._udp.office.example.com. 11. Security Considerations The security considerations as described in Section 7 of [RFC5988] and Section 6 of [RFC6690] apply. The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described in [RFC7252]. DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. 11.1. Endpoint Identification and Authentication An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. 11.2. Access Control Access control SHOULD be performed separately for the RD Function Set and the RD Lookup Function Set, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. 11.3. Denial of Service Attacks Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the Shelby, et al. Expires January 8, 2017 [Page 36] =0C Internet-Draft CoRE Resource Directory July 2016 request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than requests, RDs can unknowingly become part of a DDoS amplification attack. Therefore, it is RECOMMENDED that implementations ensure return routability. This can be done, for example by responding to wild card lookups only over DTLS or TLS or TCP. 12. IANA Considerations 12.1. Resource Types "core.rd", "core.rd-group" and "core.rd-lookup" resource types need to be registered with the resource type registry defined by [RFC6690]. 12.2. Link Extension The "exp" and "ins" attributes need to be registered when a future Web Linking link-extension registry is created (e.g. in RFC5988bis). 12.3. IPv6 ND Resource Directory Address Option This document registers one new ND option type under the subregistry "IPv6 Neighbor Discovery Option Formats": o Resource Directory address Option (38) 12.4. RD Parameter Registry This specification defines a new sub-registry for registration and lookup parameters called "RD Parameters" under "CoRE Parameters". Although this specification defines a basic set of parameters, it is expected that other standards that make use of this interface will define new ones. Each entry in the registry must include the human readable name of the parameter, the query parameter, validity requirements if any and a description. The query parameter MUST be a valid URI query key [RFC3986]. Shelby, et al. Expires January 8, 2017 [Page 37] =0C Internet-Draft CoRE Resource Directory July 2016 Initial entries in this sub-registry are as follows: +-----------+-------+---------------+-------------------------------+ | Name | Query | Validity | Description | +-----------+-------+---------------+-------------------------------+ | Endpoint | ep | | Name of the endpoint, max 63 | | Name | | | bytes | | Lifetime | lt | 60-4294967295 | Lifetime of the registration | | | | | in seconds | | Domain | d | | Domain to which this endpoint | | | | | belongs | | Endpoint | et | | Semantic name of the endpoint | | Type | | | | | Context | con | URI | The scheme, address and port | | | | | at which this server is | | | | | available | | Resource | res | | Name of the resource | | Name | | | | | Group | gp | | Name of a group in the RD | | Name | | | | | Page | page | Integer | Used for pagination | | Count | count | Integer | Used for pagination | | Resource | ins | | Instance Identifier | | Instance | | | | | Export | exp | | A link MAY be exported to | | | | | another Resource Directory | +-----------+-------+---------------+-------------------------------+ Table 1: RD Parameters The IANA policy for future additions to the sub-registry is "Expert Review" as described in [RFC5226]. 13. Examples Examples are added here. 13.1. Lighting Installation This example shows a simplified lighting installation which makes use of the Resource Directory (RD) with a CoAP interface to facilitate the installation and start up of the application code in the lights and sensors. In particular, the example leads to the definition of a group and the enabling of the corresponding multicast address. No conclusions must be drawn on the realization of actual installation or naming procedures, because the example only "emphasizes" some of the issues that may influence the use of the RD and does not pretend to be normative. Shelby, et al. Expires January 8, 2017 [Page 38] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.1. Installation Characteristics The example assumes that the installation is managed. That means that a Commissioning Tool (CT) is used to authorize the addition of nodes, name them, and name their services. The CT can be connected to the installation in many ways: the CT can be part of the installation network, connected by WiFi to the installation network, or connected via GPRS link, or other method. It is assumed that there are two naming authorities for the installation: (1) the network manager that is responsible for the correct operation of the network and the connected interfaces, and (2) the lighting manager that is responsible for the correct functioning of networked lights and sensors. The result is the existence of two naming schemes coming from the two managing entities. The example installation consists of one presence sensor, and two luminaries, luminary1 and luminary2, each with their own wireless interface. Each luminary contains three lamps: left, right and middle. Each luminary is accessible through one endpoint. For each lamp a resource exists to modify the settings of a lamp in a luminary. The purpose of the installation is that the presence sensor notifies the presence of persons to a group of lamps. The group of lamps consists of: middle and left lamps of luminary1 and right lamp of luminary2. Before commissioning by the lighting manager, the network is installed and access to the interfaces is proven to work by the network manager. At the moment of installation, the network under installation is not necessarily connected to the DNS infra structure. Therefore, SLAAC IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in Table 2 below: +--------------------+--------------+ | Name | IPv6 address | +--------------------+--------------+ | luminary1 | FDFD::ABCD:1 | | luminary2 | FDFD::ABCD:2 | | Presence sensor | FDFD::ABCD:3 | | Resource directory | FDFD::ABCD:0 | +--------------------+--------------+ Table 2: interface SLAAC addresses Shelby, et al. Expires January 8, 2017 [Page 39] =0C Internet-Draft CoRE Resource Directory July 2016 In Section 13.1.2 the use of resource directory during installation is presented. In Section 13.1.3 the connection to DNS is discussed. 13.1.2. RD entries It is assumed that access to the DNS infrastructure is not always possible during installation. Therefore, the SLAAC addresses are used in this section. For discovery, the resource types (rt) of the devices are important. The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor. The endpoints have names which are relevant to the light installation manager. In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door. The endpoint names reflect this physical location. The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively. The identifiers relevant to the Resource Directory are shown in Table 3 below: +----------------+------------------+---------------+---------------+ | Name | endpoint | resource path | resource type | +----------------+------------------+---------------+---------------+ | luminary1 | lm_R2-4-015_wndw | /light/left | light | | luminary1 | lm_R2-4-015_wndw | /light/middle | light | | luminary1 | lm_R2-4-015_wndw | /light/right | light | | luminary2 | lm_R2-4-015_door | /light/left | light | | luminary2 | lm_R2-4-015_door | /light/middle | light | | luminary2 | lm_R2-4-015_door | /light/right | light | | Presence | ps_R2-4-015_door | /ps | p-sensor | | sensor | | | | +----------------+------------------+---------------+---------------+ Table 3: Resource Directory identifiers The CT inserts the endpoints of the luminaries and the sensor in the RD using the Context parameter (con) to specify the interface address: Shelby, et al. Expires January 8, 2017 [Page 40] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_wndw&con=3Dcoap://[FDFD::ABCD:1] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light";d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4521 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:2] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4522 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dps_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:3] Payload: ;rt=3D"p-sensor"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4523 The domain name d=3D"R2-4-015" has been added for an efficient lookup because filtering on "ep" name is more awkward. The same domain name is communicated to the two luminaries and the presence sensor by the CT. The group is specified in the RD. The Context parameter is set to the site-local multicast address allocated to the group. In the POST in the example below, these two endpoints and the endpoint of the presence sensor are registered as members of the group. Req: POST coap://[FDFD::ABCD:0]/rd-group ?gp=3Dgrp_R2-4-015;con=3D"coap//[FF05::1]";exp;ins=3D"grp1234" Payload: <>ep=3Dlm_R2-4-015_wndw, <>ep=3Dlm_R2-4-015_door, <>ep=3Dps_R2-4-015_door Res: 2.01 Created Location: /rd-group/501 Shelby, et al. Expires January 8, 2017 [Page 41] =0C Internet-Draft CoRE Resource Directory July 2016 After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. The luminary, knowing its domain, queries the RD for the endpoint with rt=3Dlight and d=3DR2-4-015. The RD returns all endpoints in = the domain. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep ?d=3DR2-4-015;rt=3Dlight Res: 2.05 Content ; ep=3D"lm_R2-4-015_wndw", ; ep=3D"lm_R2-4-015_door" Knowing its own IPv6 address, the luminary discovers its endpoint name. With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp ?ep=3Dlm_R2-4-015_wndw Res: 2.05 Content ;gp=3D"grp_R2-4-015" =46rom the context parameter value, the luminary learns the multicast address of the multicast group. Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in [RFC7390]. Req: POST //[FDFD::ABCD:1]/coap-group Content-Format: application/coap-group+json { "a": "[FF05::1]", "n": "grp_R2-4-015"} Res: 2.01 Created Location-Path: /coap-group/1 Dependent on the situation only the address ,"a", or the name, "n", is specified in the coap-group resource. Shelby, et al. Expires January 8, 2017 [Page 42] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.3. DNS entries It may be profitable to discover the light groups for applications, which are unaware ot the existence of the RD. An agent needs to query the RD to return all groups which are exported to be inserted into DNS. Req: GET /rd-lookup/gp?exp Res: 2.05 Content ;exp;gp=3D"grp_R2-4-015;ins=3D"grp1234"; ep=3D"lm_R2-4-015_wndw"; ep=3D"lm_R2-4-015_door The group with FQDN grp_R2-4-015.bc.example.com can be entered into the DNS by the agent. The accompanying instance name is grp1234. The is chosen to be _group._udp. The agent enters the following RRs into the DNS. grp_R2-4-015.bc.example.com. IN AAAA FF05::1 _group._udp.bc.example.com IN PTR grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com IN SRV 0 0 5683 grp_R2-4-015_door.bc.example.com. grp1234._group._udp.bc.example.com IN TXT txtver=3D1;path=3D/light/grp1 =46rom then on applications, not familiar with the existence of the = RD, can use DNS to access the lighting group. 13.2. OMA Lightweight M2M (LWM2M) Example This example shows how the OMA LWM2M specification makes use of Resource Directory (RD). OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority). LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing a Resource Directory along with other LWM2M interfaces defined by the LWM2M specification. CoRE Resource Directory (RD) is used to provide the LWM2M Registration interface. Shelby, et al. Expires January 8, 2017 [Page 43] =0C Internet-Draft CoRE Resource Directory July 2016 LWM2M does not provide for registration domains and does not currently use the rd-group or rd-lookup interfaces. The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server. Other interfaces, proxies, applications, and function sets are currently out of scope for LWM2M. The location of the LWM2M Server and RD Function Set is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD function set is used. LWM2M Servers and endpoints are not required to implement the ./well-known/core resource. 13.2.1. The LWM2M Object Model The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. An LWM2M Object is a resource template and container type that encapsulates a set of related resources. An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings. base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined". As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". [_TEMPLATE_TODO] Shelby, et al. Expires January 8, 2017 [Page 44] =0C Internet-Draft CoRE Resource Directory July 2016 base-uri :=3D Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id :=3D OMNA (OMA Name Authority) registered object ID = (0-65535) object-instance :=3D Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id :=3D OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance :=3D Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings. For example, a LWM2M URI might be: /1/0/1 The base uri is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined". This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 13.2.2. LWM2M Register Endpoint LWM2M defines a registration interface based on the Resource Directory Function Set, described in Section 6. The URI of the LWM2M Resource Directory function set is specified to be "/rd" as recommended in Section 6.3. LWM2M endpoints register object IDs, for example , to indicate that a particular object type is supported, and register object instances, for example , to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format. Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. Shelby, et al. Expires January 8, 2017 [Page 45] =0C Internet-Draft CoRE Resource Directory July 2016 When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in Table 1 : ep - Endpoint Name lt - registration lifetime Endpoint Name is mandatory, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 4: LWM2M Additional Registration Parameters The following RD registration parameters are not currently specified for use in LWM2M: et - Endpoint Type con - Context The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: ,,, This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. Shelby, et al. Expires January 8, 2017 [Page 46] =0C Internet-Draft CoRE Resource Directory July 2016 13.2.3. Alternate Base URI If the LWM2M endpoint exposes objects at a base URI other than the default empty base path, the endpoint must register the base URI using rt=3D"oma.lwm2m". An example link payload using alternate base URI would be: ;rt=3D"oma.lwm2m",,, This link payload indicates that the lwm2m objects will be placed under the base URI "/my_lwm2m" and that object ID 1 (server) is supported, with a single instance 0 existing, and object 5 (firmware update) is supported. 13.2.4. LWM2M Update Endpoint Registration An LWM2M Registration update proceeds as described in Section 6.4, and adds some optional parameter updates: lt - Registration Lifetime b - Protocol Binding sms - MSISDN link payload - new or modified links A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. 13.2.5. LWM2M De-Register Endpoint LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation. LWM2M de- registration proceeds as described in Section 6.5. 14. Acknowledgments Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided helpful comments, discussions and ideas to improve and shape this document. Section 9 is based on an earlier draft by Kerry Lynn. Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. Shelby, et al. Expires January 8, 2017 [Page 47] =0C Internet-Draft CoRE Resource Directory July 2016 15. Changelog changes from -07 to -08 o removed link target value returned from domain and group lookup types o Maximum length of domain parameter 63 bytes for consistency with group o removed option for simple POST of link data, don't require a .well-known/core resource to accept POST data and handle it in a special way; we already have /rd for that o add IPv6 ND Option for discovery of an RD o clarify group configuration section 6.1 that endpoints must be registered before including them in a group o removed all superfluous client-server diagrams o simplified lighting example o introduced Commissioning Tool o RD-Look-up text is extended. changes from -06 to -07 o added text in the discovery section to allow content format hints to be exposed in the discovery link attributes o editorial updates to section 9 o update author information o minor text corrections Changes from -05 to -06 o added note that the PATCH section is contingent on the progress of the PATCH method changes from -04 to -05 o added Update Endpoint Links using PATCH o http access made explicit in interface specification Shelby, et al. Expires January 8, 2017 [Page 48] =0C Internet-Draft CoRE Resource Directory July 2016 o Added http examples Changes from -03 to -04: o Added http response codes o Clarified endpoint name usage o Add application/link-format+cbor content-format Changes from -02 to -03: o Added an example for lighting and DNS integration o Added an example for RD use in OMA LWM2M o Added Read Links operation for link inspection by endpoints o Expanded DNS-SD section o Added draft authors Peter van der Stok and Michael Koster Changes from -01 to -02: o Added a catalogue use case. o Changed the registration update to a POST with optional link format payload. Removed the endpoint type update from the update. o Additional examples section added for more complex use cases. o New DNS-SD mapping section. o Added text on endpoint identification and authentication. o Error code 4.04 added to Registration Update and Delete requests. o Made 63 bytes a SHOULD rather than a MUST for endpoint name and resource type parameters. Changes from -00 to -01: o Removed the ETag validation feature. o Place holder for the DNS-SD mapping section. o Explicitly disabled GET or POST on returned Location. Shelby, et al. Expires January 8, 2017 [Page 49] =0C Internet-Draft CoRE Resource Directory July 2016 o New registry for RD parameters. o Added support for the JSON Link Format. o Added reference to the Groupcomm WG draft. Changes from -05 to WG Document -00: o Updated the version and date. Changes from -04 to -05: o Restricted Update to parameter updates. o Added pagination support for the Lookup interface. o Minor editing, bug fixes and reference updates. o Added group support. o Changed rt to et for the registration and update interface. Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten. o Editorial improvements. o Fixed the use of ETags. o Fixed tickets 383 and 372 Changes from -02 to -03: o Changed the endpoint name back to a single registration parameter ep=3D and removed the h=3D and ins=3D parameters. o Updated REST interface descriptions to use RFC6570 URI Template format. o Introduced an improved RD Lookup design as its own function set. o Improved the security considerations section. o Made the POST registration interface idempotent by requiring the ep=3D parameter to be present. Shelby, et al. Expires January 8, 2017 [Page 50] =0C Internet-Draft CoRE Resource Directory July 2016 Changes from -01 to -02: o Added a terminology section. o Changed the inclusion of an ETag in registration or update to a MAY. o Added the concept of an RD Domain and a registration parameter for it. o Recommended the Location returned from a registration to be stable, allowing for endpoint and Domain information to be changed during updates. o Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 16. References 16.1. Normative References [I-D.ietf-core-links-json] Li, K., Rahman, A., and D. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-05 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . Shelby, et al. Expires January 8, 2017 [Page 51] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . 16.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Shelby, et al. Expires January 8, 2017 [Page 52] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . Editorial Comments [_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert. Authors' Addresses Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Michael Koster SmartThings 665 Clyde Avenue Mountain View 94043 USA Phone: +1-707-502-5136 Email: Michael.Koster@smartthings.com Shelby, et al. Expires January 8, 2017 [Page 53] =0C Internet-Draft CoRE Resource Directory July 2016 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Shelby, et al. Expires January 8, 2017 [Page 54] --Apple-Mail=_ABD19AB8-011C-4B10-ADA1-B47E9441EB3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = Jul 8, 2016, at 7:06 AM, Michael Koster <michael.koster@smartthings.com> wrote:

Hi,

comments below 
On Jul 8, 2016, at 3:35 = AM, peter van der Stok <stokcons@xs4all.nl> wrote:

Hi Matthias,


I did a quick review of = the draft. I know you are quite swamped, but
maybe we can = get some updates in before publishing:

Thanks, there is one point where I can be useful.....

4.1. =  Resource Directory Address Option (RDAO)
I am quite = lost of the context here. There is only a quick hint in
the = bullet point list in Section 4---best add parentheses and "see
..." there. Otherwise it is unclear what kind of option you = are
talking about.

In the bullets of section 4 it is mentioned see section 4.1; = I probably do not understand what you mean.

It is the only location = where "6LR" is used without explanation.
Furthermore, the = endpoint could also be a 6LoWPAN host instead of a
router...

Right, = 6LR should be endpoint.

Fixed.

Also addressed some of Matthias = comments

<draft-ietf-core-resour= ce-directory-xx.txt>

= --Apple-Mail=_ABD19AB8-011C-4B10-ADA1-B47E9441EB3C-- --Apple-Mail=_914BB970-8729-4CDC-A478-D2773D077815-- From nobody Fri Jul 8 07:37:05 2016 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 AAC4812D773 for ; Fri, 8 Jul 2016 07:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_NEUTRAL=0.779] autolearn=ham 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 B_M3U1s_lgBM for ; Fri, 8 Jul 2016 07:36:55 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 B1D5912D5D6 for ; Fri, 8 Jul 2016 07:36:54 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id t190so13563186pfb.3 for ; Fri, 08 Jul 2016 07:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Q/qUjLEzzzkHUa710jpn1bRC++8UzblMevrFn1nOShM=; b=EUMsmWbTm5fTs5qlF/uNJ1mBn2Spx2SUu5CH9OrgI+4adQzZ66GzKKNER/LQV6fxF8 P5b0g+23GUdqExgxu/7GAeeHfWkGiQf0H2KGmGDwkBXCUDLJnmJNBCO9TDhT8dcXDX3t QwvVznIoeehCzbCT2sjJhHL+nBk8j9RDWsFsowdYbMMPa2X28+IbzU5rFhyPkTKb65l5 ajt5iHJeDSy0UQsSA3cGNCJZgyR3jGKohVUvJwP13pW1C+lkDWrAJAsSSBJV006DbRNr /nzuGLbpbJlFmdxCM0n+OhqbfJsT7EQQdZmbcABKFYz347sQBeEjlw1t0QqntXDP9A5P +kEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Q/qUjLEzzzkHUa710jpn1bRC++8UzblMevrFn1nOShM=; b=UmQb9u+WRPexPSWPawJEwFxVlxZLsQ2aCff1YmD88vxrl2z/tafylQZzQzYo0DPm7h nTALNZeRK0Qd/1ColZcgzYcEzrABolxGDsdXLvFa26rCXjnJ76H1lRaFyh3CrT/u07x8 13TvEVvCMBewe/48kWXz2ucHyJLDLWzhuVpanDjRRvGisVU/bXZsXzUYXmTsrfT3Ggle lV7log0Qv1j2uajlQ8LYpmmbVA06iK5XhKasLtrEHjq7nHOt6/43ltUFQaTvc4ksxc2Z 2Dthy4aeLiVhjYWU4x/BBgJFXDQ8XNEN6T3+QEs+0Z2KZfkF0z3+VLn1JOd4gc2AHfgX G66Q== X-Gm-Message-State: ALyK8tJXoBfno8zH+cx4Mfwsf5OXY+tisrUuGdb7H9ZggfPbEbYghkXzcda1bGIObkL5t/8n X-Received: by 10.98.192.12 with SMTP id x12mr10529047pff.106.1467988614277; Fri, 08 Jul 2016 07:36:54 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id i68sm5324928pfe.64.2016.07.08.07.36.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 07:36:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7950648B-CE7B-4C9D-9C48-9716A95046BE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> Date: Fri, 8 Jul 2016 07:36:44 -0700 Message-Id: <6E015256-34B8-45ED-8CD2-4F5FA77F1178@smartthings.com> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> To: Oscar Novo X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-core-resource-directory@tools.ietf.org" , "core@ietf.org" , Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 14:37:01 -0000 --Apple-Mail=_7950648B-CE7B-4C9D-9C48-9716A95046BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is important for clients that can not process large payloads, to be = able tp paginate the output. It is meant to work like the common ?start=3D21&count=3D10 used for web = pages. I don't know why "page" and not "start".=20 I could add some text and an example. Michael > On Jul 7, 2016, at 11:42 PM, Oscar Novo = wrote: >=20 > I provided you some comment about Page and count in the = lookup some time ago. I think those two elements are extremely unclear = and need to be explained better or removed. > =C2=B7 What does the ct:40 means in the following example? >=20 --Apple-Mail=_7950648B-CE7B-4C9D-9C48-9716A95046BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is important for clients that can not process large = payloads, to be able tp paginate the output.

It is meant to work like the common = ?start=3D21&count=3D10 used for web pages.

I don't know why "page" and not = "start". 

I= could add some text and an example.

Michael

On Jul 7, 2016, at 11:42 PM, Oscar Novo = <oscar.novo@ericsson.com> wrote:

         I = provided you some comment about Page and = count in the = lookup some time ago. I think those two elements are extremely unclear = and need to be explained better or removed.
=C2=B7         What does the ct:40 means in the following example?


= --Apple-Mail=_7950648B-CE7B-4C9D-9C48-9716A95046BE-- From nobody Fri Jul 8 08:00:38 2016 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 143A712D5CE for ; Fri, 8 Jul 2016 08:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 fvNYaEt2wF7c for ; Fri, 8 Jul 2016 08:00:29 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 35DA112D603 for ; Fri, 8 Jul 2016 08:00:29 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id hu1so973378pad.3 for ; Fri, 08 Jul 2016 08:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9NJjs7wZK1lmdxKz6ZpFhADymAGkOJ8Ea0tTiEn0X9s=; b=D3CU1jWgF0Y3G/bAbHU/RsBmpCr+xwsfEpZ/rdQmI4O3pSH5fPCSW8dZxswiaVjAL9 hoFsvmINVa/s1Q43pJCOSMtUYcVCJi6v6f6eNF4oolAgDqJaS++8O+z0Yj6T0VjcK+K9 8hX8Q2oOuu2BY9nH8E4zMzaB1zIrypbwAw9URd6SS65PFKO3GNfSAl0nSqt2XPA62utM wYhaglsL3UmagZicOzAPkpn4eRm8LPMvS0MCVtQmKBAt0ZHYORwos+sViq6TQIdvAhmg 20klmFBkFv8tYf5jrW0OVyKkBNk5PNwq8cm+AgWseketRi/sPOrHH2tMyxPcaACP/uRk tipA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9NJjs7wZK1lmdxKz6ZpFhADymAGkOJ8Ea0tTiEn0X9s=; b=F2gr1GeCy8CFfmGyhcyhrzQpnEuKNbe96xpENtF8733uY1+qDr5sQITRFLMycfEhjC UhU8Kw8oYXh4zCF5BDX0KqCy/WiPF5xBxcO1WVF+MDPZMQjiNXRUaCklhMqfemXnpRZT MsZQXLNWeclRQ5MjtO73E9oNGdht3zJWeApT51dARi4Zw2jn2uO+BJITfCyMY8eZgrjB 1t+erTXASOnMUk3NsNpy8OC9eMfQpK8O6+epjKdzzD9TOIxUBO/M4FD+bdGIrUlpa7/3 m3QtBdsCZwNSWleEgsiam50eSLl81mAKIyIcuhD6vVODj6LB3kCwvDO4qxltBU/S/t4w kgYw== X-Gm-Message-State: ALyK8tLELDOt0ooNzt6z6GVAGxtZCfh3WXX45hxtUvk1LyTeUiFQnnv3+ZvkchDvd1o+Z25K X-Received: by 10.66.251.170 with SMTP id zl10mr10689733pac.25.1467990028634; Fri, 08 Jul 2016 08:00:28 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id y70sm2303995pff.25.2016.07.08.08.00.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 08:00:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_71DAEC08-D10B-4119-AA80-F05C8B25A262" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <6E015256-34B8-45ED-8CD2-4F5FA77F1178@smartthings.com> Date: Fri, 8 Jul 2016 08:00:25 -0700 Message-Id: References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> <6E015256-34B8-45ED-8CD2-4F5FA77F1178@smartthings.com> To: Oscar Novo X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-core-resource-directory@tools.ietf.org" , "core@ietf.org" , Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 15:00:37 -0000 --Apple-Mail=_71DAEC08-D10B-4119-AA80-F05C8B25A262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Update with pagination described and example > On Jul 8, 2016, at 7:36 AM, Michael Koster = wrote: >=20 > This is important for clients that can not process large payloads, to = be able tp paginate the output. >=20 > It is meant to work like the common ?start=3D21&count=3D10 used for = web pages. >=20 > I don't know why "page" and not "start".=20 >=20 > I could add some text and an example. >=20 > Michael >=20 >> On Jul 7, 2016, at 11:42 PM, Oscar Novo > wrote: >>=20 >> I provided you some comment about Page and count in the = lookup some time ago. I think those two elements are extremely unclear = and need to be explained better or removed. >> =C2=B7 What does the ct:40 means in the following example? >>=20 >=20 --Apple-Mail=_71DAEC08-D10B-4119-AA80-F05C8B25A262 Content-Type: multipart/mixed; boundary="Apple-Mail=_0AFF04ED-BE46-49E3-BF7A-08D427E3A0CA" --Apple-Mail=_0AFF04ED-BE46-49E3-BF7A-08D427E3A0CA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Update with pagination described and example

--Apple-Mail=_0AFF04ED-BE46-49E3-BF7A-08D427E3A0CA Content-Disposition: attachment; filename=draft-ietf-core-resource-directory-xx.txt Content-Type: text/plain; name="draft-ietf-core-resource-directory-xx.txt" Content-Transfer-Encoding: quoted-printable CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster Expires: January 8, 2017 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant July 07, 2016 CoRE Resource Directory draft-ietf-core-resource-directory-08 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 resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Shelby, et al. Expires January 8, 2017 [Page 1] =0C Internet-Draft CoRE Resource Directory July 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 4. Finding a Directory Server . . . . . . . . . . . . . . . . . 8 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 9 5. Simple Registration . . . . . . . . . . . . . . . . . . . . . 10 5.1. Simple publishing to Resource Directory Server . . . . . 11 5.2. Third-party registration . . . . . . . . . . . . . . . . 12 6. Resource Directory Function Set . . . . . . . . . . . . . . . 12 6.1. Content Formats . . . . . . . . . . . . . . . . . . . . . 13 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Registration . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Registration Update . . . . . . . . . . . . . . . . . . . 17 6.5. Registration Removal . . . . . . . . . . . . . . . . . . 20 6.6. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 21 6.7. Update Endpoint Links . . . . . . . . . . . . . . . . . . 22 7. Group Function Set . . . . . . . . . . . . . . . . . . . . . 24 7.1. Register a Group . . . . . . . . . . . . . . . . . . . . 24 7.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 26 8. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 27 9. New Link-Format Attributes . . . . . . . . . . . . . . . . . 32 9.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 32 9.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 33 10. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. DNS-based Service discovery . . . . . . . . . . . . . . 33 10.2. mapping ins to . . . . . . . . . . . . . . . 34 10.3. Mapping rt to . . . . . . . . . . . . . . 35 10.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 35 Shelby, et al. Expires January 8, 2017 [Page 2] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings . . . . . . . . . . . . . . = 35 10.6. Importing resource links into DNS-SD . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11.1. Endpoint Identification and Authentication . . . . . . . 37 11.2. Access Control . . . . . . . . . . . . . . . . . . . . . 37 11.3. Denial of Service Attacks . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 38 12.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 38 12.3. IPv6 ND Resource Directory Address Option . . . . . . . 38 12.4. RD Parameter Registry . . . . . . . . . . . . . . . . . 38 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. Lighting Installation . . . . . . . . . . . . . . . . . 39 13.1.1. Installation Characteristics . . . . . . . . . . . . 40 13.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 41 13.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 44 13.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 44 13.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 45 13.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 46 13.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 48 13.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 48 13.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 48 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.1. Normative References . . . . . . . . . . . . . . . . . . 52 16.2. Informative References . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Linking [RFC5988]. The use of Web Linking for the description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format [RFC6690]. However, [RFC6690] only describes how to discover resources from the web server that hosts them by requesting "/.well-known/core". In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast Shelby, et al. Expires January 8, 2017 [Page 3] =0C Internet-Draft CoRE Resource Directory July 2016 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 a Resource Directory are defined. Although the examples in this document show the use of these interfaces with CoAP [RFC7252], they can be applied in an equivalent manner to HTTP [RFC7230]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "byte" is used in its now customary sense as a synonym for "octet". This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252]. To describe the REST interfaces defined in this specification, the URI Template format is used [RFC6570]. This specification makes use of the following additional terminology: Resource Directory A web entity that stores information about web resources and implements the REST interfaces defined in this specification for registration and lookup of those resources. Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Group In the context of a Resource Directory, a group is a logical grouping of endpoints for the purpose of group communications. All groups within a domain are unique. Endpoint Shelby, et al. Expires January 8, 2017 [Page 4] =0C Internet-Draft CoRE Resource Directory July 2016 Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. 3. Architecture and Use Cases The resource directory architecture is illustrated in Figure 1. A Resource Directory (RD) is used as a repository for Web Links [RFC5988] about resources hosted on other web servers, which are called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory entries), and for clients to lookup resources from the RD or maintain groups. Endpoints themselves can also act as clients. An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured by an outside entity. This information hierarchy is shown in Figure 2. Endpoints are assumed to proactively register and maintain resource directory entries on the RD, which are soft state and need to be periodically refreshed. An endpoint is provided with interfaces to register, update and remove a resource directory entry. Furthermore, a mechanism to discover an RD using the CoRE Link Format [RFC6690] is defined. It is also possible for an RD to proactively discover Web Links from endpoints and add them as resource directory entries. A lookup interface for discovering any of the Web Links held in the RD is provided using the CoRE Link Format. Shelby, et al. Expires January 8, 2017 [Page 5] =0C Internet-Draft CoRE Resource Directory July 2016 Registration Lookup, Group Interface Interfaces +----+ | | | EP |---- | | +----+ ---- | | --|- +------+ | +----+ | ----| | | +--------+ | EP | ---------|-----| RD |----|-----| Client | +----+ | ----| | | +--------+ --|- +------+ | +----+ ---- | | | EP |---- | | +----+ Figure 1: The resource directory architecture. +------------+ | Domain | <-- Name +------------+ | | | +------------+ | | Group | <-- Name, Scheme, IP, Port | +------------+ | | +------------+ | Endpoint | <-- Name, Scheme, IP, Port +------------+ | | +------------+ | Resource | <-- Target, Parameters +------------+ Figure 2: The resource directory information hierarchy. 3.1. Use Case: Cellular M2M Over the last few years, mobile operators around the world have focused on development of M2M solutions in order to expand the business to the new type of users: machines. The machines are connected directly to a mobile network using an appropriate embedded air interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and wide range wireless interfaces. =46rom the system design point = of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application Shelby, et al. Expires January 8, 2017 [Page 6] =0C Internet-Draft CoRE Resource Directory July 2016 requirements, thus avoiding silo like solutions. One of the crucial enablers of such design is the ability to discover resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities. Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs. The address of each (proxy) endpoint on this server is included in the resource description stored in the RD. The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database. Similarly, fleet management systems provide the appropriate link parameters to the RD to look up for EPs deployed on the vehicles the application is responsible for. 3.2. Use Case: Home and Building Automation Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. The exporting of resource information to other discovery systems is also important in these automation applications. In home automation there is a need to interact with other consumer electronics, which may already support DNS-SD, and in building automation DNS-SD in combination with resource directories can cover multiple buildings. 3.3. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted Shelby, et al. Expires January 8, 2017 [Page 7] =0C Internet-Draft CoRE Resource Directory July 2016 anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use the Resource Directory lookup function set to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in web link compatible representations are supplied by Resource Directories, which may be internally stored as triples, or relation/attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to common web linking formats for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms should generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. This provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. 4. Finding a Directory Server Endpoints that want to contact a directory server can obtain candidate IP addresses for such servers in a number of ways. In a 6LoWPAN, good candidates can be taken from: o specific static configuration (e.g., anycast addresses), if any, o the ABRO option of 6LoWPAN-ND [RFC6775], o other ND options that happen to point to servers (such as RDNSS), o DHCPv6 options that might be defined later. o The IPv6 Neighbor Discovery Resource Directory Address Option Section 4.1 Shelby, et al. Expires January 8, 2017 [Page 8] =0C Internet-Draft CoRE Resource Directory July 2016 In networks with more inexpensive use of multicast, the candidate IP address may be a well-known multicast address, i.e. directory servers are found by simply sending GET requests to that well-known multicast address (see Section 6.2). As some of these sources are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate- limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. 4.1. Resource Directory Address Option (RDAO) The Resource Directory Option (RDAO) using IPv6 neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with link-local multicast address because the endpoint and the RD are separated by a border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network. The presence and the use of the RD is essential during commissioning. The RDAO format is: Shelby, et al. Expires January 8, 2017 [Page 9] =0C Internet-Draft CoRE Resource Directory July 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length =3D 3 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RD Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 38 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this set of border router information is valid. A value of all zero bits (0x0) assumes a default value of 10,000 (~one week). Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. RD Address: IPv6 address of the RD. Figure 3: Resource Directory Address Option 5. Simple Registration Not all endpoints hosting resources are expected to know how to implement the Resource Directory Function Set (see Section 6) hence cannot register with a Resource Directory. Instead, simple endpoints can implement the generic Simple Directory Discovery approach described in this section. An RD implementing this specification MUST implement Simple Directory Discovery. However, there may be Shelby, et al. Expires January 8, 2017 [Page 10] =0C Internet-Draft CoRE Resource Directory July 2016 security reasons why this form of directory discovery would be disabled. This approach requires that the endpoint makes available the hosted resources that it wants to be discovered, as links on its "/.well- known/core" interface as specified in [RFC6690]. The endpoint then finds one or more addresses of the directory server as described in Section 4. An endpoint can send (a selection of) hosted resources to a directory server for publication as described in Section 5.1. The directory server integrates the information it received this way into its resource directory. It MAY make the information available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 5.1. Simple publishing to Resource Directory Server An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. The endpoint MAY include registration parameters in the POST request as per Section 6.3 The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. Shelby, et al. Expires January 8, 2017 [Page 11] =0C Internet-Draft CoRE Resource Directory July 2016 Req:(to RD server from [ff02::1]) POST coap://rd.example.com/.well-known/core?lt=3D6000 Content-Format: 40 payload: (empty payload) Res: 2.04 Changed (later) Req: (from RD server to [ff02::1]) GET coap://[ff02::1]/.well-known/core Accept: 40 Res: 2.05 Content payload: 5.2. Third-party registration For some applications, even Simple Directory Discovery may be too taxing for certain very constrained devices, in particular if the security requirements become too onerous. In a controlled environment (e.g. building control), the Resource Directory can be filled by a third device, called a commissioning tool. The commissioning tool can fill the Resource Directory from a database or other means. For that purpose the scheme, IP address and port of the registered device is indicated in the Context parameter of the registration Section 6.3. 6. Resource Directory Function Set This section defines the REST interfaces between an RD and endpoints, which is called the Resource Directory Function Set. Although the examples throughout this section assume the use of CoAP [RFC7252], these REST interfaces can also be realized using HTTP [RFC7230]. In all definitions in this section, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces defined in this section. Shelby, et al. Expires January 8, 2017 [Page 12] =0C Internet-Draft CoRE Resource Directory July 2016 Resource directory entries are designed to be easily exported to other discovery mechanisms such as DNS-SD. For that reason, parameters that would meaningfully be mapped to DNS SHOULD be limited to a maximum length of 63 bytes. 6.1. Content Formats Resource Directory implementations using this specification MUST support the application/link-format content format (ct=3D40). Resource Directories implementing this specification MAY support additional content formats. Any additional content format supported by a Resource Directory implementing this specification MUST have an equivalent serialization in the application/link-format content format. 6.2. Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the path of its RD Function Set. There can be several mechanisms for discovering the RD including assuming a default location (e.g. on an Edge Router in a LoWPAN), by assigning an anycast address to the RD, using DHCP, or by discovering the RD using the CoRE Link Format (see also Section 4). This section defines discovery of the RD using the well-known interface of the CoRE Link Format [RFC6690] as the required mechanism. It is however expected that RDs will also be discoverable via other methods depending on the deployment. Discovery of the RD function set is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup" is used to discover the RD Lookup Function Set. Upon success, the response will contain a payload with a link format entry for each RD discovered, with the URL indicating the root resource of the RD. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link attribute, as shown in the example below. Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. Shelby, et al. Expires January 8, 2017 [Page 13] =0C Internet-Draft CoRE Resource Directory July 2016 HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. An RD implementation of this specification MUST support query filtering for the rt parameter as defined in [RFC6690]. The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt :=3D Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : YES (Unicast only) The following example shows an endpoint discovering an RD using this interface, thus learning that the base RD resource is, in this Shelby, et al. Expires January 8, 2017 [Page 14] =0C Internet-Draft CoRE Resource Directory July 2016 example, at /rd and that the content_format delivered by the server hosting the resource is application.xml (ct=3D40). Note that it is = up to the RD to choose its base RD resource, although diagnostics and debugging is facilitated by using the base paths specified here where possible. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup";ct=3D40, ;rt=3D"core.rd-group";ct=3D40 The following example shows the way of indicating multiple values for Content-Format codes. The Content-Format code attribute "ct" MAY include a space-separated sequence of Content-Format codes as specified in [RFC7252], indicating that multiple content-formats are available. The example below shows the required ct=3D40 = (application/ link-format) as well as a vendor-specific content format. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 21225", ;rt=3D"core.rd-lookup";ct=3D"40 21225", ;rt=3D"core.rd-group";ct=3D"40 21225" 6.3. Registration After discovering the location of an RD Function Set, an endpoint MAY register its resources using the registration interface. This interface accepts a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link- format+json), or CBOR CoRE Link Format (application/link-format+cbor) [I-D.ietf-core-links-json], along with query string parameters indicating the name of the endpoint, its domain and the lifetime of the registration. All parameters except the endpoint name are optional. It is expected that other specifications will define further parameters (see Section 12.4). The RD then creates a new resource or updates an existing resource in the RD and returns its location. An endpoint MUST use that location when refreshing registrations using this interface. Endpoint resources in the RD are kept active for the period indicated by the lifetime parameter. The endpoint is responsible for refreshing the entry within this period using either the registration or update interface. The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameter does not create multiple RD Shelby, et al. Expires January 8, 2017 [Page 15] =0C Internet-Draft CoRE Resource Directory July 2016 entries. A new registration may be created at any time to supercede an existing registration, replacing the registration parameters and links. The registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd :=3D RD Function Set path (mandatory). This is the path of = the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10). et :=3D Endpoint Type (optional). The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor Shelby, et al. Expires January 8, 2017 [Page 16] =0C Internet-Draft CoRE Resource Directory July 2016 The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new resource entry for the endpoint. This Location MUST be a stable identifier generated by the RD as it is used for all subsequent operations on this registration. The resource returned in the Location is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered links, including updating and deleting links. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. The resulting location /rd/4521 is just an example of an RD generated location. Req: POST coap://rd.example.com/rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 Req: POST /rd?ep=3Dnode1 HTTP/1.1 Host : example.com Content-Type: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 6.4. Registration Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the resource returned in the Location option in the response to the first registration. Shelby, et al. Expires January 8, 2017 [Page 17] =0C Internet-Draft CoRE Resource Directory July 2016 An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 6.3 ) if they have changed since the last registration or update. Parameters that have not changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in {registration}. Upon receiving an update request, an RD MUST reset the timeout for that endpoint and update the scheme, IP address and port of the endpoint, using the source address of the update, or the context ("con") parameter if present. If the lifetime parameter "lt" is included in the received update request, the RD MUST update the lifetime of the registration and set the timeout equal to the new lifetime. An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if both the target URI and relation type match. In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 6.7. The update registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. Optional. In the absence of this parameter the scheme of the protocol, source IP address and source port used to register are assumed. This parameter is Shelby, et al. Expires January 8, 2017 [Page 18] =0C Internet-Draft CoRE Resource Directory July 2016 compulsory when the directory is filled by a third party such as a commissioning tool. Content-Format: application/link-format (mandatory) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint updating its registration at an RD using this interface. Req: POST /rd/4521 Res: 2.04 Changed The following example shows an endpoint updating its registration with a new lifetime and context, changing an existing link, and adding a new link using this interface. With the initial registration the client set the following values: o lifetime (lt)=3D500 o context (con)=3Dcoap://local-proxy-old.example.com:5683 o resource=3D ;ct=3D41;rt=3D"foobar";if=3D"sensor" Shelby, et al. Expires January 8, 2017 [Page 19] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST /rd/4521?lt=3D600&con=3D"coap://local-proxy.example.com:5683"= Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-f";if=3D"sensor", ;ct=3D41;rt=3D"door";if=3D"sensor" Res: 2.04 Changed 6.5. Registration Removal Although RD entries have soft state and will eventually timeout after their lifetime, an endpoint SHOULD explicitly remove its entry from the RD if it knows it will no longer be available (for example on shut-down). This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. The removal request interface is specified as follows: Interaction: EP -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the endpoint from the RD. Shelby, et al. Expires January 8, 2017 [Page 20] =0C Internet-Draft CoRE Resource Directory July 2016 Req: DELETE /rd/4521 Res: 2.02 Deleted 6.6. Read Endpoint Links Some endpoints may wish to manage their links as a collection, and may need to read the current set of links in order to determine link maintenance operations. One or more links MAY be selected by using query filtering as specified in [RFC6690] Section 4.1 The read request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" upon success with an "application/link-format", "application/link-format+cbor", or "application/link-format+json" payload. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires January 8, 2017 [Page 21] =0C Internet-Draft CoRE Resource Directory July 2016 The following examples show successful read of the endpoint links from the RD. Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" 6.7. Update Endpoint Links [This section will be removed before or as a result of a working- group last-call if the PATCH methods do not achieve the same level of consensus as the present document.] A PATCH update adds, removes or changes links for the endpoint by including link update information in the payload of the update as a merge-patch+json format [RFC7396] document. One or more links are selected for update by using query filtering as specified in [RFC6690] Section 4.1 The query filter selects the links to be modified or deleted, by matching the query parameter values to the values of the link attributes. When the query parameters are not present in the request, the payload specifies links to be added to the target document. When the query parameters are present, the attribute names and values in the query parameters select one or more links on which to apply the PATCH operation. If an attribute name specified in the PATCH document exists in any the set of selected links, all occurrences of the attribute value in the target document MUST be updated using the value from the PATCH payload. If the attribute name is not present in any selected links, the attribute MUST be added to the links. The update request interface is specified as follows: Interaction: EP -> RD Method: PATCH URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 22] =0C Internet-Draft CoRE Resource Directory July 2016 location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 Content-Format: application/merge-patch+json (mandatory) The following response codes are defined for this interface: Success: 2.04 "Changed" 0r 204 "No Content" in the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration resource does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show an endpoint adding , modifying , and removing links in RD using the Update Endpoint Links function. The following example shows an EP adding the link ;ct=3D41;rt=3D"humid-s";if=3D"sensor" to the collection of = links at the location /rd/4521. Req: PATCH /rd/4521 Payload: [{"href":"/sensors/humid","ct": 41, "rt": "humid-s", "if": "sensor"}] Content-Format: application/merge-patch+json Res: 2.04 Changed The following example shows an EP modifying all links at the location /rd/4521 which are identified by href=3D"/sensors/temp", from the initial link-value of ;rt=3D"temperature" to the new link-value ;rt=3D"temperature-c";if=3D"sensor" by = changing Shelby, et al. Expires January 8, 2017 [Page 23] =0C Internet-Draft CoRE Resource Directory July 2016 the value of the link attribute "rt" and adding the link attribute if=3D"sensor" using the PATCH operation with the supplied merge- patch+json document payload. Req: PATCH /rd/4521?href=3D"/sensors/temp" Payload: {"rt": "temperature-c", "if": "sensor"}, Content-Format: application/merge-patch+json Res: 2.04 Changed This example shows an EP removing all links at the location /rd/4521 which are identified by href=3D"/sensors/light". Req: PATCH /rd/4521?href=3D"/sensors/light" Payload: {null} Content-Format: application/merge-patch+json Res: 2.04 Changed 7. Group Function Set This section defines a function set for the creation of groups of endpoints for the purpose of managing and looking up endpoints for group operations. The group function set is similar to the resource directory function set, in that a group may be created or removed. However unlike an endpoint entry, a group entry consists of a list of endpoints and does not have a lifetime associated with it. In order to make use of multicast requests with CoAP, a group MAY have a multicast address associated with it. 7.1. Register a Group In order to create a group, a commissioning tool (CT) used to configure groups, makes a request to the RD indicating the name of the group to create (or update), optionally the domain the group belongs to, and optionally the multicast address of the group. The registration message includes the list of endpoints that belong to that group. Shelby, et al. Expires January 8, 2017 [Page 24] =0C Internet-Draft CoRE Resource Directory July 2016 All the endpoints in the group MUST be registered with the RD before registering a group. If an endpoint is not yet registered to the RD before registering the group, the registration message returns an error. The RD sends a blank target URI for every endpoint link when registering the group. Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. The registration request interface is specified as follows: Interaction: CT -> RD Method: POST URI Template: /{+rd-group}{?gp,d,con} URI Template Variables: rd-group :=3D RD Group Function Set path (mandatory). This is = the path of the RD Group Function Set. An RD SHOULD use the value "rd-group" for this variable whenever possible. gp :=3D Group Name (mandatory). The name of the group to be created or replaced, unique within that domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this group = belongs. The maximum length of this parameter is 63 bytes. Optional. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10) con :=3D Context (optional). This parameter is used to set the = IP multicast address at which this server is available in the form scheme://multicast-address:port. Optional. In the absence of this parameter no multicast address is configured. This parameter is compulsory when the directory is filled by a commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 25] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new group entry. This Location MUST be a stable identifier generated by the RD as it is used for delete operations on this registration. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". An Endpoint is not registered in the RD (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface. The resulting location /rd-group/12 is just an example of an RD generated group location. Req: POST coap://rd.example.com/rd-group?gp=3Dlights Content-Format: 40 Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 2.01 Created Location: /rd-group/12 Req: POST /rd-group?gp=3Dlights HTTP/1.1 Host: example.com Content-Type: application/link-format Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 201 Created Location: /rd-group/12 7.2. Group Removal A group can be removed simply by sending a removal message to the location returned when registering the group. Removing a group MUST NOT remove the endpoints of the group from the RD. The removal request interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 26] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: CT -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful group registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the group from the RD. Req: DELETE /rd-group/12 Res: 2.02 Deleted 8. RD Lookup Function Set In order for an RD to be used for discovering resources registered with it, a lookup interface can be provided using this function set. This lookup interface is defined as a default, and it is assumed that RDs may also support lookups to return resource descriptions in alternative formats (e.g. Atom or HTML Link) or using more advanced interfaces (e.g. supporting context or semantic based lookup). This function set allows lookups for domains, groups, endpoints and resources using attributes defined in the RD Function Set and for use with the CoRE Link Format. The result of a lookup request is the list of links (if any) corresponding to the type of lookup. Thus, a domain lookup MUST return a list of domains, a group lookup MUST return a list of groups, an endpoint lookup MUST return a list of Shelby, et al. Expires January 8, 2017 [Page 27] =0C Internet-Draft CoRE Resource Directory July 2016 endpoints and a resource lookup MUST return a list of links to resources. Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. The target of these links SHOULD be the actual location of the domain, endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. The domain lookup returns every lookup domain with a "/rd" value encapsulated within angle brackets. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a "/rd-group" value encapsulated within angle brackets. Otherwise, the group lookup returns the multicast address of the group inside angle brackets. Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default) or its alternate content-formats ("application/link-format+json" or "application/link-format+cbor"). The page and count parameters are used to obtain lookup results in specified increments using pagination, where count specifies how many links to return and page specifies which subset of links organized in sequential pages , each containing 'count' links, starting with link zero and page zero. Thus, specifying count of 10 and page of 0 will return the first 10 links in the result set (links 0-9). Count =3D = 10 and page =3D 1 will return th enext 'page' containing links 10-19, = and so on. Multiple query parameters MAY be included in a lookup, all included parameters MUST match for a resource to be returned. The character'*' MAY be included at the end of a parameter value as a wildcard operator. The rd-lookup interface MAY use any set of query parameters to match the registered attributes and relations. In addition, this interface MAY be used with queries that specify domains, endpoints, and groups. For example, a domain lookup filtering on groups would return a list of domains that contain the specified groups. An endpoint lookup filtering on groups would return a list of endpoints that are in the specified groups. The lookup interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 28] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: Client -> RD Method: GET URI Template: /{+rd-lookup-base}/{lookup- type}{?d,ep,gp,et,rt,page,count,resource-param} URI Template Variables: rd-lookup-base :=3D RD Lookup Function Set path (mandatory). = This is the path of the RD Lookup Function Set. An RD SHOULD use the value "rd-lookup" for this variable whenever possible. lookup-type :=3D ("d", "ep", "res", "gp") (mandatory) This = variable is used to select the kind of lookup to perform (domain, endpoint, resource, or group). ep :=3D Endpoint name (optional). Used for endpoint, group and resource lookups. d :=3D Domain (optional). Used for domain, group, endpoint and resource lookups. res :=3D resource (optional). Used for domain, group, endpoint = and resource lookups. gp :=3D Group name (optional). Used for endpoint, group and resource lookups. page :=3D Page (optional). Parameter can not be used without the count parameter. Results are returned from result set in pages that contain 'count' links starting from index (page * count). Page numbering starts with zero. count :=3D Count (optional). Number of results is limited to = this parameter value. If the page parameter is also present, the response MUST only include 'count' links starting with the (page * count) link in the result set from the query. If the count parameter is not present, then the response MUST return all matching links in the result set. Link numbering starts with zero. rt :=3D Resource type (optional). Used for group, endpoint and resource lookups. et :=3D Endpoint type (optional). Used for group, endpoint and resource lookups. Shelby, et al. Expires January 8, 2017 [Page 29] =0C Internet-Draft CoRE Resource Directory July 2016 resource-param :=3D Link attribute parameters (optional). Any = link attribute as defined in Section 4.1 of [RFC6690], used for resource lookups. Content-Format: application/link-format (optional) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" with an "application/link- format", "application/link-format+cbor", or "application/link- format+json" payload containing matching entries for the lookup. Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching entry is found for a unicast request. Failure: No error response to a multicast request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The examples in this section assume a CoAP host with IP address FDFD::123 and a default CoAP port 61616. HTTP hosts are possible and do not change the nature of the examples.\ The following example shows a client performing a resource lookup: Req: GET /rd-lookup/res?rt=3Dtemperature Res: 2.05 Content ;rt=3D"temperature" The following example shows a client performing an endpoint type lookup: Req: GET /rd-lookup/ep?et=3Dpower-node Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" Shelby, et al. Expires January 8, 2017 [Page 30] =0C Internet-Draft CoRE Resource Directory July 2016 The following example shows a client performing a domain lookup: Req: GET /rd-lookup/d Res: 2.05 Content <>;d=3D"domain1", <>;d=3D"domain2" The following example shows a client performing a group lookup for all groups: Req: GET /rd-lookup/gp Res: 2.05 Content <>;gp=3D"lights1";d=3D"example.com" <>;gp=3D"lights2";d=3D"ecample.com" The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rd-lookup/ep?gp=3Dlights1 Res: 2.05 Content ;ep=3D"node1", ;ep=3D"node2" The following example shows a client performing a lookup for all groups an endpoint belongs to: Req: GET /rd-lookup/gp?ep=3Dnode1 Res: 2.05 Content <>;gp=3D"lights1" The following example shows a client performing a paginated lookup Shelby, et al. Expires January 8, 2017 [Page 31] =0C Internet-Draft CoRE Resource Directory July 2016 Req: GET /rd-lookup/res?page=3D0&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 Req: GET /rd-lookup/res?page=3D1&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 9. New Link-Format Attributes When using the CoRE Link Format to describe resources being discovered by or posted to a resource directory service, additional information about those resources is useful. This specification defines the following new attributes for use in the CoRE Link Format [RFC6690]: link-extension =3D ( "ins" "=3D" quoted-string ) ; Max 63 bytes link-extension =3D ( "exp" ) 9.1. Resource Instance attribute 'ins' The Resource Instance "ins" attribute is an identifier for this resource, which makes it possible to distinguish it from other similar resources. This attribute is similar in use to the portion of a DNS-SD record (see Section 10.1, and SHOULD be unique across resources with the same Resource Type attribute in the domain it is used. A Resource Instance might be a descriptive string like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID or iNumber. This attribute is used by a Resource Directory to distinguish between multiple instances of the same resource type within the directory. This attribute MUST be no more than 63 bytes in length. The resource identifier attribute MUST NOT appear more than once in a link description. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. Shelby, et al. Expires January 8, 2017 [Page 32] =0C Internet-Draft CoRE Resource Directory July 2016 9.2. Export attribute 'exp' The Export "exp" attribute is used as a flag to indicate that a link description MAY be exported by a resource directory to external directories. The CoRE Link Format is used for many purposes between CoAP endpoints. Some are useful mainly locally, for example checking the observability of a resource before accessing it, determining the size of a resource, or traversing dynamic resource structures. However, other links are very useful to be exported to other directories, for example the entry point resource to a functional service. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 10. DNS-SD Mapping CoRE Resource Discovery is intended to support fine-grained discovery of hosted resources, their attributes, and possibly other resource relations [RFC6690]. In contrast, service discovery generally refers to a coarse-grained resolution of an endpoint's IP address, port number, and protocol. Resource and service discovery are complementary in the case of large networks, where the latter can facilitate scaling. This document defines a mapping between CoRE Link Format attributes and DNS-Based Service Discovery [RFC6763] fields that permits discovery of CoAP services by either method. 10.1. DNS-based Service discovery DNS-Based Service Discovery (DNS-SD) defines a conventional method of configuring DNS PTR, SRV, and TXT resource records to facilitate discovery of services (such as CoAP servers in a subdomain) using the existing DNS infrastructure. This section gives a brief overview of DNS-SD; see [RFC6763] for a detailed specification. DNS-SD service names are limited to 255 octets and are of the form: Service Name =3D ... The service name is the label of SRV/TXT resource records. The SRV RR specifies the host and the port of the endpoint. The TXT RR provides additional information in the form of key/value pairs. The part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify servers or groups of servers. Shelby, et al. Expires January 8, 2017 [Page 33] =0C Internet-Draft CoRE Resource Directory July 2016 The part is composed of at least two labels. The first label of the pair is the application protocol name [RFC6335] preceded by an underscore character. The second label indicates the transport and is always "_udp" for UDP-based CoAP services. In cases where narrowing the scope of the search may be useful, these labels may be optionally preceded by a subtype name followed by the "_sub" label. An example of this more specific is "light._sub._dali._udp". A default part of the service name may be set at the factory or during the commissioning process. It SHOULD uniquely identify an instance of within a . Taken together, these three elements comprise a unique name for an SRV/ TXT record pair within the DNS subdomain. The granularity of a service name MAY be that of a host or group, or it could represent a particular resource within a CoAP server. The SRV record contains the host name (AAAA record name) and port of the service while protocol is part of the service name. In the case where a service name identifies a particular resource, the path part of the URI must be carried in a corresponding TXT record. A DNS TXT record is in practice limited to a few hundred octets in length, which is indicated in the resource record header in the DNS response message. The data consists of one or more strings comprising a key=3Dvalue pair. By convention, the first pair is txtver=3D (to support different versions of a service description). 10.2. mapping ins to The Resource Instance "ins" attribute maps to the part of a DNS-SD service name. It is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. However, to the extent that the "ins" attribute may be chosen to match the DNS host name of a service, it SHOULD use the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. The part of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can allow the device or service to be accessed in many cases without any manual configuration at all. The default name should be short and descriptive, and MAY include a collision-resistant substring such as the lower bits of the device's MAC address, serial number, Shelby, et al. Expires January 8, 2017 [Page 34] =0C Internet-Draft CoRE Resource Directory July 2016 fingerprint, or other identifier in an attempt to make the name relatively unique. DNS labels are currently limited to 63 octets in length and the entire service name may not exceed 255 octets. 10.3. Mapping rt to The resource type "rt" attribute is mapped into the part of a DNS-SD service name and SHOULD conform to the reg-rel-type production of the Link Format defined in Section 2 of [RFC6690]. The "rt" attribute MUST be composed of at least a single Net-Unicode text string, without underscore '_' or period '.' and limited to 15 octets in length, which represents the application protocol name. This string is mapped to the DNS-SD by prepending an underscore and appending a period followed by the "_udp" label. For example, rt=3D"dali" is mapped into "_dali._udp". The application protocol name may be optionally followed by a period and a service subtype name consisting of a Net-Unicode text string, without underscore or period and limited to 63 octets. This string is mapped to the DNS-SD by appending a period followed by the "_sub" label and then appending a period followed by the service type label pair derived as in the previous paragraph. For example, rt=3D"dali.light" is mapped into "light._sub._dali._udp". The resulting string is used to form labels for DNS-SD records which are stored directly in the DNS. 10.4. Domain mapping DNS domains may be derived from the "d" attribute. The domain attribute may be suffixed with the zone name of the authoritative DNS server to generate the domain name. The "ep" attribute is prefixed to the domain name to generate the FQDN to be stored into DNS with an AAAA RR. 10.5. TXT Record key=3Dvalue strings A number of [RFC6763] key/value pairs are derived from link-format information, to be exported in the DNS-SD as key=3Dvalue strings in a TXT record ([RFC6763], Section 6.3). The resource is exported as key/value pair "path=3D". The Interface Description "if" attribute is exported as key/value pair "if=3D". Shelby, et al. Expires January 8, 2017 [Page 35] =0C Internet-Draft CoRE Resource Directory July 2016 The DNS TXT record can be further populated by importing any other resource description attributes as they share the same key=3Dvalue format specified in Section 6 of [RFC6763]. 10.6. Importing resource links into DNS-SD Assuming the ability to query a Resource Directory or multicast a GET (?exp) over the local link, CoAP resource discovery may be used to populate the DNS-SD database in an automated fashion. CoAP resource descriptions (links) can be exported to DNS-SD for exposure to service discovery by using the Resource Instance attribute as the basis for a unique service name, composed with the Resource Type as the , and registered in the correct . The agent responsible for exporting records to the DNS zone file SHOULD be authenticated to the DNS server. The following example shows an agent discovering a resource to be exported: Req: GET /rd-lookup/res?exp Res: 2.05 Content ; exp;rt=3D"dali.light";ins=3D"Spot"; d=3D"office";ep=3D"node1" The agent subsequently registers the following DNS-SD RRs, assuming a zone name "example.com" prefixed with "office": node1.office.example.com. IN AAAA FDFD::1234 _dali._udp.office.example.com IN PTR Spot._dali._udp.office.example.com light._sub._dali._udp.example.com IN PTR Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com IN SRV 0 0 5683 node1.office.example.com. Spot._dali._udp.office.example.com IN TXT txtver=3D1;path=3D/light/1 In the above figure the Service Name is chosen as Spot._dali._udp.office.example.com without the light._sub service prefix. An alternative Service Name would be: Spot.light._sub._dali._udp.office.example.com. 11. Security Considerations The security considerations as described in Section 7 of [RFC5988] and Section 6 of [RFC6690] apply. The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as Shelby, et al. Expires January 8, 2017 [Page 36] =0C Internet-Draft CoRE Resource Directory July 2016 described in [RFC7252]. DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. 11.1. Endpoint Identification and Authentication An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. 11.2. Access Control Access control SHOULD be performed separately for the RD Function Set and the RD Lookup Function Set, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. 11.3. Denial of Service Attacks Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than Shelby, et al. Expires January 8, 2017 [Page 37] =0C Internet-Draft CoRE Resource Directory July 2016 requests, RDs can unknowingly become part of a DDoS amplification attack. Therefore, it is RECOMMENDED that implementations ensure return routability. This can be done, for example by responding to wild card lookups only over DTLS or TLS or TCP. 12. IANA Considerations 12.1. Resource Types "core.rd", "core.rd-group" and "core.rd-lookup" resource types need to be registered with the resource type registry defined by [RFC6690]. 12.2. Link Extension The "exp" and "ins" attributes need to be registered when a future Web Linking link-extension registry is created (e.g. in RFC5988bis). 12.3. IPv6 ND Resource Directory Address Option This document registers one new ND option type under the subregistry "IPv6 Neighbor Discovery Option Formats": o Resource Directory address Option (38) 12.4. RD Parameter Registry This specification defines a new sub-registry for registration and lookup parameters called "RD Parameters" under "CoRE Parameters". Although this specification defines a basic set of parameters, it is expected that other standards that make use of this interface will define new ones. Each entry in the registry must include the human readable name of the parameter, the query parameter, validity requirements if any and a description. The query parameter MUST be a valid URI query key [RFC3986]. Initial entries in this sub-registry are as follows: Shelby, et al. Expires January 8, 2017 [Page 38] =0C Internet-Draft CoRE Resource Directory July 2016 +-----------+-------+---------------+-------------------------------+ | Name | Query | Validity | Description | +-----------+-------+---------------+-------------------------------+ | Endpoint | ep | | Name of the endpoint, max 63 | | Name | | | bytes | | Lifetime | lt | 60-4294967295 | Lifetime of the registration | | | | | in seconds | | Domain | d | | Domain to which this endpoint | | | | | belongs | | Endpoint | et | | Semantic name of the endpoint | | Type | | | | | Context | con | URI | The scheme, address and port | | | | | at which this server is | | | | | available | | Resource | res | | Name of the resource | | Name | | | | | Group | gp | | Name of a group in the RD | | Name | | | | | Page | page | Integer | Used for pagination | | Count | count | Integer | Used for pagination | | Resource | ins | | Instance Identifier | | Instance | | | | | Export | exp | | A link MAY be exported to | | | | | another Resource Directory | +-----------+-------+---------------+-------------------------------+ Table 1: RD Parameters The IANA policy for future additions to the sub-registry is "Expert Review" as described in [RFC5226]. 13. Examples Examples are added here. 13.1. Lighting Installation This example shows a simplified lighting installation which makes use of the Resource Directory (RD) with a CoAP interface to facilitate the installation and start up of the application code in the lights and sensors. In particular, the example leads to the definition of a group and the enabling of the corresponding multicast address. No conclusions must be drawn on the realization of actual installation or naming procedures, because the example only "emphasizes" some of the issues that may influence the use of the RD and does not pretend to be normative. Shelby, et al. Expires January 8, 2017 [Page 39] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.1. Installation Characteristics The example assumes that the installation is managed. That means that a Commissioning Tool (CT) is used to authorize the addition of nodes, name them, and name their services. The CT can be connected to the installation in many ways: the CT can be part of the installation network, connected by WiFi to the installation network, or connected via GPRS link, or other method. It is assumed that there are two naming authorities for the installation: (1) the network manager that is responsible for the correct operation of the network and the connected interfaces, and (2) the lighting manager that is responsible for the correct functioning of networked lights and sensors. The result is the existence of two naming schemes coming from the two managing entities. The example installation consists of one presence sensor, and two luminaries, luminary1 and luminary2, each with their own wireless interface. Each luminary contains three lamps: left, right and middle. Each luminary is accessible through one endpoint. For each lamp a resource exists to modify the settings of a lamp in a luminary. The purpose of the installation is that the presence sensor notifies the presence of persons to a group of lamps. The group of lamps consists of: middle and left lamps of luminary1 and right lamp of luminary2. Before commissioning by the lighting manager, the network is installed and access to the interfaces is proven to work by the network manager. At the moment of installation, the network under installation is not necessarily connected to the DNS infra structure. Therefore, SLAAC IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in Table 2 below: +--------------------+--------------+ | Name | IPv6 address | +--------------------+--------------+ | luminary1 | FDFD::ABCD:1 | | luminary2 | FDFD::ABCD:2 | | Presence sensor | FDFD::ABCD:3 | | Resource directory | FDFD::ABCD:0 | +--------------------+--------------+ Table 2: interface SLAAC addresses Shelby, et al. Expires January 8, 2017 [Page 40] =0C Internet-Draft CoRE Resource Directory July 2016 In Section 13.1.2 the use of resource directory during installation is presented. In Section 13.1.3 the connection to DNS is discussed. 13.1.2. RD entries It is assumed that access to the DNS infrastructure is not always possible during installation. Therefore, the SLAAC addresses are used in this section. For discovery, the resource types (rt) of the devices are important. The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor. The endpoints have names which are relevant to the light installation manager. In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door. The endpoint names reflect this physical location. The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively. The identifiers relevant to the Resource Directory are shown in Table 3 below: +----------------+------------------+---------------+---------------+ | Name | endpoint | resource path | resource type | +----------------+------------------+---------------+---------------+ | luminary1 | lm_R2-4-015_wndw | /light/left | light | | luminary1 | lm_R2-4-015_wndw | /light/middle | light | | luminary1 | lm_R2-4-015_wndw | /light/right | light | | luminary2 | lm_R2-4-015_door | /light/left | light | | luminary2 | lm_R2-4-015_door | /light/middle | light | | luminary2 | lm_R2-4-015_door | /light/right | light | | Presence | ps_R2-4-015_door | /ps | p-sensor | | sensor | | | | +----------------+------------------+---------------+---------------+ Table 3: Resource Directory identifiers The CT inserts the endpoints of the luminaries and the sensor in the RD using the Context parameter (con) to specify the interface address: Shelby, et al. Expires January 8, 2017 [Page 41] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_wndw&con=3Dcoap://[FDFD::ABCD:1] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light";d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4521 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:2] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4522 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dps_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:3] Payload: ;rt=3D"p-sensor"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4523 The domain name d=3D"R2-4-015" has been added for an efficient lookup because filtering on "ep" name is more awkward. The same domain name is communicated to the two luminaries and the presence sensor by the CT. The group is specified in the RD. The Context parameter is set to the site-local multicast address allocated to the group. In the POST in the example below, these two endpoints and the endpoint of the presence sensor are registered as members of the group. Req: POST coap://[FDFD::ABCD:0]/rd-group ?gp=3Dgrp_R2-4-015;con=3D"coap//[FF05::1]";exp;ins=3D"grp1234" Payload: <>ep=3Dlm_R2-4-015_wndw, <>ep=3Dlm_R2-4-015_door, <>ep=3Dps_R2-4-015_door Res: 2.01 Created Location: /rd-group/501 Shelby, et al. Expires January 8, 2017 [Page 42] =0C Internet-Draft CoRE Resource Directory July 2016 After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. The luminary, knowing its domain, queries the RD for the endpoint with rt=3Dlight and d=3DR2-4-015. The RD returns all endpoints in = the domain. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep ?d=3DR2-4-015;rt=3Dlight Res: 2.05 Content ; ep=3D"lm_R2-4-015_wndw", ; ep=3D"lm_R2-4-015_door" Knowing its own IPv6 address, the luminary discovers its endpoint name. With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp ?ep=3Dlm_R2-4-015_wndw Res: 2.05 Content ;gp=3D"grp_R2-4-015" =46rom the context parameter value, the luminary learns the multicast address of the multicast group. Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in [RFC7390]. Req: POST //[FDFD::ABCD:1]/coap-group Content-Format: application/coap-group+json { "a": "[FF05::1]", "n": "grp_R2-4-015"} Res: 2.01 Created Location-Path: /coap-group/1 Dependent on the situation only the address ,"a", or the name, "n", is specified in the coap-group resource. Shelby, et al. Expires January 8, 2017 [Page 43] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.3. DNS entries It may be profitable to discover the light groups for applications, which are unaware ot the existence of the RD. An agent needs to query the RD to return all groups which are exported to be inserted into DNS. Req: GET /rd-lookup/gp?exp Res: 2.05 Content ;exp;gp=3D"grp_R2-4-015;ins=3D"grp1234"; ep=3D"lm_R2-4-015_wndw"; ep=3D"lm_R2-4-015_door The group with FQDN grp_R2-4-015.bc.example.com can be entered into the DNS by the agent. The accompanying instance name is grp1234. The is chosen to be _group._udp. The agent enters the following RRs into the DNS. grp_R2-4-015.bc.example.com. IN AAAA FF05::1 _group._udp.bc.example.com IN PTR grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com IN SRV 0 0 5683 grp_R2-4-015_door.bc.example.com. grp1234._group._udp.bc.example.com IN TXT txtver=3D1;path=3D/light/grp1 =46rom then on applications, not familiar with the existence of the = RD, can use DNS to access the lighting group. 13.2. OMA Lightweight M2M (LWM2M) Example This example shows how the OMA LWM2M specification makes use of Resource Directory (RD). OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority). LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing a Resource Directory along with other LWM2M interfaces defined by the LWM2M specification. CoRE Resource Directory (RD) is used to provide the LWM2M Registration interface. Shelby, et al. Expires January 8, 2017 [Page 44] =0C Internet-Draft CoRE Resource Directory July 2016 LWM2M does not provide for registration domains and does not currently use the rd-group or rd-lookup interfaces. The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server. Other interfaces, proxies, applications, and function sets are currently out of scope for LWM2M. The location of the LWM2M Server and RD Function Set is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD function set is used. LWM2M Servers and endpoints are not required to implement the ./well-known/core resource. 13.2.1. The LWM2M Object Model The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. An LWM2M Object is a resource template and container type that encapsulates a set of related resources. An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings. base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined". As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". [_TEMPLATE_TODO] Shelby, et al. Expires January 8, 2017 [Page 45] =0C Internet-Draft CoRE Resource Directory July 2016 base-uri :=3D Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id :=3D OMNA (OMA Name Authority) registered object ID = (0-65535) object-instance :=3D Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id :=3D OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance :=3D Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings. For example, a LWM2M URI might be: /1/0/1 The base uri is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined". This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 13.2.2. LWM2M Register Endpoint LWM2M defines a registration interface based on the Resource Directory Function Set, described in Section 6. The URI of the LWM2M Resource Directory function set is specified to be "/rd" as recommended in Section 6.3. LWM2M endpoints register object IDs, for example , to indicate that a particular object type is supported, and register object instances, for example , to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format. Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. Shelby, et al. Expires January 8, 2017 [Page 46] =0C Internet-Draft CoRE Resource Directory July 2016 When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in Table 1 : ep - Endpoint Name lt - registration lifetime Endpoint Name is mandatory, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 4: LWM2M Additional Registration Parameters The following RD registration parameters are not currently specified for use in LWM2M: et - Endpoint Type con - Context The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: ,,, This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. Shelby, et al. Expires January 8, 2017 [Page 47] =0C Internet-Draft CoRE Resource Directory July 2016 13.2.3. Alternate Base URI If the LWM2M endpoint exposes objects at a base URI other than the default empty base path, the endpoint must register the base URI using rt=3D"oma.lwm2m". An example link payload using alternate base URI would be: ;rt=3D"oma.lwm2m",,, This link payload indicates that the lwm2m objects will be placed under the base URI "/my_lwm2m" and that object ID 1 (server) is supported, with a single instance 0 existing, and object 5 (firmware update) is supported. 13.2.4. LWM2M Update Endpoint Registration An LWM2M Registration update proceeds as described in Section 6.4, and adds some optional parameter updates: lt - Registration Lifetime b - Protocol Binding sms - MSISDN link payload - new or modified links A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. 13.2.5. LWM2M De-Register Endpoint LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation. LWM2M de- registration proceeds as described in Section 6.5. 14. Acknowledgments Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided helpful comments, discussions and ideas to improve and shape this document. Section 9 is based on an earlier draft by Kerry Lynn. Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. Shelby, et al. Expires January 8, 2017 [Page 48] =0C Internet-Draft CoRE Resource Directory July 2016 15. Changelog changes from -07 to -08 o removed link target value returned from domain and group lookup types o Maximum length of domain parameter 63 bytes for consistency with group o removed option for simple POST of link data, don't require a .well-known/core resource to accept POST data and handle it in a special way; we already have /rd for that o add IPv6 ND Option for discovery of an RD o clarify group configuration section 6.1 that endpoints must be registered before including them in a group o removed all superfluous client-server diagrams o simplified lighting example o introduced Commissioning Tool o RD-Look-up text is extended. changes from -06 to -07 o added text in the discovery section to allow content format hints to be exposed in the discovery link attributes o editorial updates to section 9 o update author information o minor text corrections Changes from -05 to -06 o added note that the PATCH section is contingent on the progress of the PATCH method changes from -04 to -05 o added Update Endpoint Links using PATCH o http access made explicit in interface specification Shelby, et al. Expires January 8, 2017 [Page 49] =0C Internet-Draft CoRE Resource Directory July 2016 o Added http examples Changes from -03 to -04: o Added http response codes o Clarified endpoint name usage o Add application/link-format+cbor content-format Changes from -02 to -03: o Added an example for lighting and DNS integration o Added an example for RD use in OMA LWM2M o Added Read Links operation for link inspection by endpoints o Expanded DNS-SD section o Added draft authors Peter van der Stok and Michael Koster Changes from -01 to -02: o Added a catalogue use case. o Changed the registration update to a POST with optional link format payload. Removed the endpoint type update from the update. o Additional examples section added for more complex use cases. o New DNS-SD mapping section. o Added text on endpoint identification and authentication. o Error code 4.04 added to Registration Update and Delete requests. o Made 63 bytes a SHOULD rather than a MUST for endpoint name and resource type parameters. Changes from -00 to -01: o Removed the ETag validation feature. o Place holder for the DNS-SD mapping section. o Explicitly disabled GET or POST on returned Location. Shelby, et al. Expires January 8, 2017 [Page 50] =0C Internet-Draft CoRE Resource Directory July 2016 o New registry for RD parameters. o Added support for the JSON Link Format. o Added reference to the Groupcomm WG draft. Changes from -05 to WG Document -00: o Updated the version and date. Changes from -04 to -05: o Restricted Update to parameter updates. o Added pagination support for the Lookup interface. o Minor editing, bug fixes and reference updates. o Added group support. o Changed rt to et for the registration and update interface. Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten. o Editorial improvements. o Fixed the use of ETags. o Fixed tickets 383 and 372 Changes from -02 to -03: o Changed the endpoint name back to a single registration parameter ep=3D and removed the h=3D and ins=3D parameters. o Updated REST interface descriptions to use RFC6570 URI Template format. o Introduced an improved RD Lookup design as its own function set. o Improved the security considerations section. o Made the POST registration interface idempotent by requiring the ep=3D parameter to be present. Shelby, et al. Expires January 8, 2017 [Page 51] =0C Internet-Draft CoRE Resource Directory July 2016 Changes from -01 to -02: o Added a terminology section. o Changed the inclusion of an ETag in registration or update to a MAY. o Added the concept of an RD Domain and a registration parameter for it. o Recommended the Location returned from a registration to be stable, allowing for endpoint and Domain information to be changed during updates. o Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 16. References 16.1. Normative References [I-D.ietf-core-links-json] Li, K., Rahman, A., and D. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-05 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . Shelby, et al. Expires January 8, 2017 [Page 52] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . 16.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Shelby, et al. Expires January 8, 2017 [Page 53] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . Editorial Comments [_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert. Authors' Addresses Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Michael Koster SmartThings 665 Clyde Avenue Mountain View 94043 USA Phone: +1-707-502-5136 Email: Michael.Koster@smartthings.com Shelby, et al. Expires January 8, 2017 [Page 54] =0C Internet-Draft CoRE Resource Directory July 2016 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Shelby, et al. Expires January 8, 2017 [Page 55] --Apple-Mail=_0AFF04ED-BE46-49E3-BF7A-08D427E3A0CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Jul 8, 2016, at 7:36 AM, Michael Koster <michael.koster@smartthings.com> wrote:

This is = important for clients that can not process large payloads, to be able tp = paginate the output.

It is meant to work like the common ?start=3D21&count=3D10 = used for web pages.

I don't know why "page" and not "start". 

I could add some text = and an example.

Michael

On Jul 7, 2016, at 11:42 PM, Oscar Novo <oscar.novo@ericsson.com> wrote:

         I = provided you some comment about Page and = count in the = lookup some time ago. I think those two elements are extremely unclear = and need to be explained better or removed.
=C2=B7         What does the ct:40 means in the following example?



= --Apple-Mail=_0AFF04ED-BE46-49E3-BF7A-08D427E3A0CA-- --Apple-Mail=_71DAEC08-D10B-4119-AA80-F05C8B25A262-- From nobody Fri Jul 8 08:06:08 2016 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 801B912D784; Fri, 8 Jul 2016 08:05:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708150553.32160.26131.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 08:05:53 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:05:54 -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 Markup Language (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-01.txt Pages : 32 Date : 2016-07-08 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-senml-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-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 Fri Jul 8 08:22:59 2016 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 7713212D7D9 for ; Fri, 8 Jul 2016 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_NEUTRAL=0.779] autolearn=ham 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 AxkeHF12ZmEx for ; Fri, 8 Jul 2016 08:22:54 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 DA60A12D7F0 for ; Fri, 8 Jul 2016 08:22:48 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id c2so13778211pfa.2 for ; Fri, 08 Jul 2016 08:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7bKrr+gB7vybrIiLNNAGEFxjdO/pMR9s67L9Q57WfiE=; b=1tgZt4E/vwpZ7syMNXhR6LgMz+R9fcQb1H4CkjUqEjQJUuEUyQTZv5hKPjtasOy8em h7NNrXFE1YraWVBgd43jY84Ap6x13e1lsKNK+iT+KMxPsd0iVdZNzmiYFIePTHwM+EDP Y9bHbfDn2U3tZ8NMBq1Onat5dB+/AETKXBte9YDHIkhB10cmGvMnyLqmD04w+H8d4GzV Yjoao0vR5n8Q2yjunw0OUqcXyjhGUlR95IQx1CdFhtRTCQ80kewusXuY8TjyNX/r0WSY 4cja//eR7B6I+GsEs8RSI/BD+VdxlM1+RLzuCWW5jLEps0CVh00ESBTIgtUzDAXOi1L6 wHgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7bKrr+gB7vybrIiLNNAGEFxjdO/pMR9s67L9Q57WfiE=; b=PLabX1eJt0XgJOEap0TSxTPqkNC8m2enezbbugFbQ4fWM/kd6sx1hd8CvbPITHNhNj 5kwo42kwouj9O59Ro2qJ+654IUPjS3dJyDRcXOBZT51IWdz6C4VM0qw1Dlssi9JNxt6/ 2pESzqdJUFxDKDzEnaAiN9RotxfiPmo3ijeXNXUUCTJnF6dlZrwCURf3wSxP3gzqi757 4bZ8lq1OD+VJu+LeBoQ29TjxTXGSWHkM2w0W4rC/yz70yqsVaflSWPsu/fYj/TTMrv0O DGia39E06SuORiLPbcN7Q0C6UL1xKZxJ690qE6JXfe6aAeP2TeFuUGn4W7Pb3OLSG//b YTxg== X-Gm-Message-State: ALyK8tL+8gMUhjliYuXwduUAvkjyEWSOABtfw+HZTOptiYr5mhJzuQtMCZiUPc9oVWB6XIQC X-Received: by 10.98.89.210 with SMTP id k79mr10855959pfj.152.1467991368409; Fri, 08 Jul 2016 08:22:48 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id x68sm5538211pfb.88.2016.07.08.08.22.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 08:22:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E35F60A3-302B-43EE-9459-1ED6FA84ABC3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> Date: Fri, 8 Jul 2016 08:22:41 -0700 Message-Id: <36EADFEA-0B01-436A-95FD-592ECC408127@smartthings.com> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-core-resource-directory@tools.ietf.org" , Oscar Novo , "core@ietf.org" , Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 15:22:57 -0000 --Apple-Mail=_E35F60A3-302B-43EE-9459-1ED6FA84ABC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have addressed everything except these 2 comments: > On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias = wrote: >=20 > 6.6. Read Endpoint Links > Is there any functionality that is not provided through the lookup = interface (apart from a quicker ep selection)? >=20 > As part of the RD evolution, a GET on the handle resource should = primarily return the forms to update and delete the registration. Forms = that are pre-filled with the endpoint information could enable a nice = collection-based lookup for management. >=20 What would be the content-format used to transmit the forms? I would = expect GET on a collection with the content format of the resource to = return a representation of the resource content, in this case the links = in the collection. How should we indicate the hypermedia controls of the = resource? I think we need to give this a little more thought, how to = expose the controls of a resource vs. the content.=20 In the meantime, the lookup interface could be used for inspection but = the idea of having read and patch update as operations on the links of = one endpoint seems useful for doing read-modify-write workflow on links. = It's useful to use the same URI for the resource instead of having to = construct a different address to read vs update. Also I think discovery = (lookup), modifying links, and registration refresh are logically = separate workflows in the client. > 6.7. Update Endpoint Links > Shouldn't this be merged with Section 6.4. Registration Update? See above reason based on separate workflows. Does it make sense? Best regards, Michael --Apple-Mail=_E35F60A3-302B-43EE-9459-1ED6FA84ABC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I have addressed everything except these 2 comments:

On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:

6.6.  Read Endpoint Links
Is there any functionality that is not provided = through the lookup interface (apart from a quicker ep = selection)?

As part of the RD = evolution, a GET on the handle resource should primarily return the = forms to update and delete the registration. Forms that are pre-filled = with the endpoint information could enable a nice collection-based = lookup for management.

What would be the content-format used to = transmit the forms? I would expect GET on a collection with the content = format of the resource to return a representation of the resource = content, in this case the links in the collection. How should we = indicate the hypermedia controls of the resource? I think we need to = give this a little more thought, how to expose the controls of a = resource vs. the content. 

In = the meantime, the lookup interface could be used for inspection but the = idea of having read and patch update as operations on the links of one = endpoint seems useful for doing read-modify-write workflow on links. = It's useful to use the same URI for the resource instead of having to = construct a different address to read vs update.  Also I think = discovery (lookup), modifying links, and registration refresh are = logically separate workflows in the client.
6.7.  =
Update Endpoint Links
Shouldn't this be = merged with Section 6.4. Registration Update?

See above reason based on separate workflows. Does = it make sense?

Best = regards,

Michael

= --Apple-Mail=_E35F60A3-302B-43EE-9459-1ED6FA84ABC3-- From nobody Fri Jul 8 08:32:26 2016 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 3517712D096 for ; Fri, 8 Jul 2016 08:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 U0U0VevCIBIh for ; Fri, 8 Jul 2016 08:32:10 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 3B13912D822 for ; Fri, 8 Jul 2016 08:32:06 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id b13so13333885pat.0 for ; Fri, 08 Jul 2016 08:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=+GpI2jEEFnN/TcQ46LEhAHzFAnyUYKC12zq5UGztSgY=; b=BXge/7YzaQdAlP8n8t3rDAJeDQ9wXIUkZghV0opLbNsY3/Vc5vOBnjThJ2S01Dcoel qoXfB0NP/EPZ70PYL0O9EPjQTuSGO/3DNjimYgnhSJSJMT55nMr6R7Uhb5e/3lqpv86r DA6JgJyXUJMWto9QjIsc6PA4rznU3WoGGfxsOmnKrM4Qm5QBBuxeObOymXwRdxPRczSk um+OVz4ToVrw32aeQKLOFqyo7snuH6nC1167yn4oqaIDjw1eI1p7364I/e2vpwcx34jR jQpfY08w4QVgy2JDPyfJdzVEUL+rH95k9MGBVb/Iy7MjReWjtCRTR1m59zQjjpaQHLEq iJPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+GpI2jEEFnN/TcQ46LEhAHzFAnyUYKC12zq5UGztSgY=; b=WaMewCuFbDPG+0GOOBxUHWIgPB56KPT1EFSsAJ7yrMfQS22rSH2UaSMjkaPkcsVONM xiD3WoCri1LM+MXnKjAZnH4IgxOYFsiXREYQWz3H5BVJ8MZYvteijh+XfyRIb7ugiFQC VqJlbEJlQrV0ihCOjsWCfY4yMMtdEIebY4AUbH6Z8vAD0uw/XQZX77bwJ+Pfsz64ZSx/ QBeVy7Ccr8teX/O69cqxVWuZDR6/SNA0yGrQFpY0b6Ex1aQC/pBQSaqCB2HzqEiF7MnU NlURhtC3TUq8VocERN520+6G3d70Ov7j5xBHcVwdLy9CF2/3gdpcdFxOc/Ps//kc+ZIs pB9Q== X-Gm-Message-State: ALyK8tK5JIt0lKc2tt5TgjByf4bg84skrYLUXApGIjWuGYB2AB5QwgmfZrPjvc/F991zttz1 X-Received: by 10.66.249.161 with SMTP id yv1mr10941929pac.39.1467991925805; Fri, 08 Jul 2016 08:32:05 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id a87sm5569035pfc.63.2016.07.08.08.32.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 08:32:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_287A5426-06E0-47A7-8847-333F88238132" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <36EADFEA-0B01-436A-95FD-592ECC408127@smartthings.com> Date: Fri, 8 Jul 2016 08:32:02 -0700 Message-Id: References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> <36EADFEA-0B01-436A-95FD-592ECC408127@smartthings.com> To: Michael Koster X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Hannes Tschofenig , "draft-ietf-core-resource-directory@tools.ietf.org" , Oscar Novo , "core@ietf.org" Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 15:32:23 -0000 --Apple-Mail=_287A5426-06E0-47A7-8847-333F88238132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 couple more nits > On Jul 8, 2016, at 8:22 AM, Michael Koster = wrote: >=20 > I have addressed everything except these 2 comments: >=20 >> On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias > wrote: >>=20 >> 6.6. Read Endpoint Links >> Is there any functionality that is not provided through the lookup = interface (apart from a quicker ep selection)? >>=20 >> As part of the RD evolution, a GET on the handle resource should = primarily return the forms to update and delete the registration. Forms = that are pre-filled with the endpoint information could enable a nice = collection-based lookup for management. >>=20 > What would be the content-format used to transmit the forms? I would = expect GET on a collection with the content format of the resource to = return a representation of the resource content, in this case the links = in the collection. How should we indicate the hypermedia controls of the = resource? I think we need to give this a little more thought, how to = expose the controls of a resource vs. the content.=20 >=20 > In the meantime, the lookup interface could be used for inspection but = the idea of having read and patch update as operations on the links of = one endpoint seems useful for doing read-modify-write workflow on links. = It's useful to use the same URI for the resource instead of having to = construct a different address to read vs update. Also I think discovery = (lookup), modifying links, and registration refresh are logically = separate workflows in the client. >> 6.7. Update Endpoint Links >> Shouldn't this be merged with Section 6.4. Registration Update? >=20 > See above reason based on separate workflows. Does it make sense? >=20 > Best regards, >=20 > Michael >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_287A5426-06E0-47A7-8847-333F88238132 Content-Type: multipart/mixed; boundary="Apple-Mail=_CFC45CA3-A912-4DE2-AE6C-D5F652FE53A4" --Apple-Mail=_CFC45CA3-A912-4DE2-AE6C-D5F652FE53A4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 couple more nits

--Apple-Mail=_CFC45CA3-A912-4DE2-AE6C-D5F652FE53A4 Content-Disposition: attachment; filename=draft-ietf-core-resource-directory-xx.txt Content-Type: text/plain; name="draft-ietf-core-resource-directory-xx.txt" Content-Transfer-Encoding: quoted-printable CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster Expires: January 8, 2017 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant July 07, 2016 CoRE Resource Directory draft-ietf-core-resource-directory-08 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 resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Shelby, et al. Expires January 8, 2017 [Page 1] =0C Internet-Draft CoRE Resource Directory July 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 4. Finding a Directory Server . . . . . . . . . . . . . . . . . 8 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 9 5. Simple Registration . . . . . . . . . . . . . . . . . . . . . 10 5.1. Simple publishing to Resource Directory Server . . . . . 11 5.2. Third-party registration . . . . . . . . . . . . . . . . 12 6. Resource Directory Function Set . . . . . . . . . . . . . . . 12 6.1. Content Formats . . . . . . . . . . . . . . . . . . . . . 13 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Registration . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Registration Update . . . . . . . . . . . . . . . . . . . 18 6.5. Registration Removal . . . . . . . . . . . . . . . . . . 20 6.6. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 21 6.7. Update Endpoint Links . . . . . . . . . . . . . . . . . . 22 7. Group Function Set . . . . . . . . . . . . . . . . . . . . . 24 7.1. Register a Group . . . . . . . . . . . . . . . . . . . . 24 7.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 26 8. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 27 9. New Link-Format Attributes . . . . . . . . . . . . . . . . . 32 9.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 32 9.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 33 10. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. DNS-based Service discovery . . . . . . . . . . . . . . 33 10.2. mapping ins to . . . . . . . . . . . . . . . 34 10.3. Mapping rt to . . . . . . . . . . . . . . 35 10.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 35 Shelby, et al. Expires January 8, 2017 [Page 2] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings . . . . . . . . . . . . . . = 35 10.6. Importing resource links into DNS-SD . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11.1. Endpoint Identification and Authentication . . . . . . . 37 11.2. Access Control . . . . . . . . . . . . . . . . . . . . . 37 11.3. Denial of Service Attacks . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 38 12.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 38 12.3. IPv6 ND Resource Directory Address Option . . . . . . . 38 12.4. RD Parameter Registry . . . . . . . . . . . . . . . . . 38 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. Lighting Installation . . . . . . . . . . . . . . . . . 39 13.1.1. Installation Characteristics . . . . . . . . . . . . 40 13.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 41 13.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 44 13.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 44 13.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 45 13.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 46 13.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 48 13.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 48 13.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 48 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.1. Normative References . . . . . . . . . . . . . . . . . . 52 16.2. Informative References . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Linking [RFC5988]. The use of Web Linking for the description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format [RFC6690]. However, [RFC6690] only describes how to discover resources from the web server that hosts them by requesting "/.well-known/core". In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast Shelby, et al. Expires January 8, 2017 [Page 3] =0C Internet-Draft CoRE Resource Directory July 2016 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 a Resource Directory are defined. Although the examples in this document show the use of these interfaces with CoAP [RFC7252], they can be applied in an equivalent manner to HTTP [RFC7230]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "byte" is used in its now customary sense as a synonym for "octet". This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252]. To describe the REST interfaces defined in this specification, the URI Template format is used [RFC6570]. This specification makes use of the following additional terminology: Resource Directory A web entity that stores information about web resources and implements the REST interfaces defined in this specification for registration and lookup of those resources. Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Group In the context of a Resource Directory, a group is a logical grouping of endpoints for the purpose of group communications. All groups within a domain are unique. Endpoint Shelby, et al. Expires January 8, 2017 [Page 4] =0C Internet-Draft CoRE Resource Directory July 2016 Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. 3. Architecture and Use Cases The resource directory architecture is illustrated in Figure 1. A Resource Directory (RD) is used as a repository for Web Links [RFC5988] about resources hosted on other web servers, which are called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory entries), and for clients to lookup resources from the RD or maintain groups. Endpoints themselves can also act as clients. An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured by an outside entity. This information hierarchy is shown in Figure 2. Endpoints are assumed to proactively register and maintain resource directory entries on the RD, which are soft state and need to be periodically refreshed. An endpoint is provided with interfaces to register, update and remove a resource directory entry. Furthermore, a mechanism to discover an RD using the CoRE Link Format [RFC6690] is defined. It is also possible for an RD to proactively discover Web Links from endpoints and add them as resource directory entries. A lookup interface for discovering any of the Web Links held in the RD is provided using the CoRE Link Format. Shelby, et al. Expires January 8, 2017 [Page 5] =0C Internet-Draft CoRE Resource Directory July 2016 Registration Lookup, Group Interface Interfaces +----+ | | | EP |---- | | +----+ ---- | | --|- +------+ | +----+ | ----| | | +--------+ | EP | ---------|-----| RD |----|-----| Client | +----+ | ----| | | +--------+ --|- +------+ | +----+ ---- | | | EP |---- | | +----+ Figure 1: The resource directory architecture. +------------+ | Domain | <-- Name +------------+ | | | +------------+ | | Group | <-- Name, Scheme, IP, Port | +------------+ | | +------------+ | Endpoint | <-- Name, Scheme, IP, Port +------------+ | | +------------+ | Resource | <-- Target, Parameters +------------+ Figure 2: The resource directory information hierarchy. 3.1. Use Case: Cellular M2M Over the last few years, mobile operators around the world have focused on development of M2M solutions in order to expand the business to the new type of users: machines. The machines are connected directly to a mobile network using an appropriate embedded air interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and wide range wireless interfaces. =46rom the system design point = of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application Shelby, et al. Expires January 8, 2017 [Page 6] =0C Internet-Draft CoRE Resource Directory July 2016 requirements, thus avoiding silo like solutions. One of the crucial enablers of such design is the ability to discover resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities. Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs. The address of each (proxy) endpoint on this server is included in the resource description stored in the RD. The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database. Similarly, fleet management systems provide the appropriate link parameters to the RD to look up for EPs deployed on the vehicles the application is responsible for. 3.2. Use Case: Home and Building Automation Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. The exporting of resource information to other discovery systems is also important in these automation applications. In home automation there is a need to interact with other consumer electronics, which may already support DNS-SD, and in building automation DNS-SD in combination with resource directories can cover multiple buildings. 3.3. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted Shelby, et al. Expires January 8, 2017 [Page 7] =0C Internet-Draft CoRE Resource Directory July 2016 anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use the Resource Directory lookup function set to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in web link compatible representations are supplied by Resource Directories, which may be internally stored as triples, or relation/attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to common web linking formats for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms should generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. This provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. 4. Finding a Directory Server Endpoints that want to contact a directory server can obtain candidate IP addresses for such servers in a number of ways. In a 6LoWPAN, good candidates can be taken from: o specific static configuration (e.g., anycast addresses), if any, o the ABRO option of 6LoWPAN-ND [RFC6775], o other ND options that happen to point to servers (such as RDNSS), o DHCPv6 options that might be defined later. o The IPv6 Neighbor Discovery Resource Directory Address Option described in Section 4.1 Shelby, et al. Expires January 8, 2017 [Page 8] =0C Internet-Draft CoRE Resource Directory July 2016 In networks with more inexpensive use of multicast, the candidate IP address may be a well-known multicast address, i.e. directory servers are found by simply sending GET requests to that well-known multicast address (see Section 6.2). As some of these sources are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate- limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. 4.1. Resource Directory Address Option (RDAO) The Resource Directory Option (RDAO) using IPv6 neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with link-local multicast address because the endpoint and the RD are separated by a border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network. The presence and the use of the RD is essential during commissioning. The RDAO format is: Shelby, et al. Expires January 8, 2017 [Page 9] =0C Internet-Draft CoRE Resource Directory July 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length =3D 3 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RD Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 38 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this set of border router information is valid. A value of all zero bits (0x0) assumes a default value of 10,000 (~one week). Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. RD Address: IPv6 address of the RD. Figure 3: Resource Directory Address Option 5. Simple Registration Not all endpoints hosting resources are expected to know how to implement the Resource Directory Function Set (see Section 6) hence cannot register with a Resource Directory. Instead, simple endpoints can implement the generic Simple Directory Discovery approach described in this section. An RD implementing this specification MUST implement Simple Directory Discovery. However, there may be Shelby, et al. Expires January 8, 2017 [Page 10] =0C Internet-Draft CoRE Resource Directory July 2016 security reasons why this form of directory discovery would be disabled. This approach requires that the endpoint makes available the hosted resources that it wants to be discovered, as links on its "/.well- known/core" interface as specified in [RFC6690]. The endpoint then finds one or more addresses of the directory server as described in Section 4. An endpoint can send (a selection of) hosted resources to a directory server for publication as described in Section 5.1. The directory server integrates the information it received this way into its resource directory. It MAY make the information available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 5.1. Simple publishing to Resource Directory Server An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. The endpoint MAY include registration parameters in the POST request as per Section 6.3 The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. Shelby, et al. Expires January 8, 2017 [Page 11] =0C Internet-Draft CoRE Resource Directory July 2016 Req:(to RD server from [ff02::1]) POST coap://rd.example.com/.well-known/core?lt=3D6000 Content-Format: 40 payload: (empty payload) Res: 2.04 Changed (later) Req: (from RD server to [ff02::1]) GET coap://[ff02::1]/.well-known/core Accept: 40 Res: 2.05 Content payload: 5.2. Third-party registration For some applications, even Simple Directory Discovery may be too taxing for certain very constrained devices, in particular if the security requirements become too onerous. In a controlled environment (e.g. building control), the Resource Directory can be filled by a third device, called a commissioning tool. The commissioning tool can fill the Resource Directory from a database or other means. For that purpose the scheme, IP address and port of the registered device is indicated in the Context parameter of the registration described in Section 6.3. 6. Resource Directory Function Set This section defines the REST interfaces between an RD and endpoints, which is called the Resource Directory Function Set. Although the examples throughout this section assume the use of CoAP [RFC7252], these REST interfaces can also be realized using HTTP [RFC7230]. In all definitions in this section, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces defined in this section. Shelby, et al. Expires January 8, 2017 [Page 12] =0C Internet-Draft CoRE Resource Directory July 2016 Resource directory entries are designed to be easily exported to other discovery mechanisms such as DNS-SD. For that reason, parameters that would meaningfully be mapped to DNS SHOULD be limited to a maximum length of 63 bytes. 6.1. Content Formats Resource Directory implementations using this specification MUST support the application/link-format content format (ct=3D40). Resource Directories implementing this specification MAY support additional content formats. Any additional content format supported by a Resource Directory implementing this specification MUST have an equivalent serialization in the application/link-format content format. 6.2. Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the path of its RD Function Set. There can be several mechanisms for discovering the RD including assuming a default location (e.g. on an Edge Router in a LoWPAN), by assigning an anycast address to the RD, using DHCP, or by discovering the RD using the CoRE Link Format (see also Section 4). This section defines discovery of the RD using the well-known interface of the CoRE Link Format [RFC6690] as the required mechanism. It is however expected that RDs will also be discoverable via other methods depending on the deployment. Discovery of the RD function set is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup" is used to discover the RD Lookup Function Set. Upon success, the response will contain a payload with a link format entry for each RD discovered, with the URL indicating the root resource of the RD. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link attribute, as shown in the example below. Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. Shelby, et al. Expires January 8, 2017 [Page 13] =0C Internet-Draft CoRE Resource Directory July 2016 HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. An RD implementation of this specification MUST support query filtering for the rt parameter as defined in [RFC6690]. The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt :=3D Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : YES (Unicast only) The following example shows an endpoint discovering an RD using this interface, thus learning that the base RD resource is, in this Shelby, et al. Expires January 8, 2017 [Page 14] =0C Internet-Draft CoRE Resource Directory July 2016 example, at /rd and that the content_format delivered by the server hosting the resource is application.xml (ct=3D40). Note that it is = up to the RD to choose its base RD resource, although diagnostics and debugging is facilitated by using the base paths specified here where possible. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup";ct=3D40, ;rt=3D"core.rd-group";ct=3D40 The following example shows the way of indicating that a client may request alternate content-formats. The Content-Format code attribute "ct" MAY include a space-separated sequence of Content-Format codes as specified in [RFC7252], indicating that multiple content-formats are available. The example below shows the required ct=3D40 (application/link-format) indicated as well as a vendor-specific content format (21225). Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 21225", ;rt=3D"core.rd-lookup";ct=3D"40 21225", ;rt=3D"core.rd-group";ct=3D"40 21225" 6.3. Registration After discovering the location of an RD Function Set, an endpoint MAY register its resources using the registration interface. This interface accepts a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link- format+json), or CBOR CoRE Link Format (application/link-format+cbor) [I-D.ietf-core-links-json], along with query string parameters indicating the name of the endpoint, its domain and the lifetime of the registration. All parameters except the endpoint name are optional. It is expected that other specifications will define further parameters (see Section 12.4). The RD then creates a new resource or updates an existing resource in the RD and returns its location. An endpoint MUST use that location when refreshing registrations using this interface. Endpoint resources in the RD are kept active for the period indicated by the lifetime parameter. The endpoint is responsible for refreshing the entry within this period using either the registration or update interface. The registration interface MUST be implemented to be idempotent, so that registering Shelby, et al. Expires January 8, 2017 [Page 15] =0C Internet-Draft CoRE Resource Directory July 2016 twice with the same endpoint parameter does not create multiple RD entries. A new registration may be created at any time to supercede an existing registration, replacing the registration parameters and links. The registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd :=3D RD Function Set path (mandatory). This is the path of = the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10). et :=3D Endpoint Type (optional). The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Shelby, et al. Expires January 8, 2017 [Page 16] =0C Internet-Draft CoRE Resource Directory July 2016 Content-Format: application/link-format+cbor The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new resource entry for the endpoint. This Location MUST be a stable identifier generated by the RD as it is used for all subsequent operations on this registration. The resource returned in the Location is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered links, including updating and deleting links. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. The resulting location /rd/4521 is just an example of an RD generated location. Req: POST coap://rd.example.com/rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 Req: POST /rd?ep=3Dnode1 HTTP/1.1 Host : example.com Content-Type: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 Shelby, et al. Expires January 8, 2017 [Page 17] =0C Internet-Draft CoRE Resource Directory July 2016 6.4. Registration Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the resource returned in the Location option in the response to the first registration. An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 6.3 ) if they have changed since the last registration or update. Parameters that have not changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in {registration}. Upon receiving an update request, an RD MUST reset the timeout for that endpoint and update the scheme, IP address and port of the endpoint, using the source address of the update, or the context ("con") parameter if present. If the lifetime parameter "lt" is included in the received update request, the RD MUST update the lifetime of the registration and set the timeout equal to the new lifetime. An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if both the target URI and relation type match. In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 6.7. The update registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. Shelby, et al. Expires January 8, 2017 [Page 18] =0C Internet-Draft CoRE Resource Directory July 2016 con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. Optional. In the absence of this parameter the scheme of the protocol, source IP address and source port used to register are assumed. This parameter is compulsory when the directory is filled by a third party such as a commissioning tool. Content-Format: application/link-format (mandatory) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint updating its registration at an RD using this interface. Req: POST /rd/4521 Res: 2.04 Changed The following example shows an endpoint updating its registration with a new lifetime and context, changing an existing link, and adding a new link using this interface. With the initial registration the client set the following values: o lifetime (lt)=3D500 o context (con)=3Dcoap://local-proxy-old.example.com:5683 o resource=3D ;ct=3D41;rt=3D"foobar";if=3D"sensor" Shelby, et al. Expires January 8, 2017 [Page 19] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST /rd/4521?lt=3D600&con=3D"coap://local-proxy.example.com:5683"= Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-f";if=3D"sensor", ;ct=3D41;rt=3D"door";if=3D"sensor" Res: 2.04 Changed 6.5. Registration Removal Although RD entries have soft state and will eventually timeout after their lifetime, an endpoint SHOULD explicitly remove its entry from the RD if it knows it will no longer be available (for example on shut-down). This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. The removal request interface is specified as follows: Interaction: EP -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the endpoint from the RD. Shelby, et al. Expires January 8, 2017 [Page 20] =0C Internet-Draft CoRE Resource Directory July 2016 Req: DELETE /rd/4521 Res: 2.02 Deleted 6.6. Read Endpoint Links Some endpoints may wish to manage their links as a collection, and may need to read the current set of links in order to determine link maintenance operations. One or more links MAY be selected by using query filtering as specified in [RFC6690] Section 4.1 The read request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" upon success with an "application/link-format", "application/link-format+cbor", or "application/link-format+json" payload. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires January 8, 2017 [Page 21] =0C Internet-Draft CoRE Resource Directory July 2016 The following examples show successful read of the endpoint links from the RD. Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" 6.7. Update Endpoint Links [This section will be removed before or as a result of a working- group last-call if the PATCH methods do not achieve the same level of consensus as the present document.] A PATCH update adds, removes or changes links for the endpoint by including link update information in the payload of the update as a merge-patch+json format [RFC7396] document. One or more links are selected for update by using query filtering as specified in [RFC6690] Section 4.1 The query filter selects the links to be modified or deleted, by matching the query parameter values to the values of the link attributes. When the query parameters are not present in the request, the payload specifies links to be added to the target document. When the query parameters are present, the attribute names and values in the query parameters select one or more links on which to apply the PATCH operation. If an attribute name specified in the PATCH document exists in any the set of selected links, all occurrences of the attribute value in the target document MUST be updated using the value from the PATCH payload. If the attribute name is not present in any selected links, the attribute MUST be added to the links. The update request interface is specified as follows: Interaction: EP -> RD Method: PATCH URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 22] =0C Internet-Draft CoRE Resource Directory July 2016 location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 Content-Format: application/merge-patch+json (mandatory) The following response codes are defined for this interface: Success: 2.04 "Changed" 0r 204 "No Content" in the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration resource does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show an endpoint adding , modifying , and removing links in RD using the Update Endpoint Links function. The following example shows an EP adding the link ;ct=3D41;rt=3D"humid-s";if=3D"sensor" to the collection of = links at the location /rd/4521. Req: PATCH /rd/4521 Payload: [{"href":"/sensors/humid","ct": 41, "rt": "humid-s", "if": "sensor"}] Content-Format: application/merge-patch+json Res: 2.04 Changed The following example shows an EP modifying all links at the location /rd/4521 which are identified by href=3D"/sensors/temp", from the initial link-value of ;rt=3D"temperature" to the new link-value ;rt=3D"temperature-c";if=3D"sensor" by = changing Shelby, et al. Expires January 8, 2017 [Page 23] =0C Internet-Draft CoRE Resource Directory July 2016 the value of the link attribute "rt" and adding the link attribute if=3D"sensor" using the PATCH operation with the supplied merge- patch+json document payload. Req: PATCH /rd/4521?href=3D"/sensors/temp" Payload: {"rt": "temperature-c", "if": "sensor"}, Content-Format: application/merge-patch+json Res: 2.04 Changed This example shows an EP removing all links at the location /rd/4521 which are identified by href=3D"/sensors/light". Req: PATCH /rd/4521?href=3D"/sensors/light" Payload: {null} Content-Format: application/merge-patch+json Res: 2.04 Changed 7. Group Function Set This section defines a function set for the creation of groups of endpoints for the purpose of managing and looking up endpoints for group operations. The group function set is similar to the resource directory function set, in that a group may be created or removed. However unlike an endpoint entry, a group entry consists of a list of endpoints and does not have a lifetime associated with it. In order to make use of multicast requests with CoAP, a group MAY have a multicast address associated with it. 7.1. Register a Group In order to create a group, a commissioning tool (CT) used to configure groups, makes a request to the RD indicating the name of the group to create (or update), optionally the domain the group belongs to, and optionally the multicast address of the group. The registration message includes the list of endpoints that belong to that group. Shelby, et al. Expires January 8, 2017 [Page 24] =0C Internet-Draft CoRE Resource Directory July 2016 All the endpoints in the group MUST be registered with the RD before registering a group. If an endpoint is not yet registered to the RD before registering the group, the registration message returns an error. The RD sends a blank target URI for every endpoint link when registering the group. Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. The registration request interface is specified as follows: Interaction: CT -> RD Method: POST URI Template: /{+rd-group}{?gp,d,con} URI Template Variables: rd-group :=3D RD Group Function Set path (mandatory). This is = the path of the RD Group Function Set. An RD SHOULD use the value "rd-group" for this variable whenever possible. gp :=3D Group Name (mandatory). The name of the group to be created or replaced, unique within that domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this group = belongs. The maximum length of this parameter is 63 bytes. Optional. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10) con :=3D Context (optional). This parameter is used to set the = IP multicast address at which this server is available in the form scheme://multicast-address:port. Optional. In the absence of this parameter no multicast address is configured. This parameter is compulsory when the directory is filled by a commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 25] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new group entry. This Location MUST be a stable identifier generated by the RD as it is used for delete operations on this registration. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". An Endpoint is not registered in the RD (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface. The resulting location /rd-group/12 is just an example of an RD generated group location. Req: POST coap://rd.example.com/rd-group?gp=3Dlights Content-Format: 40 Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 2.01 Created Location: /rd-group/12 Req: POST /rd-group?gp=3Dlights HTTP/1.1 Host: example.com Content-Type: application/link-format Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 201 Created Location: /rd-group/12 7.2. Group Removal A group can be removed simply by sending a removal message to the location returned when registering the group. Removing a group MUST NOT remove the endpoints of the group from the RD. The removal request interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 26] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: CT -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful group registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the group from the RD. Req: DELETE /rd-group/12 Res: 2.02 Deleted 8. RD Lookup Function Set In order for an RD to be used for discovering resources registered with it, a lookup interface can be provided using this function set. This lookup interface is defined as a default, and it is assumed that RDs may also support lookups to return resource descriptions in alternative formats (e.g. Atom or HTML Link) or using more advanced interfaces (e.g. supporting context or semantic based lookup). This function set allows lookups for domains, groups, endpoints and resources using attributes defined in the RD Function Set and for use with the CoRE Link Format. The result of a lookup request is the list of links (if any) corresponding to the type of lookup. Thus, a domain lookup MUST return a list of domains, a group lookup MUST return a list of groups, an endpoint lookup MUST return a list of Shelby, et al. Expires January 8, 2017 [Page 27] =0C Internet-Draft CoRE Resource Directory July 2016 endpoints and a resource lookup MUST return a list of links to resources. Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. The target of these links SHOULD be the actual location of the domain, endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. The domain lookup returns every lookup domain with a "/rd" value encapsulated within angle brackets. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a "/rd-group" value encapsulated within angle brackets. Otherwise, the group lookup returns the multicast address of the group inside angle brackets. Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default) or its alternate content-formats ("application/link-format+json" or "application/link-format+cbor"). The page and count parameters are used to obtain lookup results in specified increments using pagination, where count specifies how many links to return and page specifies which subset of links organized in sequential pages , each containing 'count' links, starting with link zero and page zero. Thus, specifying count of 10 and page of 0 will return the first 10 links in the result set (links 0-9). Count =3D = 10 and page =3D 1 will return th enext 'page' containing links 10-19, = and so on. Multiple query parameters MAY be included in a lookup, all included parameters MUST match for a resource to be returned. The character'*' MAY be included at the end of a parameter value as a wildcard operator. The rd-lookup interface MAY use any set of query parameters to match the registered attributes and relations. In addition, this interface MAY be used with queries that specify domains, endpoints, and groups. For example, a domain lookup filtering on groups would return a list of domains that contain the specified groups. An endpoint lookup filtering on groups would return a list of endpoints that are in the specified groups. The lookup interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 28] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: Client -> RD Method: GET URI Template: /{+rd-lookup-base}/{lookup- type}{?d,ep,gp,et,rt,page,count,resource-param} URI Template Variables: rd-lookup-base :=3D RD Lookup Function Set path (mandatory). = This is the path of the RD Lookup Function Set. An RD SHOULD use the value "rd-lookup" for this variable whenever possible. lookup-type :=3D ("d", "ep", "res", "gp") (mandatory) This = variable is used to select the kind of lookup to perform (domain, endpoint, resource, or group). ep :=3D Endpoint name (optional). Used for endpoint, group and resource lookups. d :=3D Domain (optional). Used for domain, group, endpoint and resource lookups. res :=3D resource (optional). Used for domain, group, endpoint = and resource lookups. gp :=3D Group name (optional). Used for endpoint, group and resource lookups. page :=3D Page (optional). Parameter can not be used without the count parameter. Results are returned from result set in pages that contain 'count' links starting from index (page * count). Page numbering starts with zero. count :=3D Count (optional). Number of results is limited to = this parameter value. If the page parameter is also present, the response MUST only include 'count' links starting with the (page * count) link in the result set from the query. If the count parameter is not present, then the response MUST return all matching links in the result set. Link numbering starts with zero. rt :=3D Resource type (optional). Used for group, endpoint and resource lookups. et :=3D Endpoint type (optional). Used for group, endpoint and resource lookups. Shelby, et al. Expires January 8, 2017 [Page 29] =0C Internet-Draft CoRE Resource Directory July 2016 resource-param :=3D Link attribute parameters (optional). Any = link attribute as defined in Section 4.1 of [RFC6690], used for resource lookups. Content-Format: application/link-format (optional) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" with an "application/link- format", "application/link-format+cbor", or "application/link- format+json" payload containing matching entries for the lookup. Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching entry is found for a unicast request. Failure: No error response to a multicast request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The examples in this section assume a CoAP host with IP address FDFD::123 and a default CoAP port 61616. HTTP hosts are possible and do not change the nature of the examples.\ The following example shows a client performing a resource lookup: Req: GET /rd-lookup/res?rt=3Dtemperature Res: 2.05 Content ;rt=3D"temperature" The following example shows a client performing an endpoint type lookup: Req: GET /rd-lookup/ep?et=3Dpower-node Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" Shelby, et al. Expires January 8, 2017 [Page 30] =0C Internet-Draft CoRE Resource Directory July 2016 The following example shows a client performing a domain lookup: Req: GET /rd-lookup/d Res: 2.05 Content <>;d=3D"domain1", <>;d=3D"domain2" The following example shows a client performing a group lookup for all groups: Req: GET /rd-lookup/gp Res: 2.05 Content <>;gp=3D"lights1";d=3D"example.com" <>;gp=3D"lights2";d=3D"ecample.com" The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rd-lookup/ep?gp=3Dlights1 Res: 2.05 Content ;ep=3D"node1", ;ep=3D"node2" The following example shows a client performing a lookup for all groups an endpoint belongs to: Req: GET /rd-lookup/gp?ep=3Dnode1 Res: 2.05 Content <>;gp=3D"lights1" The following example shows a client performing a paginated lookup Shelby, et al. Expires January 8, 2017 [Page 31] =0C Internet-Draft CoRE Resource Directory July 2016 Req: GET /rd-lookup/res?page=3D0&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 Req: GET /rd-lookup/res?page=3D1&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 9. New Link-Format Attributes When using the CoRE Link Format to describe resources being discovered by or posted to a resource directory service, additional information about those resources is useful. This specification defines the following new attributes for use in the CoRE Link Format [RFC6690]: link-extension =3D ( "ins" "=3D" quoted-string ) ; Max 63 bytes link-extension =3D ( "exp" ) 9.1. Resource Instance attribute 'ins' The Resource Instance "ins" attribute is an identifier for this resource, which makes it possible to distinguish it from other similar resources. This attribute is similar in use to the portion of a DNS-SD record (see Section 10.1, and SHOULD be unique across resources with the same Resource Type attribute in the domain it is used. A Resource Instance might be a descriptive string like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID or iNumber. This attribute is used by a Resource Directory to distinguish between multiple instances of the same resource type within the directory. This attribute MUST be no more than 63 bytes in length. The resource identifier attribute MUST NOT appear more than once in a link description. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. Shelby, et al. Expires January 8, 2017 [Page 32] =0C Internet-Draft CoRE Resource Directory July 2016 9.2. Export attribute 'exp' The Export "exp" attribute is used as a flag to indicate that a link description MAY be exported by a resource directory to external directories. The CoRE Link Format is used for many purposes between CoAP endpoints. Some are useful mainly locally, for example checking the observability of a resource before accessing it, determining the size of a resource, or traversing dynamic resource structures. However, other links are very useful to be exported to other directories, for example the entry point resource to a functional service. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 10. DNS-SD Mapping CoRE Resource Discovery is intended to support fine-grained discovery of hosted resources, their attributes, and possibly other resource relations [RFC6690]. In contrast, service discovery generally refers to a coarse-grained resolution of an endpoint's IP address, port number, and protocol. Resource and service discovery are complementary in the case of large networks, where the latter can facilitate scaling. This document defines a mapping between CoRE Link Format attributes and DNS-Based Service Discovery [RFC6763] fields that permits discovery of CoAP services by either method. 10.1. DNS-based Service discovery DNS-Based Service Discovery (DNS-SD) defines a conventional method of configuring DNS PTR, SRV, and TXT resource records to facilitate discovery of services (such as CoAP servers in a subdomain) using the existing DNS infrastructure. This section gives a brief overview of DNS-SD; see [RFC6763] for a detailed specification. DNS-SD service names are limited to 255 octets and are of the form: Service Name =3D ... The service name is the label of SRV/TXT resource records. The SRV RR specifies the host and the port of the endpoint. The TXT RR provides additional information in the form of key/value pairs. The part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify servers or groups of servers. Shelby, et al. Expires January 8, 2017 [Page 33] =0C Internet-Draft CoRE Resource Directory July 2016 The part is composed of at least two labels. The first label of the pair is the application protocol name [RFC6335] preceded by an underscore character. The second label indicates the transport and is always "_udp" for UDP-based CoAP services. In cases where narrowing the scope of the search may be useful, these labels may be optionally preceded by a subtype name followed by the "_sub" label. An example of this more specific is "light._sub._dali._udp". A default part of the service name may be set at the factory or during the commissioning process. It SHOULD uniquely identify an instance of within a . Taken together, these three elements comprise a unique name for an SRV/ TXT record pair within the DNS subdomain. The granularity of a service name MAY be that of a host or group, or it could represent a particular resource within a CoAP server. The SRV record contains the host name (AAAA record name) and port of the service while protocol is part of the service name. In the case where a service name identifies a particular resource, the path part of the URI must be carried in a corresponding TXT record. A DNS TXT record is in practice limited to a few hundred octets in length, which is indicated in the resource record header in the DNS response message. The data consists of one or more strings comprising a key=3Dvalue pair. By convention, the first pair is txtver=3D (to support different versions of a service description). 10.2. mapping ins to The Resource Instance "ins" attribute maps to the part of a DNS-SD service name. It is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. However, to the extent that the "ins" attribute may be chosen to match the DNS host name of a service, it SHOULD use the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. The part of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can allow the device or service to be accessed in many cases without any manual configuration at all. The default name should be short and descriptive, and MAY include a collision-resistant substring such as the lower bits of the device's MAC address, serial number, Shelby, et al. Expires January 8, 2017 [Page 34] =0C Internet-Draft CoRE Resource Directory July 2016 fingerprint, or other identifier in an attempt to make the name relatively unique. DNS labels are currently limited to 63 octets in length and the entire service name may not exceed 255 octets. 10.3. Mapping rt to The resource type "rt" attribute is mapped into the part of a DNS-SD service name and SHOULD conform to the reg-rel-type production of the Link Format defined in Section 2 of [RFC6690]. The "rt" attribute MUST be composed of at least a single Net-Unicode text string, without underscore '_' or period '.' and limited to 15 octets in length, which represents the application protocol name. This string is mapped to the DNS-SD by prepending an underscore and appending a period followed by the "_udp" label. For example, rt=3D"dali" is mapped into "_dali._udp". The application protocol name may be optionally followed by a period and a service subtype name consisting of a Net-Unicode text string, without underscore or period and limited to 63 octets. This string is mapped to the DNS-SD by appending a period followed by the "_sub" label and then appending a period followed by the service type label pair derived as in the previous paragraph. For example, rt=3D"dali.light" is mapped into "light._sub._dali._udp". The resulting string is used to form labels for DNS-SD records which are stored directly in the DNS. 10.4. Domain mapping DNS domains may be derived from the "d" attribute. The domain attribute may be suffixed with the zone name of the authoritative DNS server to generate the domain name. The "ep" attribute is prefixed to the domain name to generate the FQDN to be stored into DNS with an AAAA RR. 10.5. TXT Record key=3Dvalue strings A number of [RFC6763] key/value pairs are derived from link-format information, to be exported in the DNS-SD as key=3Dvalue strings in a TXT record ([RFC6763], Section 6.3). The resource is exported as key/value pair "path=3D". The Interface Description "if" attribute is exported as key/value pair "if=3D". Shelby, et al. Expires January 8, 2017 [Page 35] =0C Internet-Draft CoRE Resource Directory July 2016 The DNS TXT record can be further populated by importing any other resource description attributes as they share the same key=3Dvalue format specified in Section 6 of [RFC6763]. 10.6. Importing resource links into DNS-SD Assuming the ability to query a Resource Directory or multicast a GET (?exp) over the local link, CoAP resource discovery may be used to populate the DNS-SD database in an automated fashion. CoAP resource descriptions (links) can be exported to DNS-SD for exposure to service discovery by using the Resource Instance attribute as the basis for a unique service name, composed with the Resource Type as the , and registered in the correct . The agent responsible for exporting records to the DNS zone file SHOULD be authenticated to the DNS server. The following example shows an agent discovering a resource to be exported: Req: GET /rd-lookup/res?exp Res: 2.05 Content ; exp;rt=3D"dali.light";ins=3D"Spot"; d=3D"office";ep=3D"node1" The agent subsequently registers the following DNS-SD RRs, assuming a zone name "example.com" prefixed with "office": node1.office.example.com. IN AAAA FDFD::1234 _dali._udp.office.example.com IN PTR Spot._dali._udp.office.example.com light._sub._dali._udp.example.com IN PTR Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com IN SRV 0 0 5683 node1.office.example.com. Spot._dali._udp.office.example.com IN TXT txtver=3D1;path=3D/light/1 In the above figure the Service Name is chosen as Spot._dali._udp.office.example.com without the light._sub service prefix. An alternative Service Name would be: Spot.light._sub._dali._udp.office.example.com. 11. Security Considerations The security considerations as described in Section 7 of [RFC5988] and Section 6 of [RFC6690] apply. The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as Shelby, et al. Expires January 8, 2017 [Page 36] =0C Internet-Draft CoRE Resource Directory July 2016 described in [RFC7252]. DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. 11.1. Endpoint Identification and Authentication An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. 11.2. Access Control Access control SHOULD be performed separately for the RD Function Set and the RD Lookup Function Set, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. 11.3. Denial of Service Attacks Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than Shelby, et al. Expires January 8, 2017 [Page 37] =0C Internet-Draft CoRE Resource Directory July 2016 requests, RDs can unknowingly become part of a DDoS amplification attack. Therefore, it is RECOMMENDED that implementations ensure return routability. This can be done, for example by responding to wild card lookups only over DTLS or TLS or TCP. 12. IANA Considerations 12.1. Resource Types "core.rd", "core.rd-group" and "core.rd-lookup" resource types need to be registered with the resource type registry defined by [RFC6690]. 12.2. Link Extension The "exp" and "ins" attributes need to be registered when a future Web Linking link-extension registry is created (e.g. in RFC5988bis). 12.3. IPv6 ND Resource Directory Address Option This document registers one new ND option type under the subregistry "IPv6 Neighbor Discovery Option Formats": o Resource Directory address Option (38) 12.4. RD Parameter Registry This specification defines a new sub-registry for registration and lookup parameters called "RD Parameters" under "CoRE Parameters". Although this specification defines a basic set of parameters, it is expected that other standards that make use of this interface will define new ones. Each entry in the registry must include the human readable name of the parameter, the query parameter, validity requirements if any and a description. The query parameter MUST be a valid URI query key [RFC3986]. Initial entries in this sub-registry are as follows: Shelby, et al. Expires January 8, 2017 [Page 38] =0C Internet-Draft CoRE Resource Directory July 2016 +-----------+-------+---------------+-------------------------------+ | Name | Query | Validity | Description | +-----------+-------+---------------+-------------------------------+ | Endpoint | ep | | Name of the endpoint, max 63 | | Name | | | bytes | | Lifetime | lt | 60-4294967295 | Lifetime of the registration | | | | | in seconds | | Domain | d | | Domain to which this endpoint | | | | | belongs | | Endpoint | et | | Semantic name of the endpoint | | Type | | | | | Context | con | URI | The scheme, address and port | | | | | at which this server is | | | | | available | | Resource | res | | Name of the resource | | Name | | | | | Group | gp | | Name of a group in the RD | | Name | | | | | Page | page | Integer | Used for pagination | | Count | count | Integer | Used for pagination | | Resource | ins | | Instance Identifier | | Instance | | | | | Export | exp | | A link MAY be exported to | | | | | another Resource Directory | +-----------+-------+---------------+-------------------------------+ Table 1: RD Parameters The IANA policy for future additions to the sub-registry is "Expert Review" as described in [RFC5226]. 13. Examples Examples are added here. 13.1. Lighting Installation This example shows a simplified lighting installation which makes use of the Resource Directory (RD) with a CoAP interface to facilitate the installation and start up of the application code in the lights and sensors. In particular, the example leads to the definition of a group and the enabling of the corresponding multicast address. No conclusions must be drawn on the realization of actual installation or naming procedures, because the example only "emphasizes" some of the issues that may influence the use of the RD and does not pretend to be normative. Shelby, et al. Expires January 8, 2017 [Page 39] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.1. Installation Characteristics The example assumes that the installation is managed. That means that a Commissioning Tool (CT) is used to authorize the addition of nodes, name them, and name their services. The CT can be connected to the installation in many ways: the CT can be part of the installation network, connected by WiFi to the installation network, or connected via GPRS link, or other method. It is assumed that there are two naming authorities for the installation: (1) the network manager that is responsible for the correct operation of the network and the connected interfaces, and (2) the lighting manager that is responsible for the correct functioning of networked lights and sensors. The result is the existence of two naming schemes coming from the two managing entities. The example installation consists of one presence sensor, and two luminaries, luminary1 and luminary2, each with their own wireless interface. Each luminary contains three lamps: left, right and middle. Each luminary is accessible through one endpoint. For each lamp a resource exists to modify the settings of a lamp in a luminary. The purpose of the installation is that the presence sensor notifies the presence of persons to a group of lamps. The group of lamps consists of: middle and left lamps of luminary1 and right lamp of luminary2. Before commissioning by the lighting manager, the network is installed and access to the interfaces is proven to work by the network manager. At the moment of installation, the network under installation is not necessarily connected to the DNS infra structure. Therefore, SLAAC IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in Table 2 below: +--------------------+--------------+ | Name | IPv6 address | +--------------------+--------------+ | luminary1 | FDFD::ABCD:1 | | luminary2 | FDFD::ABCD:2 | | Presence sensor | FDFD::ABCD:3 | | Resource directory | FDFD::ABCD:0 | +--------------------+--------------+ Table 2: interface SLAAC addresses Shelby, et al. Expires January 8, 2017 [Page 40] =0C Internet-Draft CoRE Resource Directory July 2016 In Section 13.1.2 the use of resource directory during installation is presented. In Section 13.1.3 the connection to DNS is discussed. 13.1.2. RD entries It is assumed that access to the DNS infrastructure is not always possible during installation. Therefore, the SLAAC addresses are used in this section. For discovery, the resource types (rt) of the devices are important. The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor. The endpoints have names which are relevant to the light installation manager. In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door. The endpoint names reflect this physical location. The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively. The identifiers relevant to the Resource Directory are shown in Table 3 below: +----------------+------------------+---------------+---------------+ | Name | endpoint | resource path | resource type | +----------------+------------------+---------------+---------------+ | luminary1 | lm_R2-4-015_wndw | /light/left | light | | luminary1 | lm_R2-4-015_wndw | /light/middle | light | | luminary1 | lm_R2-4-015_wndw | /light/right | light | | luminary2 | lm_R2-4-015_door | /light/left | light | | luminary2 | lm_R2-4-015_door | /light/middle | light | | luminary2 | lm_R2-4-015_door | /light/right | light | | Presence | ps_R2-4-015_door | /ps | p-sensor | | sensor | | | | +----------------+------------------+---------------+---------------+ Table 3: Resource Directory identifiers The CT inserts the endpoints of the luminaries and the sensor in the RD using the Context parameter (con) to specify the interface address: Shelby, et al. Expires January 8, 2017 [Page 41] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_wndw&con=3Dcoap://[FDFD::ABCD:1] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light";d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4521 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:2] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4522 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dps_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:3] Payload: ;rt=3D"p-sensor"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4523 The domain name d=3D"R2-4-015" has been added for an efficient lookup because filtering on "ep" name is more awkward. The same domain name is communicated to the two luminaries and the presence sensor by the CT. The group is specified in the RD. The Context parameter is set to the site-local multicast address allocated to the group. In the POST in the example below, these two endpoints and the endpoint of the presence sensor are registered as members of the group. Req: POST coap://[FDFD::ABCD:0]/rd-group ?gp=3Dgrp_R2-4-015;con=3D"coap//[FF05::1]";exp;ins=3D"grp1234" Payload: <>ep=3Dlm_R2-4-015_wndw, <>ep=3Dlm_R2-4-015_door, <>ep=3Dps_R2-4-015_door Res: 2.01 Created Location: /rd-group/501 Shelby, et al. Expires January 8, 2017 [Page 42] =0C Internet-Draft CoRE Resource Directory July 2016 After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. The luminary, knowing its domain, queries the RD for the endpoint with rt=3Dlight and d=3DR2-4-015. The RD returns all endpoints in = the domain. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep ?d=3DR2-4-015;rt=3Dlight Res: 2.05 Content ; ep=3D"lm_R2-4-015_wndw", ; ep=3D"lm_R2-4-015_door" Knowing its own IPv6 address, the luminary discovers its endpoint name. With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp ?ep=3Dlm_R2-4-015_wndw Res: 2.05 Content ;gp=3D"grp_R2-4-015" =46rom the context parameter value, the luminary learns the multicast address of the multicast group. Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in [RFC7390]. Req: POST //[FDFD::ABCD:1]/coap-group Content-Format: application/coap-group+json { "a": "[FF05::1]", "n": "grp_R2-4-015"} Res: 2.01 Created Location-Path: /coap-group/1 Dependent on the situation only the address ,"a", or the name, "n", is specified in the coap-group resource. Shelby, et al. Expires January 8, 2017 [Page 43] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.3. DNS entries It may be profitable to discover the light groups for applications, which are unaware ot the existence of the RD. An agent needs to query the RD to return all groups which are exported to be inserted into DNS. Req: GET /rd-lookup/gp?exp Res: 2.05 Content ;exp;gp=3D"grp_R2-4-015;ins=3D"grp1234"; ep=3D"lm_R2-4-015_wndw"; ep=3D"lm_R2-4-015_door The group with FQDN grp_R2-4-015.bc.example.com can be entered into the DNS by the agent. The accompanying instance name is grp1234. The is chosen to be _group._udp. The agent enters the following RRs into the DNS. grp_R2-4-015.bc.example.com. IN AAAA FF05::1 _group._udp.bc.example.com IN PTR grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com IN SRV 0 0 5683 grp_R2-4-015_door.bc.example.com. grp1234._group._udp.bc.example.com IN TXT txtver=3D1;path=3D/light/grp1 =46rom then on applications, not familiar with the existence of the = RD, can use DNS to access the lighting group. 13.2. OMA Lightweight M2M (LWM2M) Example This example shows how the OMA LWM2M specification makes use of Resource Directory (RD). OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority). LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing a Resource Directory along with other LWM2M interfaces defined by the LWM2M specification. CoRE Resource Directory (RD) is used to provide the LWM2M Registration interface. Shelby, et al. Expires January 8, 2017 [Page 44] =0C Internet-Draft CoRE Resource Directory July 2016 LWM2M does not provide for registration domains and does not currently use the rd-group or rd-lookup interfaces. The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server. Other interfaces, proxies, applications, and function sets are currently out of scope for LWM2M. The location of the LWM2M Server and RD Function Set is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD function set is used. LWM2M Servers and endpoints are not required to implement the ./well-known/core resource. 13.2.1. The LWM2M Object Model The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. An LWM2M Object is a resource template and container type that encapsulates a set of related resources. An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings. base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined". As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". [_TEMPLATE_TODO] Shelby, et al. Expires January 8, 2017 [Page 45] =0C Internet-Draft CoRE Resource Directory July 2016 base-uri :=3D Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id :=3D OMNA (OMA Name Authority) registered object ID = (0-65535) object-instance :=3D Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id :=3D OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance :=3D Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings. For example, a LWM2M URI might be: /1/0/1 The base uri is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined". This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 13.2.2. LWM2M Register Endpoint LWM2M defines a registration interface based on the Resource Directory Function Set, described in Section 6. The URI of the LWM2M Resource Directory function set is specified to be "/rd" as recommended in Section 6.3. LWM2M endpoints register object IDs, for example , to indicate that a particular object type is supported, and register object instances, for example , to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format. Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. Shelby, et al. Expires January 8, 2017 [Page 46] =0C Internet-Draft CoRE Resource Directory July 2016 When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in Table 1 : ep - Endpoint Name lt - registration lifetime Endpoint Name is mandatory, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 4: LWM2M Additional Registration Parameters The following RD registration parameters are not currently specified for use in LWM2M: et - Endpoint Type con - Context The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: ,,, This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. Shelby, et al. Expires January 8, 2017 [Page 47] =0C Internet-Draft CoRE Resource Directory July 2016 13.2.3. Alternate Base URI If the LWM2M endpoint exposes objects at a base URI other than the default empty base path, the endpoint must register the base URI using rt=3D"oma.lwm2m". An example link payload using alternate base URI would be: ;rt=3D"oma.lwm2m",,, This link payload indicates that the lwm2m objects will be placed under the base URI "/my_lwm2m" and that object ID 1 (server) is supported, with a single instance 0 existing, and object 5 (firmware update) is supported. 13.2.4. LWM2M Update Endpoint Registration An LWM2M Registration update proceeds as described in Section 6.4, and adds some optional parameter updates: lt - Registration Lifetime b - Protocol Binding sms - MSISDN link payload - new or modified links A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. 13.2.5. LWM2M De-Register Endpoint LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation. LWM2M de- registration proceeds as described in Section 6.5. 14. Acknowledgments Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided helpful comments, discussions and ideas to improve and shape this document. Section 9 is based on an earlier draft by Kerry Lynn. Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. Shelby, et al. Expires January 8, 2017 [Page 48] =0C Internet-Draft CoRE Resource Directory July 2016 15. Changelog changes from -07 to -08 o removed link target value returned from domain and group lookup types o Maximum length of domain parameter 63 bytes for consistency with group o removed option for simple POST of link data, don't require a .well-known/core resource to accept POST data and handle it in a special way; we already have /rd for that o add IPv6 ND Option for discovery of an RD o clarify group configuration section 6.1 that endpoints must be registered before including them in a group o removed all superfluous client-server diagrams o simplified lighting example o introduced Commissioning Tool o RD-Look-up text is extended. changes from -06 to -07 o added text in the discovery section to allow content format hints to be exposed in the discovery link attributes o editorial updates to section 9 o update author information o minor text corrections Changes from -05 to -06 o added note that the PATCH section is contingent on the progress of the PATCH method changes from -04 to -05 o added Update Endpoint Links using PATCH o http access made explicit in interface specification Shelby, et al. Expires January 8, 2017 [Page 49] =0C Internet-Draft CoRE Resource Directory July 2016 o Added http examples Changes from -03 to -04: o Added http response codes o Clarified endpoint name usage o Add application/link-format+cbor content-format Changes from -02 to -03: o Added an example for lighting and DNS integration o Added an example for RD use in OMA LWM2M o Added Read Links operation for link inspection by endpoints o Expanded DNS-SD section o Added draft authors Peter van der Stok and Michael Koster Changes from -01 to -02: o Added a catalogue use case. o Changed the registration update to a POST with optional link format payload. Removed the endpoint type update from the update. o Additional examples section added for more complex use cases. o New DNS-SD mapping section. o Added text on endpoint identification and authentication. o Error code 4.04 added to Registration Update and Delete requests. o Made 63 bytes a SHOULD rather than a MUST for endpoint name and resource type parameters. Changes from -00 to -01: o Removed the ETag validation feature. o Place holder for the DNS-SD mapping section. o Explicitly disabled GET or POST on returned Location. Shelby, et al. Expires January 8, 2017 [Page 50] =0C Internet-Draft CoRE Resource Directory July 2016 o New registry for RD parameters. o Added support for the JSON Link Format. o Added reference to the Groupcomm WG draft. Changes from -05 to WG Document -00: o Updated the version and date. Changes from -04 to -05: o Restricted Update to parameter updates. o Added pagination support for the Lookup interface. o Minor editing, bug fixes and reference updates. o Added group support. o Changed rt to et for the registration and update interface. Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten. o Editorial improvements. o Fixed the use of ETags. o Fixed tickets 383 and 372 Changes from -02 to -03: o Changed the endpoint name back to a single registration parameter ep=3D and removed the h=3D and ins=3D parameters. o Updated REST interface descriptions to use RFC6570 URI Template format. o Introduced an improved RD Lookup design as its own function set. o Improved the security considerations section. o Made the POST registration interface idempotent by requiring the ep=3D parameter to be present. Shelby, et al. Expires January 8, 2017 [Page 51] =0C Internet-Draft CoRE Resource Directory July 2016 Changes from -01 to -02: o Added a terminology section. o Changed the inclusion of an ETag in registration or update to a MAY. o Added the concept of an RD Domain and a registration parameter for it. o Recommended the Location returned from a registration to be stable, allowing for endpoint and Domain information to be changed during updates. o Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 16. References 16.1. Normative References [I-D.ietf-core-links-json] Li, K., Rahman, A., and D. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-05 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . Shelby, et al. Expires January 8, 2017 [Page 52] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . 16.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Shelby, et al. Expires January 8, 2017 [Page 53] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . Editorial Comments [_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert. Authors' Addresses Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Michael Koster SmartThings 665 Clyde Avenue Mountain View 94043 USA Phone: +1-707-502-5136 Email: Michael.Koster@smartthings.com Shelby, et al. Expires January 8, 2017 [Page 54] =0C Internet-Draft CoRE Resource Directory July 2016 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Shelby, et al. Expires January 8, 2017 [Page 55] --Apple-Mail=_CFC45CA3-A912-4DE2-AE6C-D5F652FE53A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On = Jul 8, 2016, at 8:22 AM, Michael Koster <michael.koster@smartthings.com> wrote:

I have = addressed everything except these 2 comments:

On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:

6.6.  Read Endpoint Links
Is there any functionality that is not provided = through the lookup interface (apart from a quicker ep = selection)?

As part of the RD = evolution, a GET on the handle resource should primarily return the = forms to update and delete the registration. Forms that are pre-filled = with the endpoint information could enable a nice collection-based = lookup for management.

What would be the content-format used to = transmit the forms? I would expect GET on a collection with the content = format of the resource to return a representation of the resource = content, in this case the links in the collection. How should we = indicate the hypermedia controls of the resource? I think we need to = give this a little more thought, how to expose the controls of a = resource vs. the content. 

In the meantime, the lookup interface = could be used for inspection but the idea of having read and patch = update as operations on the links of one endpoint seems useful for doing = read-modify-write workflow on links. It's useful to use the same URI for = the resource instead of having to construct a different address to read = vs update.  Also I think discovery (lookup), modifying links, and = registration refresh are logically separate workflows in the client.
6.7.  Update Endpoint Links
Shouldn't this be merged with Section 6.4. = Registration Update?

See = above reason based on separate workflows. Does it make sense?

Best regards,

Michael

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

= --Apple-Mail=_CFC45CA3-A912-4DE2-AE6C-D5F652FE53A4-- --Apple-Mail=_287A5426-06E0-47A7-8847-333F88238132-- From nobody Fri Jul 8 09:26:52 2016 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 3877612D555 for ; Fri, 8 Jul 2016 09:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 LEZCD4amD4rj for ; Fri, 8 Jul 2016 09:26:44 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0A212B05F for ; Fri, 8 Jul 2016 09:26:42 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id hu1so1245948pad.3 for ; Fri, 08 Jul 2016 09:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=PSYHtzpSWkFdd4NUYs82hM/IrQfLUM635qT6xxZ5QGQ=; b=If1r+BIempd+50CzpPPtuusIBsiKor2Ambi9WKrziX73sjop8sEPppVA7V5tLMXwo/ nTLSAqlYG5fDO9LfNUScwZu7nkdfCYMAFV8Avs9g3aZMtD8KaH916nb2ul3NzGdBKxFy 4N0L8vIWCPyG774PPvvLAhRxtJdgb9LKrNQrkJv82zCHQ+Jq7etJ8JVWUZO3axiczzxf meJzBBKigK6kwUbxsLgRCY2moNKYjEU58k4pZfowOWcibpZ3JChlyN1yPHj6yhGXxWWY Cax2GWZJUb2jqF87WZo+Db4HBTYk8OhCqbeiDE581XM7JMZ2W93B+2w0ev+pbg1HhFyu Se/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PSYHtzpSWkFdd4NUYs82hM/IrQfLUM635qT6xxZ5QGQ=; b=OC15aBgPNHMSXwY9CXm3x9AmwrS5okeN/eTgMh+ZwbXSkqGHPh//YJ0jMxJDBI+eIi QHQnwZKMAKfIaDNpwuEp5iHFMq2OX3RVk4qIH5/0O7ZF3O0ZyV+E9sJZv5lUs5XJAG6Y NZQik/h/x40vvbgS/Jkse7raQ4JfJy0rxP4MaTZpAgELIXihzm5hhmD88bNyzbJERaKC qRixYobDUdRyc3/B5ME3Kk85qPC+65HjiLz1kr8Pxx2Bbryoacj1LpSSMfethixRDtyV 8bbWeliv3/JZdQLe0R+Uf4dkpM5iuJWq0NK+7b6SrDKiB617qCuo7zG/ChiRtfJTiIdj cwBQ== X-Gm-Message-State: ALyK8tITVGnHy3pT3VqqnfCMuZVq+er7aj7JOCkGaIBn7znEdLsrCyNyrB3oj9trrZfZPR+E X-Received: by 10.66.11.72 with SMTP id o8mr11359792pab.106.1467995202438; Fri, 08 Jul 2016 09:26:42 -0700 (PDT) Received: from [172.16.2.46] (23-24-193-1-static.hfc.comcastbusiness.net. [23.24.193.1]) by smtp.gmail.com with ESMTPSA id um7sm6214628pab.20.2016.07.08.09.26.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 09:26:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_78C519D9-8C19-4636-A025-0646AB2985C1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Fri, 8 Jul 2016 09:26:34 -0700 Message-Id: References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <55877B3AFB359744BA0F2140E36F52B551DB4D46@MBX110.d.ethz.ch> <36EADFEA-0B01-436A-95FD-592ECC408127@smartthings.com> To: Michael Koster X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Hannes Tschofenig , "draft-ietf-core-resource-directory@tools.ietf.org" , Oscar Novo , "core@ietf.org" Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 16:26:50 -0000 --Apple-Mail=_78C519D9-8C19-4636-A025-0646AB2985C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Candidate to submit. > On Jul 8, 2016, at 8:32 AM, Michael Koster = wrote: >=20 > couple more nits >=20 > >=20 >> On Jul 8, 2016, at 8:22 AM, Michael Koster = > = wrote: >>=20 >> I have addressed everything except these 2 comments: >>=20 >>> On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias > wrote: >>>=20 >>> 6.6. Read Endpoint Links >>> Is there any functionality that is not provided through the lookup = interface (apart from a quicker ep selection)? >>>=20 >>> As part of the RD evolution, a GET on the handle resource should = primarily return the forms to update and delete the registration. Forms = that are pre-filled with the endpoint information could enable a nice = collection-based lookup for management. >>>=20 >> What would be the content-format used to transmit the forms? I would = expect GET on a collection with the content format of the resource to = return a representation of the resource content, in this case the links = in the collection. How should we indicate the hypermedia controls of the = resource? I think we need to give this a little more thought, how to = expose the controls of a resource vs. the content.=20 >>=20 >> In the meantime, the lookup interface could be used for inspection = but the idea of having read and patch update as operations on the links = of one endpoint seems useful for doing read-modify-write workflow on = links. It's useful to use the same URI for the resource instead of = having to construct a different address to read vs update. Also I think = discovery (lookup), modifying links, and registration refresh are = logically separate workflows in the client. >>> 6.7. Update Endpoint Links >>> Shouldn't this be merged with Section 6.4. Registration Update? >>=20 >> See above reason based on separate workflows. Does it make sense? >>=20 >> Best regards, >>=20 >> Michael >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --Apple-Mail=_78C519D9-8C19-4636-A025-0646AB2985C1 Content-Type: multipart/mixed; boundary="Apple-Mail=_A6EF9B6D-F4A7-4715-8132-C8B4663EB59A" --Apple-Mail=_A6EF9B6D-F4A7-4715-8132-C8B4663EB59A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Candidate to submit.

--Apple-Mail=_A6EF9B6D-F4A7-4715-8132-C8B4663EB59A Content-Disposition: attachment; filename=draft-ietf-core-resource-directory-xx.txt Content-Type: text/plain; name="draft-ietf-core-resource-directory-xx.txt" Content-Transfer-Encoding: quoted-printable CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster Expires: January 8, 2017 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant July 07, 2016 CoRE Resource Directory draft-ietf-core-resource-directory-08 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 resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Shelby, et al. Expires January 8, 2017 [Page 1] =0C Internet-Draft CoRE Resource Directory July 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 4. Finding a Directory Server . . . . . . . . . . . . . . . . . 8 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 9 5. Simple Registration . . . . . . . . . . . . . . . . . . . . . 10 5.1. Simple publishing to Resource Directory Server . . . . . 11 5.2. Third-party registration . . . . . . . . . . . . . . . . 12 6. Resource Directory Function Set . . . . . . . . . . . . . . . 12 6.1. Content Formats . . . . . . . . . . . . . . . . . . . . . 13 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Registration . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Registration Update . . . . . . . . . . . . . . . . . . . 18 6.5. Registration Removal . . . . . . . . . . . . . . . . . . 20 6.6. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 21 6.7. Update Endpoint Links . . . . . . . . . . . . . . . . . . 22 7. Group Function Set . . . . . . . . . . . . . . . . . . . . . 24 7.1. Register a Group . . . . . . . . . . . . . . . . . . . . 24 7.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 26 8. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 27 9. New Link-Format Attributes . . . . . . . . . . . . . . . . . 32 9.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 32 9.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 33 10. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. DNS-based Service discovery . . . . . . . . . . . . . . 33 10.2. mapping ins to . . . . . . . . . . . . . . . 34 10.3. Mapping rt to . . . . . . . . . . . . . . 35 10.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 35 Shelby, et al. Expires January 8, 2017 [Page 2] =0C Internet-Draft CoRE Resource Directory July 2016 10.5. TXT Record key=3Dvalue strings . . . . . . . . . . . . . . = 35 10.6. Importing resource links into DNS-SD . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11.1. Endpoint Identification and Authentication . . . . . . . 37 11.2. Access Control . . . . . . . . . . . . . . . . . . . . . 37 11.3. Denial of Service Attacks . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 38 12.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 38 12.3. IPv6 ND Resource Directory Address Option . . . . . . . 38 12.4. RD Parameter Registry . . . . . . . . . . . . . . . . . 38 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. Lighting Installation . . . . . . . . . . . . . . . . . 39 13.1.1. Installation Characteristics . . . . . . . . . . . . 40 13.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 41 13.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 44 13.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 44 13.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 45 13.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 46 13.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 48 13.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 48 13.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 48 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.1. Normative References . . . . . . . . . . . . . . . . . . 52 16.2. Informative References . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Linking [RFC5988]. The use of Web Linking for the description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format [RFC6690]. However, [RFC6690] only describes how to discover resources from the web server that hosts them by requesting "/.well-known/core". In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast Shelby, et al. Expires January 8, 2017 [Page 3] =0C Internet-Draft CoRE Resource Directory July 2016 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 a Resource Directory are defined. Although the examples in this document show the use of these interfaces with CoAP [RFC7252], they can be applied in an equivalent manner to HTTP [RFC7230]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "byte" is used in its now customary sense as a synonym for "octet". This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252]. To describe the REST interfaces defined in this specification, the URI Template format is used [RFC6570]. This specification makes use of the following additional terminology: Resource Directory A web entity that stores information about web resources and implements the REST interfaces defined in this specification for registration and lookup of those resources. Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Group In the context of a Resource Directory, a group is a logical grouping of endpoints for the purpose of group communications. All groups within a domain are unique. Endpoint Shelby, et al. Expires January 8, 2017 [Page 4] =0C Internet-Draft CoRE Resource Directory July 2016 Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. 3. Architecture and Use Cases The resource directory architecture is illustrated in Figure 1. A Resource Directory (RD) is used as a repository for Web Links [RFC5988] about resources hosted on other web servers, which are called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory entries), and for clients to lookup resources from the RD or maintain groups. Endpoints themselves can also act as clients. An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured by an outside entity. This information hierarchy is shown in Figure 2. Endpoints are assumed to proactively register and maintain resource directory entries on the RD, which are soft state and need to be periodically refreshed. An endpoint is provided with interfaces to register, update and remove a resource directory entry. Furthermore, a mechanism to discover an RD using the CoRE Link Format [RFC6690] is defined. It is also possible for an RD to proactively discover Web Links from endpoints and add them as resource directory entries. A lookup interface for discovering any of the Web Links held in the RD is provided using the CoRE Link Format. Shelby, et al. Expires January 8, 2017 [Page 5] =0C Internet-Draft CoRE Resource Directory July 2016 Registration Lookup, Group Interface Interfaces +----+ | | | EP |---- | | +----+ ---- | | --|- +------+ | +----+ | ----| | | +--------+ | EP | ---------|-----| RD |----|-----| Client | +----+ | ----| | | +--------+ --|- +------+ | +----+ ---- | | | EP |---- | | +----+ Figure 1: The resource directory architecture. +------------+ | Domain | <-- Name +------------+ | | | +------------+ | | Group | <-- Name, Scheme, IP, Port | +------------+ | | +------------+ | Endpoint | <-- Name, Scheme, IP, Port +------------+ | | +------------+ | Resource | <-- Target, Parameters +------------+ Figure 2: The resource directory information hierarchy. 3.1. Use Case: Cellular M2M Over the last few years, mobile operators around the world have focused on development of M2M solutions in order to expand the business to the new type of users: machines. The machines are connected directly to a mobile network using an appropriate embedded air interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and wide range wireless interfaces. =46rom the system design point = of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application Shelby, et al. Expires January 8, 2017 [Page 6] =0C Internet-Draft CoRE Resource Directory July 2016 requirements, thus avoiding silo like solutions. One of the crucial enablers of such design is the ability to discover resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities. Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs. The address of each (proxy) endpoint on this server is included in the resource description stored in the RD. The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database. Similarly, fleet management systems provide the appropriate link parameters to the RD to look up for EPs deployed on the vehicles the application is responsible for. 3.2. Use Case: Home and Building Automation Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. The exporting of resource information to other discovery systems is also important in these automation applications. In home automation there is a need to interact with other consumer electronics, which may already support DNS-SD, and in building automation DNS-SD in combination with resource directories can cover multiple buildings. 3.3. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted Shelby, et al. Expires January 8, 2017 [Page 7] =0C Internet-Draft CoRE Resource Directory July 2016 anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use the Resource Directory lookup function set to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in web link compatible representations are supplied by Resource Directories, which may be internally stored as triples, or relation/attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to common web linking formats for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms should generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. This provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. 4. Finding a Directory Server Endpoints that want to contact a directory server can obtain candidate IP addresses for such servers in a number of ways. In a 6LoWPAN, good candidates can be taken from: o specific static configuration (e.g., anycast addresses), if any, o the ABRO option of 6LoWPAN-ND [RFC6775], o other ND options that happen to point to servers (such as RDNSS), o DHCPv6 options that might be defined later. o The IPv6 Neighbor Discovery Resource Directory Address Option described in Section 4.1 Shelby, et al. Expires January 8, 2017 [Page 8] =0C Internet-Draft CoRE Resource Directory July 2016 In networks with more inexpensive use of multicast, the candidate IP address may be a well-known multicast address, i.e. directory servers are found by simply sending GET requests to that well-known multicast address (see Section 6.2). As some of these sources are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate- limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. 4.1. Resource Directory Address Option (RDAO) The Resource Directory Option (RDAO) using IPv6 neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with link-local multicast address because the endpoint and the RD are separated by a border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network. The presence and the use of the RD is essential during commissioning. The RDAO format is: Shelby, et al. Expires January 8, 2017 [Page 9] =0C Internet-Draft CoRE Resource Directory July 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length =3D 3 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RD Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 38 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this set of border router information is valid. A value of all zero bits (0x0) assumes a default value of 10,000 (~one week). Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. RD Address: IPv6 address of the RD. Figure 3: Resource Directory Address Option 5. Simple Registration Not all endpoints hosting resources are expected to know how to implement the Resource Directory Function Set (see Section 6) hence cannot register with a Resource Directory. Instead, simple endpoints can implement the generic Simple Directory Discovery approach described in this section. An RD implementing this specification MUST implement Simple Directory Discovery. However, there may be Shelby, et al. Expires January 8, 2017 [Page 10] =0C Internet-Draft CoRE Resource Directory July 2016 security reasons why this form of directory discovery would be disabled. This approach requires that the endpoint makes available the hosted resources that it wants to be discovered, as links on its "/.well- known/core" interface as specified in [RFC6690]. The endpoint then finds one or more addresses of the directory server as described in Section 4. An endpoint can send (a selection of) hosted resources to a directory server for publication as described in Section 5.1. The directory server integrates the information it received this way into its resource directory. It MAY make the information available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 5.1. Simple publishing to Resource Directory Server An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. The endpoint MAY include registration parameters in the POST request as per Section 6.3 The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. Shelby, et al. Expires January 8, 2017 [Page 11] =0C Internet-Draft CoRE Resource Directory July 2016 Req:(to RD server from [ff02::1]) POST coap://rd.example.com/.well-known/core?lt=3D6000 Content-Format: 40 payload: (empty payload) Res: 2.04 Changed (later) Req: (from RD server to [ff02::1]) GET coap://[ff02::1]/.well-known/core Accept: 40 Res: 2.05 Content payload: 5.2. Third-party registration For some applications, even Simple Directory Discovery may be too taxing for certain very constrained devices, in particular if the security requirements become too onerous. In a controlled environment (e.g. building control), the Resource Directory can be filled by a third device, called a commissioning tool. The commissioning tool can fill the Resource Directory from a database or other means. For that purpose the scheme, IP address and port of the registered device is indicated in the Context parameter of the registration described in Section 6.3. 6. Resource Directory Function Set This section defines the REST interfaces between an RD and endpoints, which is called the Resource Directory Function Set. Although the examples throughout this section assume the use of CoAP [RFC7252], these REST interfaces can also be realized using HTTP [RFC7230]. In all definitions in this section, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces defined in this section. Shelby, et al. Expires January 8, 2017 [Page 12] =0C Internet-Draft CoRE Resource Directory July 2016 Resource directory entries are designed to be easily exported to other discovery mechanisms such as DNS-SD. For that reason, parameters that would meaningfully be mapped to DNS SHOULD be limited to a maximum length of 63 bytes. 6.1. Content Formats Resource Directory implementations using this specification MUST support the application/link-format content format (ct=3D40). Resource Directories implementing this specification MAY support additional content formats. Any additional content format supported by a Resource Directory implementing this specification MUST have an equivalent serialization in the application/link-format content format. 6.2. Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the path of its RD Function Set. There can be several mechanisms for discovering the RD including assuming a default location (e.g. on an Edge Router in a LoWPAN), by assigning an anycast address to the RD, using DHCP, or by discovering the RD using the CoRE Link Format (see also Section 4). This section defines discovery of the RD using the well-known interface of the CoRE Link Format [RFC6690] as the required mechanism. It is however expected that RDs will also be discoverable via other methods depending on the deployment. Discovery of the RD function set is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup" is used to discover the RD Lookup Function Set. Upon success, the response will contain a payload with a link format entry for each RD discovered, with the URL indicating the root resource of the RD. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link attribute, as shown in the example below. Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. Shelby, et al. Expires January 8, 2017 [Page 13] =0C Internet-Draft CoRE Resource Directory July 2016 HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. An RD implementation of this specification MUST support query filtering for the rt parameter as defined in [RFC6690]. The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt :=3D Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : YES (Unicast only) The following example shows an endpoint discovering an RD using this interface, thus learning that the base RD resource is, in this Shelby, et al. Expires January 8, 2017 [Page 14] =0C Internet-Draft CoRE Resource Directory July 2016 example, at /rd and that the content_format delivered by the server hosting the resource is application.xml (ct=3D40). Note that it is = up to the RD to choose its base RD resource, although diagnostics and debugging is facilitated by using the base paths specified here where possible. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup";ct=3D40, ;rt=3D"core.rd-group";ct=3D40 The following example shows the way of indicating that a client may request alternate content-formats. The Content-Format code attribute "ct" MAY include a space-separated sequence of Content-Format codes as specified in [RFC7252], indicating that multiple content-formats are available. The example below shows the required ct=3D40 (application/link-format) indicated as well as a vendor-specific content format (21225). Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 21225", ;rt=3D"core.rd-lookup";ct=3D"40 21225", ;rt=3D"core.rd-group";ct=3D"40 21225" 6.3. Registration After discovering the location of an RD Function Set, an endpoint MAY register its resources using the registration interface. This interface accepts a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link- format+json), or CBOR CoRE Link Format (application/link-format+cbor) [I-D.ietf-core-links-json], along with query string parameters indicating the name of the endpoint, its domain and the lifetime of the registration. All parameters except the endpoint name are optional. It is expected that other specifications will define further parameters (see Section 12.4). The RD then creates a new resource or updates an existing resource in the RD and returns its location. An endpoint MUST use that location when refreshing registrations using this interface. Endpoint resources in the RD are kept active for the period indicated by the lifetime parameter. The endpoint is responsible for refreshing the entry within this period using either the registration or update interface. The registration interface MUST be implemented to be idempotent, so that registering Shelby, et al. Expires January 8, 2017 [Page 15] =0C Internet-Draft CoRE Resource Directory July 2016 twice with the same endpoint parameter does not create multiple RD entries. A new registration may be created at any time to supercede an existing registration, replacing the registration parameters and links. The registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd :=3D RD Function Set path (mandatory). This is the path of = the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10). et :=3D Endpoint Type (optional). The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Shelby, et al. Expires January 8, 2017 [Page 16] =0C Internet-Draft CoRE Resource Directory July 2016 Content-Format: application/link-format+cbor The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new resource entry for the endpoint. This Location MUST be a stable identifier generated by the RD as it is used for all subsequent operations on this registration. The resource returned in the Location is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered links, including updating and deleting links. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. The resulting location /rd/4521 is just an example of an RD generated location. Req: POST coap://rd.example.com/rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 Req: POST /rd?ep=3Dnode1 HTTP/1.1 Host : example.com Content-Type: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 Shelby, et al. Expires January 8, 2017 [Page 17] =0C Internet-Draft CoRE Resource Directory July 2016 6.4. Registration Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the resource returned in the Location option in the response to the first registration. An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 6.3 ) if they have changed since the last registration or update. Parameters that have not changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in {registration}. Upon receiving an update request, an RD MUST reset the timeout for that endpoint and update the scheme, IP address and port of the endpoint, using the source address of the update, or the context ("con") parameter if present. If the lifetime parameter "lt" is included in the received update request, the RD MUST update the lifetime of the registration and set the timeout equal to the new lifetime. An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if both the target URI and relation type match. In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 6.7. The update registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. Shelby, et al. Expires January 8, 2017 [Page 18] =0C Internet-Draft CoRE Resource Directory July 2016 con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. Optional. In the absence of this parameter the scheme of the protocol, source IP address and source port used to register are assumed. This parameter is compulsory when the directory is filled by a third party such as a commissioning tool. Content-Format: application/link-format (mandatory) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint updating its registration at an RD using this interface. Req: POST /rd/4521 Res: 2.04 Changed The following example shows an endpoint updating its registration with a new lifetime and context, changing an existing link, and adding a new link using this interface. With the initial registration the client set the following values: o lifetime (lt)=3D500 o context (con)=3Dcoap://local-proxy-old.example.com:5683 o resource=3D ;ct=3D41;rt=3D"foobar";if=3D"sensor" Shelby, et al. Expires January 8, 2017 [Page 19] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST /rd/4521?lt=3D600&con=3D"coap://local-proxy.example.com:5683"= Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-f";if=3D"sensor", ;ct=3D41;rt=3D"door";if=3D"sensor" Res: 2.04 Changed 6.5. Registration Removal Although RD entries have soft state and will eventually timeout after their lifetime, an endpoint SHOULD explicitly remove its entry from the RD if it knows it will no longer be available (for example on shut-down). This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. The removal request interface is specified as follows: Interaction: EP -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the endpoint from the RD. Shelby, et al. Expires January 8, 2017 [Page 20] =0C Internet-Draft CoRE Resource Directory July 2016 Req: DELETE /rd/4521 Res: 2.02 Deleted 6.6. Read Endpoint Links Some endpoints may wish to manage their links as a collection, and may need to read the current set of links in order to determine link maintenance operations. One or more links MAY be selected by using query filtering as specified in [RFC6690] Section 4.1 The read request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" upon success with an "application/link-format", "application/link-format+cbor", or "application/link-format+json" payload. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires January 8, 2017 [Page 21] =0C Internet-Draft CoRE Resource Directory July 2016 The following examples show successful read of the endpoint links from the RD. Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" 6.7. Update Endpoint Links [This section will be removed before or as a result of a working- group last-call if the PATCH methods do not achieve the same level of consensus as the present document.] A PATCH update adds, removes or changes links for the endpoint by including link update information in the payload of the update as a merge-patch+json format [RFC7396] document. One or more links are selected for update by using query filtering as specified in [RFC6690] Section 4.1 The query filter selects the links to be modified or deleted, by matching the query parameter values to the values of the link attributes. When the query parameters are not present in the request, the payload specifies links to be added to the target document. When the query parameters are present, the attribute names and values in the query parameters select one or more links on which to apply the PATCH operation. If an attribute name specified in the PATCH document exists in any the set of selected links, all occurrences of the attribute value in the target document MUST be updated using the value from the PATCH payload. If the attribute name is not present in any selected links, the attribute MUST be added to the links. The update request interface is specified as follows: Interaction: EP -> RD Method: PATCH URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: Shelby, et al. Expires January 8, 2017 [Page 22] =0C Internet-Draft CoRE Resource Directory July 2016 location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 Content-Format: application/merge-patch+json (mandatory) The following response codes are defined for this interface: Success: 2.04 "Changed" 0r 204 "No Content" in the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration resource does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show an endpoint adding , modifying , and removing links in RD using the Update Endpoint Links function. The following example shows an EP adding the link ;ct=3D41;rt=3D"humid-s";if=3D"sensor" to the collection of = links at the location /rd/4521. Req: PATCH /rd/4521 Payload: [{"href":"/sensors/humid","ct": 41, "rt": "humid-s", "if": "sensor"}] Content-Format: application/merge-patch+json Res: 2.04 Changed The following example shows an EP modifying all links at the location /rd/4521 which are identified by href=3D"/sensors/temp", from the initial link-value of ;rt=3D"temperature" to the new link-value ;rt=3D"temperature-c";if=3D"sensor" by = changing Shelby, et al. Expires January 8, 2017 [Page 23] =0C Internet-Draft CoRE Resource Directory July 2016 the value of the link attribute "rt" and adding the link attribute if=3D"sensor" using the PATCH operation with the supplied merge- patch+json document payload. Req: PATCH /rd/4521?href=3D"/sensors/temp" Payload: {"rt": "temperature-c", "if": "sensor"}, Content-Format: application/merge-patch+json Res: 2.04 Changed This example shows an EP removing all links at the location /rd/4521 which are identified by href=3D"/sensors/light". Req: PATCH /rd/4521?href=3D"/sensors/light" Payload: {null} Content-Format: application/merge-patch+json Res: 2.04 Changed 7. Group Function Set This section defines a function set for the creation of groups of endpoints for the purpose of managing and looking up endpoints for group operations. The group function set is similar to the resource directory function set, in that a group may be created or removed. However unlike an endpoint entry, a group entry consists of a list of endpoints and does not have a lifetime associated with it. In order to make use of multicast requests with CoAP, a group MAY have a multicast address associated with it. 7.1. Register a Group In order to create a group, a commissioning tool (CT) used to configure groups, makes a request to the RD indicating the name of the group to create (or update), optionally the domain the group belongs to, and optionally the multicast address of the group. The registration message includes the list of endpoints that belong to that group. Shelby, et al. Expires January 8, 2017 [Page 24] =0C Internet-Draft CoRE Resource Directory July 2016 All the endpoints in the group MUST be registered with the RD before registering a group. If an endpoint is not yet registered to the RD before registering the group, the registration message returns an error. The RD sends a blank target URI for every endpoint link when registering the group. Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. The registration request interface is specified as follows: Interaction: CT -> RD Method: POST URI Template: /{+rd-group}{?gp,d,con} URI Template Variables: rd-group :=3D RD Group Function Set path (mandatory). This is = the path of the RD Group Function Set. An RD SHOULD use the value "rd-group" for this variable whenever possible. gp :=3D Group Name (mandatory). The name of the group to be created or replaced, unique within that domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this group = belongs. The maximum length of this parameter is 63 bytes. Optional. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. The domain value is needed to export the endpoint to DNS-SD (see Section 10) con :=3D Context (optional). This parameter is used to set the = IP multicast address at which this server is available in the form scheme://multicast-address:port. Optional. In the absence of this parameter no multicast address is configured. This parameter is compulsory when the directory is filled by a commissioning tool. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Shelby, et al. Expires January 8, 2017 [Page 25] =0C Internet-Draft CoRE Resource Directory July 2016 Success: 2.01 "Created" or 201 "Created". The Location header MUST be included with the new group entry. This Location MUST be a stable identifier generated by the RD as it is used for delete operations on this registration. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". An Endpoint is not registered in the RD (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface. The resulting location /rd-group/12 is just an example of an RD generated group location. Req: POST coap://rd.example.com/rd-group?gp=3Dlights Content-Format: 40 Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 2.01 Created Location: /rd-group/12 Req: POST /rd-group?gp=3Dlights HTTP/1.1 Host: example.com Content-Type: application/link-format Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 201 Created Location: /rd-group/12 7.2. Group Removal A group can be removed simply by sending a removal message to the location returned when registering the group. Removing a group MUST NOT remove the endpoints of the group from the RD. The removal request interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 26] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: CT -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful group registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the group from the RD. Req: DELETE /rd-group/12 Res: 2.02 Deleted 8. RD Lookup Function Set In order for an RD to be used for discovering resources registered with it, a lookup interface can be provided using this function set. This lookup interface is defined as a default, and it is assumed that RDs may also support lookups to return resource descriptions in alternative formats (e.g. Atom or HTML Link) or using more advanced interfaces (e.g. supporting context or semantic based lookup). This function set allows lookups for domains, groups, endpoints and resources using attributes defined in the RD Function Set and for use with the CoRE Link Format. The result of a lookup request is the list of links (if any) corresponding to the type of lookup. Thus, a domain lookup MUST return a list of domains, a group lookup MUST return a list of groups, an endpoint lookup MUST return a list of Shelby, et al. Expires January 8, 2017 [Page 27] =0C Internet-Draft CoRE Resource Directory July 2016 endpoints and a resource lookup MUST return a list of links to resources. Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. The target of these links SHOULD be the actual location of the domain, endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. The domain lookup returns every lookup domain with a "/rd" value encapsulated within angle brackets. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a "/rd-group" value encapsulated within angle brackets. Otherwise, the group lookup returns the multicast address of the group inside angle brackets. Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default) or its alternate content-formats ("application/link-format+json" or "application/link-format+cbor"). The page and count parameters are used to obtain lookup results in specified increments using pagination, where count specifies how many links to return and page specifies which subset of links organized in sequential pages , each containing 'count' links, starting with link zero and page zero. Thus, specifying count of 10 and page of 0 will return the first 10 links in the result set (links 0-9). Count =3D = 10 and page =3D 1 will return the next 'page' containing links 10-19, = and so on. Multiple query parameters MAY be included in a lookup, all included parameters MUST match for a resource to be returned. The character'*' MAY be included at the end of a parameter value as a wildcard operator. The rd-lookup interface MAY use any set of query parameters to match the registered attributes and relations. In addition, this interface MAY be used with queries that specify domains, endpoints, and groups. For example, a domain lookup filtering on groups would return a list of domains that contain the specified groups. An endpoint lookup filtering on groups would return a list of endpoints that are in the specified groups. The lookup interface is specified as follows: Shelby, et al. Expires January 8, 2017 [Page 28] =0C Internet-Draft CoRE Resource Directory July 2016 Interaction: Client -> RD Method: GET URI Template: /{+rd-lookup-base}/{lookup- type}{?d,ep,gp,et,rt,page,count,resource-param} URI Template Variables: rd-lookup-base :=3D RD Lookup Function Set path (mandatory). = This is the path of the RD Lookup Function Set. An RD SHOULD use the value "rd-lookup" for this variable whenever possible. lookup-type :=3D ("d", "ep", "res", "gp") (mandatory) This = variable is used to select the kind of lookup to perform (domain, endpoint, resource, or group). ep :=3D Endpoint name (optional). Used for endpoint, group and resource lookups. d :=3D Domain (optional). Used for domain, group, endpoint and resource lookups. res :=3D resource (optional). Used for domain, group, endpoint = and resource lookups. gp :=3D Group name (optional). Used for endpoint, group and resource lookups. page :=3D Page (optional). Parameter can not be used without the count parameter. Results are returned from result set in pages that contain 'count' links starting from index (page * count). Page numbering starts with zero. count :=3D Count (optional). Number of results is limited to = this parameter value. If the page parameter is also present, the response MUST only include 'count' links starting with the (page * count) link in the result set from the query. If the count parameter is not present, then the response MUST return all matching links in the result set. Link numbering starts with zero. rt :=3D Resource type (optional). Used for group, endpoint and resource lookups. et :=3D Endpoint type (optional). Used for group, endpoint and resource lookups. Shelby, et al. Expires January 8, 2017 [Page 29] =0C Internet-Draft CoRE Resource Directory July 2016 resource-param :=3D Link attribute parameters (optional). Any = link attribute as defined in Section 4.1 of [RFC6690], used for resource lookups. Content-Format: application/link-format (optional) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" with an "application/link- format", "application/link-format+cbor", or "application/link- format+json" payload containing matching entries for the lookup. Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching entry is found for a unicast request. Failure: No error response to a multicast request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The examples in this section assume a CoAP host with IP address FDFD::123 and a default CoAP port 61616. HTTP hosts are possible and do not change the nature of the examples.\ The following example shows a client performing a resource lookup: Req: GET /rd-lookup/res?rt=3Dtemperature Res: 2.05 Content ;rt=3D"temperature" The following example shows a client performing an endpoint type lookup: Req: GET /rd-lookup/ep?et=3Dpower-node Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" Shelby, et al. Expires January 8, 2017 [Page 30] =0C Internet-Draft CoRE Resource Directory July 2016 The following example shows a client performing a domain lookup: Req: GET /rd-lookup/d Res: 2.05 Content <>;d=3D"domain1", <>;d=3D"domain2" The following example shows a client performing a group lookup for all groups: Req: GET /rd-lookup/gp Res: 2.05 Content <>;gp=3D"lights1";d=3D"example.com" <>;gp=3D"lights2";d=3D"ecample.com" The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rd-lookup/ep?gp=3Dlights1 Res: 2.05 Content ;ep=3D"node1", ;ep=3D"node2" The following example shows a client performing a lookup for all groups an endpoint belongs to: Req: GET /rd-lookup/gp?ep=3Dnode1 Res: 2.05 Content <>;gp=3D"lights1" The following example shows a client performing a paginated lookup Shelby, et al. Expires January 8, 2017 [Page 31] =0C Internet-Draft CoRE Resource Directory July 2016 Req: GET /rd-lookup/res?page=3D0&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 Req: GET /rd-lookup/res?page=3D1&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 9. New Link-Format Attributes When using the CoRE Link Format to describe resources being discovered by or posted to a resource directory service, additional information about those resources is useful. This specification defines the following new attributes for use in the CoRE Link Format [RFC6690]: link-extension =3D ( "ins" "=3D" quoted-string ) ; Max 63 bytes link-extension =3D ( "exp" ) 9.1. Resource Instance attribute 'ins' The Resource Instance "ins" attribute is an identifier for this resource, which makes it possible to distinguish it from other similar resources. This attribute is similar in use to the portion of a DNS-SD record (see Section 10.1, and SHOULD be unique across resources with the same Resource Type attribute in the domain it is used. A Resource Instance might be a descriptive string like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID or iNumber. This attribute is used by a Resource Directory to distinguish between multiple instances of the same resource type within the directory. This attribute MUST be no more than 63 bytes in length. The resource identifier attribute MUST NOT appear more than once in a link description. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. Shelby, et al. Expires January 8, 2017 [Page 32] =0C Internet-Draft CoRE Resource Directory July 2016 9.2. Export attribute 'exp' The Export "exp" attribute is used as a flag to indicate that a link description MAY be exported by a resource directory to external directories. The CoRE Link Format is used for many purposes between CoAP endpoints. Some are useful mainly locally, for example checking the observability of a resource before accessing it, determining the size of a resource, or traversing dynamic resource structures. However, other links are very useful to be exported to other directories, for example the entry point resource to a functional service. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7. 10. DNS-SD Mapping CoRE Resource Discovery is intended to support fine-grained discovery of hosted resources, their attributes, and possibly other resource relations [RFC6690]. In contrast, service discovery generally refers to a coarse-grained resolution of an endpoint's IP address, port number, and protocol. Resource and service discovery are complementary in the case of large networks, where the latter can facilitate scaling. This document defines a mapping between CoRE Link Format attributes and DNS-Based Service Discovery [RFC6763] fields that permits discovery of CoAP services by either method. 10.1. DNS-based Service discovery DNS-Based Service Discovery (DNS-SD) defines a conventional method of configuring DNS PTR, SRV, and TXT resource records to facilitate discovery of services (such as CoAP servers in a subdomain) using the existing DNS infrastructure. This section gives a brief overview of DNS-SD; see [RFC6763] for a detailed specification. DNS-SD service names are limited to 255 octets and are of the form: Service Name =3D ... The service name is the label of SRV/TXT resource records. The SRV RR specifies the host and the port of the endpoint. The TXT RR provides additional information in the form of key/value pairs. The part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify servers or groups of servers. Shelby, et al. Expires January 8, 2017 [Page 33] =0C Internet-Draft CoRE Resource Directory July 2016 The part is composed of at least two labels. The first label of the pair is the application protocol name [RFC6335] preceded by an underscore character. The second label indicates the transport and is always "_udp" for UDP-based CoAP services. In cases where narrowing the scope of the search may be useful, these labels may be optionally preceded by a subtype name followed by the "_sub" label. An example of this more specific is "light._sub._dali._udp". A default part of the service name may be set at the factory or during the commissioning process. It SHOULD uniquely identify an instance of within a . Taken together, these three elements comprise a unique name for an SRV/ TXT record pair within the DNS subdomain. The granularity of a service name MAY be that of a host or group, or it could represent a particular resource within a CoAP server. The SRV record contains the host name (AAAA record name) and port of the service while protocol is part of the service name. In the case where a service name identifies a particular resource, the path part of the URI must be carried in a corresponding TXT record. A DNS TXT record is in practice limited to a few hundred octets in length, which is indicated in the resource record header in the DNS response message. The data consists of one or more strings comprising a key=3Dvalue pair. By convention, the first pair is txtver=3D (to support different versions of a service description). 10.2. mapping ins to The Resource Instance "ins" attribute maps to the part of a DNS-SD service name. It is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. However, to the extent that the "ins" attribute may be chosen to match the DNS host name of a service, it SHOULD use the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. The part of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can allow the device or service to be accessed in many cases without any manual configuration at all. The default name should be short and descriptive, and MAY include a collision-resistant substring such as the lower bits of the device's MAC address, serial number, Shelby, et al. Expires January 8, 2017 [Page 34] =0C Internet-Draft CoRE Resource Directory July 2016 fingerprint, or other identifier in an attempt to make the name relatively unique. DNS labels are currently limited to 63 octets in length and the entire service name may not exceed 255 octets. 10.3. Mapping rt to The resource type "rt" attribute is mapped into the part of a DNS-SD service name and SHOULD conform to the reg-rel-type production of the Link Format defined in Section 2 of [RFC6690]. The "rt" attribute MUST be composed of at least a single Net-Unicode text string, without underscore '_' or period '.' and limited to 15 octets in length, which represents the application protocol name. This string is mapped to the DNS-SD by prepending an underscore and appending a period followed by the "_udp" label. For example, rt=3D"dali" is mapped into "_dali._udp". The application protocol name may be optionally followed by a period and a service subtype name consisting of a Net-Unicode text string, without underscore or period and limited to 63 octets. This string is mapped to the DNS-SD by appending a period followed by the "_sub" label and then appending a period followed by the service type label pair derived as in the previous paragraph. For example, rt=3D"dali.light" is mapped into "light._sub._dali._udp". The resulting string is used to form labels for DNS-SD records which are stored directly in the DNS. 10.4. Domain mapping DNS domains may be derived from the "d" attribute. The domain attribute may be suffixed with the zone name of the authoritative DNS server to generate the domain name. The "ep" attribute is prefixed to the domain name to generate the FQDN to be stored into DNS with an AAAA RR. 10.5. TXT Record key=3Dvalue strings A number of [RFC6763] key/value pairs are derived from link-format information, to be exported in the DNS-SD as key=3Dvalue strings in a TXT record ([RFC6763], Section 6.3). The resource is exported as key/value pair "path=3D". The Interface Description "if" attribute is exported as key/value pair "if=3D". Shelby, et al. Expires January 8, 2017 [Page 35] =0C Internet-Draft CoRE Resource Directory July 2016 The DNS TXT record can be further populated by importing any other resource description attributes as they share the same key=3Dvalue format specified in Section 6 of [RFC6763]. 10.6. Importing resource links into DNS-SD Assuming the ability to query a Resource Directory or multicast a GET (?exp) over the local link, CoAP resource discovery may be used to populate the DNS-SD database in an automated fashion. CoAP resource descriptions (links) can be exported to DNS-SD for exposure to service discovery by using the Resource Instance attribute as the basis for a unique service name, composed with the Resource Type as the , and registered in the correct . The agent responsible for exporting records to the DNS zone file SHOULD be authenticated to the DNS server. The following example shows an agent discovering a resource to be exported: Req: GET /rd-lookup/res?exp Res: 2.05 Content ; exp;rt=3D"dali.light";ins=3D"Spot"; d=3D"office";ep=3D"node1" The agent subsequently registers the following DNS-SD RRs, assuming a zone name "example.com" prefixed with "office": node1.office.example.com. IN AAAA FDFD::1234 _dali._udp.office.example.com IN PTR Spot._dali._udp.office.example.com light._sub._dali._udp.example.com IN PTR Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com IN SRV 0 0 5683 node1.office.example.com. Spot._dali._udp.office.example.com IN TXT txtver=3D1;path=3D/light/1 In the above figure the Service Name is chosen as Spot._dali._udp.office.example.com without the light._sub service prefix. An alternative Service Name would be: Spot.light._sub._dali._udp.office.example.com. 11. Security Considerations The security considerations as described in Section 7 of [RFC5988] and Section 6 of [RFC6690] apply. The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as Shelby, et al. Expires January 8, 2017 [Page 36] =0C Internet-Draft CoRE Resource Directory July 2016 described in [RFC7252]. DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. 11.1. Endpoint Identification and Authentication An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. 11.2. Access Control Access control SHOULD be performed separately for the RD Function Set and the RD Lookup Function Set, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. 11.3. Denial of Service Attacks Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than Shelby, et al. Expires January 8, 2017 [Page 37] =0C Internet-Draft CoRE Resource Directory July 2016 requests, RDs can unknowingly become part of a DDoS amplification attack. Therefore, it is RECOMMENDED that implementations ensure return routability. This can be done, for example by responding to wild card lookups only over DTLS or TLS or TCP. 12. IANA Considerations 12.1. Resource Types "core.rd", "core.rd-group" and "core.rd-lookup" resource types need to be registered with the resource type registry defined by [RFC6690]. 12.2. Link Extension The "exp" and "ins" attributes need to be registered when a future Web Linking link-extension registry is created (e.g. in RFC5988bis). 12.3. IPv6 ND Resource Directory Address Option This document registers one new ND option type under the subregistry "IPv6 Neighbor Discovery Option Formats": o Resource Directory address Option (38) 12.4. RD Parameter Registry This specification defines a new sub-registry for registration and lookup parameters called "RD Parameters" under "CoRE Parameters". Although this specification defines a basic set of parameters, it is expected that other standards that make use of this interface will define new ones. Each entry in the registry must include the human readable name of the parameter, the query parameter, validity requirements if any and a description. The query parameter MUST be a valid URI query key [RFC3986]. Initial entries in this sub-registry are as follows: Shelby, et al. Expires January 8, 2017 [Page 38] =0C Internet-Draft CoRE Resource Directory July 2016 +-----------+-------+---------------+-------------------------------+ | Name | Query | Validity | Description | +-----------+-------+---------------+-------------------------------+ | Endpoint | ep | | Name of the endpoint, max 63 | | Name | | | bytes | | Lifetime | lt | 60-4294967295 | Lifetime of the registration | | | | | in seconds | | Domain | d | | Domain to which this endpoint | | | | | belongs | | Endpoint | et | | Semantic name of the endpoint | | Type | | | | | Context | con | URI | The scheme, address and port | | | | | at which this server is | | | | | available | | Resource | res | | Name of the resource | | Name | | | | | Group | gp | | Name of a group in the RD | | Name | | | | | Page | page | Integer | Used for pagination | | Count | count | Integer | Used for pagination | | Resource | ins | | Instance Identifier | | Instance | | | | | Export | exp | | A link MAY be exported to | | | | | another Resource Directory | +-----------+-------+---------------+-------------------------------+ Table 1: RD Parameters The IANA policy for future additions to the sub-registry is "Expert Review" as described in [RFC5226]. 13. Examples Examples are added here. 13.1. Lighting Installation This example shows a simplified lighting installation which makes use of the Resource Directory (RD) with a CoAP interface to facilitate the installation and start up of the application code in the lights and sensors. In particular, the example leads to the definition of a group and the enabling of the corresponding multicast address. No conclusions must be drawn on the realization of actual installation or naming procedures, because the example only "emphasizes" some of the issues that may influence the use of the RD and does not pretend to be normative. Shelby, et al. Expires January 8, 2017 [Page 39] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.1. Installation Characteristics The example assumes that the installation is managed. That means that a Commissioning Tool (CT) is used to authorize the addition of nodes, name them, and name their services. The CT can be connected to the installation in many ways: the CT can be part of the installation network, connected by WiFi to the installation network, or connected via GPRS link, or other method. It is assumed that there are two naming authorities for the installation: (1) the network manager that is responsible for the correct operation of the network and the connected interfaces, and (2) the lighting manager that is responsible for the correct functioning of networked lights and sensors. The result is the existence of two naming schemes coming from the two managing entities. The example installation consists of one presence sensor, and two luminaries, luminary1 and luminary2, each with their own wireless interface. Each luminary contains three lamps: left, right and middle. Each luminary is accessible through one endpoint. For each lamp a resource exists to modify the settings of a lamp in a luminary. The purpose of the installation is that the presence sensor notifies the presence of persons to a group of lamps. The group of lamps consists of: middle and left lamps of luminary1 and right lamp of luminary2. Before commissioning by the lighting manager, the network is installed and access to the interfaces is proven to work by the network manager. At the moment of installation, the network under installation is not necessarily connected to the DNS infra structure. Therefore, SLAAC IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in Table 2 below: +--------------------+--------------+ | Name | IPv6 address | +--------------------+--------------+ | luminary1 | FDFD::ABCD:1 | | luminary2 | FDFD::ABCD:2 | | Presence sensor | FDFD::ABCD:3 | | Resource directory | FDFD::ABCD:0 | +--------------------+--------------+ Table 2: interface SLAAC addresses Shelby, et al. Expires January 8, 2017 [Page 40] =0C Internet-Draft CoRE Resource Directory July 2016 In Section 13.1.2 the use of resource directory during installation is presented. In Section 13.1.3 the connection to DNS is discussed. 13.1.2. RD entries It is assumed that access to the DNS infrastructure is not always possible during installation. Therefore, the SLAAC addresses are used in this section. For discovery, the resource types (rt) of the devices are important. The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor. The endpoints have names which are relevant to the light installation manager. In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door. The endpoint names reflect this physical location. The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively. The identifiers relevant to the Resource Directory are shown in Table 3 below: +----------------+------------------+---------------+---------------+ | Name | endpoint | resource path | resource type | +----------------+------------------+---------------+---------------+ | luminary1 | lm_R2-4-015_wndw | /light/left | light | | luminary1 | lm_R2-4-015_wndw | /light/middle | light | | luminary1 | lm_R2-4-015_wndw | /light/right | light | | luminary2 | lm_R2-4-015_door | /light/left | light | | luminary2 | lm_R2-4-015_door | /light/middle | light | | luminary2 | lm_R2-4-015_door | /light/right | light | | Presence | ps_R2-4-015_door | /ps | p-sensor | | sensor | | | | +----------------+------------------+---------------+---------------+ Table 3: Resource Directory identifiers The CT inserts the endpoints of the luminaries and the sensor in the RD using the Context parameter (con) to specify the interface address: Shelby, et al. Expires January 8, 2017 [Page 41] =0C Internet-Draft CoRE Resource Directory July 2016 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_wndw&con=3Dcoap://[FDFD::ABCD:1] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light";d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4521 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:2] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4522 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dps_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:3] Payload: ;rt=3D"p-sensor"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4523 The domain name d=3D"R2-4-015" has been added for an efficient lookup because filtering on "ep" name is more awkward. The same domain name is communicated to the two luminaries and the presence sensor by the CT. The group is specified in the RD. The Context parameter is set to the site-local multicast address allocated to the group. In the POST in the example below, these two endpoints and the endpoint of the presence sensor are registered as members of the group. Req: POST coap://[FDFD::ABCD:0]/rd-group ?gp=3Dgrp_R2-4-015;con=3D"coap//[FF05::1]";exp;ins=3D"grp1234" Payload: <>ep=3Dlm_R2-4-015_wndw, <>ep=3Dlm_R2-4-015_door, <>ep=3Dps_R2-4-015_door Res: 2.01 Created Location: /rd-group/501 Shelby, et al. Expires January 8, 2017 [Page 42] =0C Internet-Draft CoRE Resource Directory July 2016 After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. The luminary, knowing its domain, queries the RD for the endpoint with rt=3Dlight and d=3DR2-4-015. The RD returns all endpoints in = the domain. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep ?d=3DR2-4-015;rt=3Dlight Res: 2.05 Content ; ep=3D"lm_R2-4-015_wndw", ; ep=3D"lm_R2-4-015_door" Knowing its own IPv6 address, the luminary discovers its endpoint name. With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp ?ep=3Dlm_R2-4-015_wndw Res: 2.05 Content ;gp=3D"grp_R2-4-015" =46rom the context parameter value, the luminary learns the multicast address of the multicast group. Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in [RFC7390]. Req: POST //[FDFD::ABCD:1]/coap-group Content-Format: application/coap-group+json { "a": "[FF05::1]", "n": "grp_R2-4-015"} Res: 2.01 Created Location-Path: /coap-group/1 Dependent on the situation only the address ,"a", or the name, "n", is specified in the coap-group resource. Shelby, et al. Expires January 8, 2017 [Page 43] =0C Internet-Draft CoRE Resource Directory July 2016 13.1.3. DNS entries It may be profitable to discover the light groups for applications, which are unaware ot the existence of the RD. An agent needs to query the RD to return all groups which are exported to be inserted into DNS. Req: GET /rd-lookup/gp?exp Res: 2.05 Content ;exp;gp=3D"grp_R2-4-015;ins=3D"grp1234"; ep=3D"lm_R2-4-015_wndw"; ep=3D"lm_R2-4-015_door The group with FQDN grp_R2-4-015.bc.example.com can be entered into the DNS by the agent. The accompanying instance name is grp1234. The is chosen to be _group._udp. The agent enters the following RRs into the DNS. grp_R2-4-015.bc.example.com. IN AAAA FF05::1 _group._udp.bc.example.com IN PTR grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com IN SRV 0 0 5683 grp_R2-4-015_door.bc.example.com. grp1234._group._udp.bc.example.com IN TXT txtver=3D1;path=3D/light/grp1 =46rom then on applications, not familiar with the existence of the = RD, can use DNS to access the lighting group. 13.2. OMA Lightweight M2M (LWM2M) Example This example shows how the OMA LWM2M specification makes use of Resource Directory (RD). OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority). LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing a Resource Directory along with other LWM2M interfaces defined by the LWM2M specification. CoRE Resource Directory (RD) is used to provide the LWM2M Registration interface. Shelby, et al. Expires January 8, 2017 [Page 44] =0C Internet-Draft CoRE Resource Directory July 2016 LWM2M does not provide for registration domains and does not currently use the rd-group or rd-lookup interfaces. The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server. Other interfaces, proxies, applications, and function sets are currently out of scope for LWM2M. The location of the LWM2M Server and RD Function Set is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD function set is used. LWM2M Servers and endpoints are not required to implement the ./well-known/core resource. 13.2.1. The LWM2M Object Model The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. An LWM2M Object is a resource template and container type that encapsulates a set of related resources. An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings. base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined". As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". [_TEMPLATE_TODO] Shelby, et al. Expires January 8, 2017 [Page 45] =0C Internet-Draft CoRE Resource Directory July 2016 base-uri :=3D Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id :=3D OMNA (OMA Name Authority) registered object ID = (0-65535) object-instance :=3D Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id :=3D OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance :=3D Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings. For example, a LWM2M URI might be: /1/0/1 The base uri is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined". This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 13.2.2. LWM2M Register Endpoint LWM2M defines a registration interface based on the Resource Directory Function Set, described in Section 6. The URI of the LWM2M Resource Directory function set is specified to be "/rd" as recommended in Section 6.3. LWM2M endpoints register object IDs, for example , to indicate that a particular object type is supported, and register object instances, for example , to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format. Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. Shelby, et al. Expires January 8, 2017 [Page 46] =0C Internet-Draft CoRE Resource Directory July 2016 When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in Table 1 : ep - Endpoint Name lt - registration lifetime Endpoint Name is mandatory, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 4: LWM2M Additional Registration Parameters The following RD registration parameters are not currently specified for use in LWM2M: et - Endpoint Type con - Context The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: ,,, This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. Shelby, et al. Expires January 8, 2017 [Page 47] =0C Internet-Draft CoRE Resource Directory July 2016 13.2.3. Alternate Base URI If the LWM2M endpoint exposes objects at a base URI other than the default empty base path, the endpoint must register the base URI using rt=3D"oma.lwm2m". An example link payload using alternate base URI would be: ;rt=3D"oma.lwm2m",,, This link payload indicates that the lwm2m objects will be placed under the base URI "/my_lwm2m" and that object ID 1 (server) is supported, with a single instance 0 existing, and object 5 (firmware update) is supported. 13.2.4. LWM2M Update Endpoint Registration An LWM2M Registration update proceeds as described in Section 6.4, and adds some optional parameter updates: lt - Registration Lifetime b - Protocol Binding sms - MSISDN link payload - new or modified links A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. 13.2.5. LWM2M De-Register Endpoint LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation. LWM2M de- registration proceeds as described in Section 6.5. 14. Acknowledgments Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided helpful comments, discussions and ideas to improve and shape this document. Section 9 is based on an earlier draft by Kerry Lynn. Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. Shelby, et al. Expires January 8, 2017 [Page 48] =0C Internet-Draft CoRE Resource Directory July 2016 15. Changelog changes from -07 to -08 o removed link target value returned from domain and group lookup types o Maximum length of domain parameter 63 bytes for consistency with group o removed option for simple POST of link data, don't require a .well-known/core resource to accept POST data and handle it in a special way; we already have /rd for that o add IPv6 ND Option for discovery of an RD o clarify group configuration section 6.1 that endpoints must be registered before including them in a group o removed all superfluous client-server diagrams o simplified lighting example o introduced Commissioning Tool o RD-Look-up text is extended. changes from -06 to -07 o added text in the discovery section to allow content format hints to be exposed in the discovery link attributes o editorial updates to section 9 o update author information o minor text corrections Changes from -05 to -06 o added note that the PATCH section is contingent on the progress of the PATCH method changes from -04 to -05 o added Update Endpoint Links using PATCH o http access made explicit in interface specification Shelby, et al. Expires January 8, 2017 [Page 49] =0C Internet-Draft CoRE Resource Directory July 2016 o Added http examples Changes from -03 to -04: o Added http response codes o Clarified endpoint name usage o Add application/link-format+cbor content-format Changes from -02 to -03: o Added an example for lighting and DNS integration o Added an example for RD use in OMA LWM2M o Added Read Links operation for link inspection by endpoints o Expanded DNS-SD section o Added draft authors Peter van der Stok and Michael Koster Changes from -01 to -02: o Added a catalogue use case. o Changed the registration update to a POST with optional link format payload. Removed the endpoint type update from the update. o Additional examples section added for more complex use cases. o New DNS-SD mapping section. o Added text on endpoint identification and authentication. o Error code 4.04 added to Registration Update and Delete requests. o Made 63 bytes a SHOULD rather than a MUST for endpoint name and resource type parameters. Changes from -00 to -01: o Removed the ETag validation feature. o Place holder for the DNS-SD mapping section. o Explicitly disabled GET or POST on returned Location. Shelby, et al. Expires January 8, 2017 [Page 50] =0C Internet-Draft CoRE Resource Directory July 2016 o New registry for RD parameters. o Added support for the JSON Link Format. o Added reference to the Groupcomm WG draft. Changes from -05 to WG Document -00: o Updated the version and date. Changes from -04 to -05: o Restricted Update to parameter updates. o Added pagination support for the Lookup interface. o Minor editing, bug fixes and reference updates. o Added group support. o Changed rt to et for the registration and update interface. Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten. o Editorial improvements. o Fixed the use of ETags. o Fixed tickets 383 and 372 Changes from -02 to -03: o Changed the endpoint name back to a single registration parameter ep=3D and removed the h=3D and ins=3D parameters. o Updated REST interface descriptions to use RFC6570 URI Template format. o Introduced an improved RD Lookup design as its own function set. o Improved the security considerations section. o Made the POST registration interface idempotent by requiring the ep=3D parameter to be present. Shelby, et al. Expires January 8, 2017 [Page 51] =0C Internet-Draft CoRE Resource Directory July 2016 Changes from -01 to -02: o Added a terminology section. o Changed the inclusion of an ETag in registration or update to a MAY. o Added the concept of an RD Domain and a registration parameter for it. o Recommended the Location returned from a registration to be stable, allowing for endpoint and Domain information to be changed during updates. o Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 16. References 16.1. Normative References [I-D.ietf-core-links-json] Li, K., Rahman, A., and D. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-05 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . Shelby, et al. Expires January 8, 2017 [Page 52] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . 16.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Shelby, et al. Expires January 8, 2017 [Page 53] =0C Internet-Draft CoRE Resource Directory July 2016 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . Editorial Comments [_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert. Authors' Addresses Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Michael Koster SmartThings 665 Clyde Avenue Mountain View 94043 USA Phone: +1-707-502-5136 Email: Michael.Koster@smartthings.com Shelby, et al. Expires January 8, 2017 [Page 54] =0C Internet-Draft CoRE Resource Directory July 2016 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Shelby, et al. Expires January 8, 2017 [Page 55] --Apple-Mail=_A6EF9B6D-F4A7-4715-8132-C8B4663EB59A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On = Jul 8, 2016, at 8:32 AM, Michael Koster <michael.koster@smartthings.com> wrote:

couple more = nits

<draft-ietf-core-resour= ce-directory-xx.txt>

On Jul = 8, 2016, at 8:22 AM, Michael Koster <michael.koster@smartthings.com> wrote:

I have = addressed everything except these 2 comments:

On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:

6.6.  Read Endpoint Links
Is there any functionality that is not provided = through the lookup interface (apart from a quicker ep = selection)?

As part of the RD = evolution, a GET on the handle resource should primarily return the = forms to update and delete the registration. Forms that are pre-filled = with the endpoint information could enable a nice collection-based = lookup for management.

What would be the content-format used to = transmit the forms? I would expect GET on a collection with the content = format of the resource to return a representation of the resource = content, in this case the links in the collection. How should we = indicate the hypermedia controls of the resource? I think we need to = give this a little more thought, how to expose the controls of a = resource vs. the content. 

In the meantime, the lookup interface = could be used for inspection but the idea of having read and patch = update as operations on the links of one endpoint seems useful for doing = read-modify-write workflow on links. It's useful to use the same URI for = the resource instead of having to construct a different address to read = vs update.  Also I think discovery (lookup), modifying links, and = registration refresh are logically separate workflows in the client.
6.7.  Update Endpoint Links
Shouldn't this be merged with Section 6.4. = Registration Update?

See = above reason based on separate workflows. Does it make sense?

Best regards,

Michael

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


= --Apple-Mail=_A6EF9B6D-F4A7-4715-8132-C8B4663EB59A-- --Apple-Mail=_78C519D9-8C19-4636-A025-0646AB2985C1-- From nobody Fri Jul 8 10:04:59 2016 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 05B0B12D51F; Fri, 8 Jul 2016 10:04:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708170455.32099.75367.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 10:04:55 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:04:55 -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 Filename : draft-ietf-core-resource-directory-08.txt Pages : 55 Date : 2016-07-08 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 resources 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 10:16:12 2016 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 2427A12D1A2; Fri, 8 Jul 2016 10:16:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708171607.32042.80416.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 10:16:07 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-senml-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:16:07 -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 Markup Language (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-02.txt Pages : 32 Date : 2016-07-08 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-senml-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-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 Fri Jul 8 10:31:12 2016 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 31E8E127058; Fri, 8 Jul 2016 10:31:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708173107.32176.82161.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 10:31:07 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-interfaces-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:31:07 -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 : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Filename : draft-ietf-core-interfaces-05.txt Pages : 22 Date : 2016-07-05 Abstract: This document defines a set of reusable REST resource design patterns suitable for use in constrained environments, based on IETF CoRE standards for information representation and information exchange. Interface types for Sensors, Actuators, Parameters, and resource Collections are defined using the "if" link attribute defined by CoRE Link Format [RFC6690]. Clients may use the "if" attribute to determine how to consume resources. Editor's note: This version removes the observe notify functionality. Further work is needed on this draft to The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 14:54:53 2016 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 821B412D899; Fri, 8 Jul 2016 14:54:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708215451.32201.18476.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:54:51 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:54:51 -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 CoRE Formats in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-06.txt Pages : 17 Date : 2016-07-08 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-links-json-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 14:56:32 2016 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 B1C7612D196 for ; Fri, 8 Jul 2016 14:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Fi2eU3xPAnH for ; Fri, 8 Jul 2016 14:56:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B3D2612D658 for ; Fri, 8 Jul 2016 14:56:28 -0700 (PDT) Received: from localhost ([::1]:52464 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bLdl4-0004xD-AP; Fri, 08 Jul 2016 14:56:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 08 Jul 2016 21:56:26 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/403#comment:1 Message-ID: <067.2ffd181343b4ffe435a7f3788fb8b567@trac.tools.ietf.org> References: <052.3af9ec97625b82887b23f6f7cb3e7b42@trac.tools.ietf.org> X-Trac-Ticket-ID: 403 In-Reply-To: <052.3af9ec97625b82887b23f6f7cb3e7b42@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-links-json@ietf.org Resent-Message-Id: <20160708215628.B3D2612D658@ietfa.amsl.com> Resent-Date: Fri, 8 Jul 2016 14:56:28 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #403 (links-json): Should the RFC 7390 part of links-json be split off? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:56:31 -0000 #403: Should the RFC 7390 part of links-json be split off? Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Yes. Done as draft-ietf-core-links-json-06 and draft-bormann-core-groupcomm-cbor -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-links- cabo@tzi.org | json@tools.ietf.org Type: other | Status: closed technical | Milestone: Priority: major | Version: links-json-05 Component: links-json | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 8 14:57:23 2016 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 A442112D630 for ; Fri, 8 Jul 2016 14:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 URR8IlesQLmn for ; Fri, 8 Jul 2016 14:57:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 12F1212D0E8 for ; Fri, 8 Jul 2016 14:57:11 -0700 (PDT) Received: from localhost ([::1]:52488 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bLdlm-0004zu-QX; Fri, 08 Jul 2016 14:57:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 08 Jul 2016 21:57:10 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/402#comment:1 Message-ID: <067.109a3fa68b5e4903d936de6e08cf84f2@trac.tools.ietf.org> References: <052.afe507cbdb0a58173eb88ad02c4f8b5f@trac.tools.ietf.org> X-Trac-Ticket-ID: 402 In-Reply-To: <052.afe507cbdb0a58173eb88ad02c4f8b5f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-links-json@ietf.org Resent-Message-Id: <20160708215711.12F1212D0E8@ietfa.amsl.com> Resent-Date: Fri, 8 Jul 2016 14:57:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #402 (links-json): A reference implementation for links-json would be useful. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:57:22 -0000 #402: A reference implementation for links-json would be useful. Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Done in draft-ietf-core-links-json-06 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-links- cabo@tzi.org | json@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: Component: links-json | Version: links-json-05 Severity: Active WG | Resolution: fixed Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 8 14:59:04 2016 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 13CEB12B00F for ; Fri, 8 Jul 2016 14:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp3Y7xGSlW9A for ; Fri, 8 Jul 2016 14:59:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 54BB412D88A for ; Fri, 8 Jul 2016 14:58:35 -0700 (PDT) Received: from localhost ([::1]:52501 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bLdn9-00052z-40; Fri, 08 Jul 2016 14:58:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 08 Jul 2016 21:58:35 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/404#comment:1 Message-ID: <067.3be1838470d3837eb66553447e369310@trac.tools.ietf.org> References: <052.cb798e74d0275b4e793c5377c157ca6f@trac.tools.ietf.org> X-Trac-Ticket-ID: 404 In-Reply-To: <052.cb798e74d0275b4e793c5377c157ca6f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-links-json@ietf.org Resent-Message-Id: <20160708215835.54BB412D88A@ietfa.amsl.com> Resent-Date: Fri, 8 Jul 2016 14:58:35 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #404 (links-json): The group-format representations in CBOR use textual representations of IP addresses and port numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:59:03 -0000 #404: The group-format representations in CBOR use textual representations of IP addresses and port numbers Changes (by cabo@tzi.org): * version: links-json-05 => * severity: Active WG Document => - Comment: This is now a ticket on draft-bormann-core-groupcomm-cbor (and continues to need consideration). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-links- cabo@tzi.org | json@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: links-json | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 8 14:59:37 2016 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 D5D8212B004 for ; Fri, 8 Jul 2016 14:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK25bdZkSUX7 for ; Fri, 8 Jul 2016 14:59:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 085F812D611 for ; Fri, 8 Jul 2016 14:59:32 -0700 (PDT) Received: from localhost ([::1]:52519 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bLdo0-00059V-9K; Fri, 08 Jul 2016 14:59:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 08 Jul 2016 21:59:28 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/404#comment:2 Message-ID: <067.bb87045aaec63f1cac3e8245fa741377@trac.tools.ietf.org> References: <052.cb798e74d0275b4e793c5377c157ca6f@trac.tools.ietf.org> X-Trac-Ticket-ID: 404 In-Reply-To: <052.cb798e74d0275b4e793c5377c157ca6f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-groupcomm@ietf.org Resent-Message-Id: <20160708215932.085F812D611@ietfa.amsl.com> Resent-Date: Fri, 8 Jul 2016 14:59:32 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #404 (groupcomm): The group-format representations in CBOR use textual representations of IP addresses and port numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:59:35 -0000 #404: The group-format representations in CBOR use textual representations of IP addresses and port numbers Changes (by cabo@tzi.org): * owner: draft-ietf-core-links-json@tools.ietf.org => draft-ietf-core- groupcomm@tools.ietf.org * component: links-json => groupcomm -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 8 15:02:06 2016 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 F32DD12D0C2 for ; Fri, 8 Jul 2016 15:02:03 -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 jAk4SR2iWSva for ; Fri, 8 Jul 2016 15:02:01 -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 574B412B01D for ; Fri, 8 Jul 2016 15:02:01 -0700 (PDT) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id C5C51A80D0; Sat, 9 Jul 2016 00:01:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id GF_r5oKq3sxb; Sat, 9 Jul 2016 00:01:58 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id D3184A80BF; Sat, 9 Jul 2016 00:01:57 +0200 (CEST) Message-ID: <578022D4.2060506@tzi.org> Date: Sat, 09 Jul 2016 00:01:56 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" References: <3A2F4C70-4960-4592-9314-6EC53B53CC94@cisco.com> In-Reply-To: <3A2F4C70-4960-4592-9314-6EC53B53CC94@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "t2trg@irtf.org" Subject: [core] Fwd: [Anima-bootstrap] bootstrap over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 22:02:04 -0000 Didn't read it yet, but sounds interesting (for both CoRE and the T2TRG security bootstrapping work). Grüße, Carsten -------- Original Message -------- Subject: [Anima-bootstrap] bootstrap over CoAP Date: Fri, 8 Jul 2016 21:59:13 +0000 From: Max Pritikin (pritikin) To: anima-bootstrap@ietf.org Folks, As hinted at in section 5.7.5 of the 03 bootstrapping document we wanted to put some more time and thought into what a CoAP requirement and solution would look like. https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-03#section-5.7.5 To expand on the thinking this draft now exists: https://tools.ietf.org/html/draft-pritikin-coap-bootstrap-00 This is of course rough thoughts. Opinions and feedback strongly solicited. Pointers to other work you want this to contrast against and or details you feel worthy of additional discussion etc are all solicited. Thanks! See you all in Berlin, - max _______________________________________________ Anima-bootstrap mailing list Anima-bootstrap@ietf.org https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Fri Jul 8 15:46:04 2016 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 F1ADD12D76C; Fri, 8 Jul 2016 15:46:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708224601.32079.31903.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 15:46:01 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-21.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 22:46:02 -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 : Block-wise transfers in CoAP Authors : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-21.txt Pages : 35 Date : 2016-07-08 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged. There is therefore an expectation that the Block options are very widely implemented in CoAP implementations, which is why this specification is listed as "updating" RFC 7252. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-block-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 15:48:26 2016 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 1CA7812D76C; Fri, 8 Jul 2016 15:48:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708224824.32172.32846.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 15:48:24 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 22:48:24 -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 (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-03.txt Pages : 39 Date : 2016-07-08 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 16:00:26 2016 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 54E6E12B028 for ; Fri, 8 Jul 2016 16:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 6Ohsj7l8a8pn for ; Fri, 8 Jul 2016 16:00:21 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0135.outbound.protection.outlook.com [104.47.37.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 A6FFD12D580 for ; Fri, 8 Jul 2016 16:00:19 -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=gdasLEzIf1k9mf8V/PgvI35u5NghHhNMWqxLfrM/aFM=; b=XOmbZUJHYDdwrBdW0PuatY0wthK44hzYRGzC0yqVj1s4KcatP9MJQpmv2rwHLJYBsC0o6SHesm3EvtHE2nJAUrdhGFmGE/N30ceCuDHzuYjYdaO6UTcyc8kQ0t+Ftuf8NcxEOEDSztFx6ECohTPAnjYlQEKO4ZmcXIguUYr4KlM= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 8 Jul 2016 23:00:17 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0528.024; Fri, 8 Jul 2016 23:00:17 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXw Date: Fri, 8 Jul 2016 23:00:16 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> In-Reply-To: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: c35fd3f4-9d4f-4344-fcc2-08d3a783a0e5 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:NvtZsQKPSfzqxf3JguHLKWYkDCBNCseqPC3qKO1yZHkD2NNFdfdFCvuKBeYOB8hhzL0mdqK7V5llG3V4M3gcGmoK8/YiFak+roRGy4eO2lnRW/cY3ztjL+8TPCBTLIfKQuyMNmj/VMDb2iu44C2K7io+qKBUa3KWAVVf2Zz6QBWFU+YxDj8Bq23x5RcdvA9woFxHtdSqzY7lppLBt6vy2HY+4ABa4+R5U+Cb2RnXfZhGp4DHKQZEmApUTVbfntk1izmgMMS2ff8Vfl8TawPBmeTmV91e1+WO+KWwQi6ltMs=; 5:2xugKESW6yqEjwgCmGraG5de3ulie1C1b812ea/oxyGE7QppEaGavlYBlddnHssI33hF8PdKjAMIq9my5egLTf3SdnVRSXPkE1uXHevEDb0CxikMj8sw25p7m2jjiR9H05wIqSxFd3W2dsM+E5dRHQ==; 24:1xNfe8q4Phe/5T5BbPiWqXg8PgMk5IQ487XfbwH2dxs+zQw8zOjaZw6jo/liaPtGyithbdOtJRnqLsxtYfEYNhrWi2A1eTY7zpzlUaeFXkQ=; 7:py9IC2wbwZYmFgKzIlkGGd6R3ZFmxIsqXeqAGplXNuk2+d9zgb0v4KnfspxcaCGB/IL5IGsOl2T4KMKscndsQUOkazm95q2SvxZMMNm0U0dx7TaMx4Nz1hqSUZnDJyCUXXUYz7hYA4e/+l8M3SZSAY3UmWpMuuvqdv0mPn/dgst15ZtSRFLruVHgQxKWAANjvY7HPZYFGcK1sUhHB2R5JBSmPJmmBEbKQecJIoo3jI4CgcVESJChVhUDCKinlI7h x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(100405760836317)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(51444003)(13464003)(129404003)(377454003)(189002)(77096005)(2351001)(3280700002)(81166006)(105586002)(10400500002)(87936001)(8676002)(81156014)(101416001)(3846002)(102836003)(4326007)(1720100001)(76176999)(50986999)(6116002)(15975445007)(3660700001)(76576001)(92566002)(68736007)(586003)(2900100001)(1730700003)(110136002)(2906002)(122556002)(189998001)(99286002)(2501003)(7696003)(66066001)(97736004)(2950100001)(106356001)(54356999)(106116001)(11100500001)(8936002)(74316002)(5002640100001)(7736002)(5003600100003)(7846002)(86362001)(33656002)(305945005)(575784001)(19580405001)(9686002)(19580395003)(5640700001)(5890100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 23:00:16.6959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 23:00:24 -0000 SGkgUGV0ZXINCg0KU2VlIGFuc3dlcnMgaW5saW5lIFtNVl0NCg0KVGhlc2UgY2hhbmdlcyB3aWxs IGJlIHN1Ym1pdHRlZCBsYXRlciB0b2RheS4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIHBldGVyIHZhbiBkZXIgU3Rvaw0KU2VudDogVHVlc2RheSwgSnVs eSA1LCAyMDE2IDU6NTEgQU0NClRvOiBDb3JlIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogW2Nv cmVdIFlBTkcgdG8gQ0JPUiBtYXBwaW5nIHZlcnNpb24gMQ0KDQpIaSBhdXRob3JzLA0KDQpBdHRh Y2hlZCBteSByZXZpZXcgb2YgdGhlIGRvY3VtZW50Lg0KSSBoYXZlIG5vdCBsb29rZWQgYXQgdGhl IGVudW0sIHVuaW9uIGVuY29kaW5nIGFzIHRoaXMgd2FzIGRvbmUgYnkgQW5keS4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpZQU5HIHRvIENCT1INClNlY3Rpb24gMSBsaW5lIDI7IHJlbW92ZSDi gJxvbmx54oCdDQoNCltNVl0g4oCcb25seeKAnSByZW1vdmVkDQoNClBhZ2UgNTsgdGhlIHRhYmxl IGlzIHJlZmVyZW5jZWQgbm93aGVyZQ0KDQpbTVZdIEFkZGluZyB0byB0aGUgdGV4dDoNCltNVl0g VGFibGUgMSBiZWxvdyBwcm92aWRlcyBhIHN1bW1hcnkgb2YgdGhpcyBub3RhdGlvbi4NCltNVl0N CltNVl0gQWRkaW5nIGFmdGVyIHRoZSB0YWJsZToNCltNVl0gVGFibGUgMSA6IENCT1IgZGlhZ25v c3RpYyBub3RhdGlvbiBzdW1tYXJ5DQoNCkVuZCBvZiBzZWN0aW9uIDIuMSDigJxEZWx0YXMgYXJl IHJlcHJlc2VudGVkIGFzIHBvc2l0aXZlIG51bWJlcuKAnSBpcyBjb250cmFkaWN0ZWQgaW4gc2Vj dGlvbiA0LjIg4oCcU0lEcyBhcyBrZXlz4oCdIHNlY29uZCBidWxsZXQ6IOKAnENsaWVudHMgYW5k IHNlcnZlcnMgTVVTVCBzdXBwb3J0IG5lZ2F0aXZlIGRlbHRhcy4NClN1Z2dlc3Rpb246IERlbHRh cyBhcmUgcmVwcmVzZW50ZWQgYXMgbnVtYmVycyBwcmVjZWRlZCBieSBhICsgb3Ig4oCTIHNpZ24N Cg0KW01WXSBSZW1vdmluZyAib3IgKzEyMyIgaW4gdGhlIGZpcnN0IGxpbmUgb2YgdGhlIHRhYmxl DQpbTVZdIFNlY29uZCBub3RlIGJlbGxvdyB0aGUgdGFibGUgaXMgdXBkYXRlZCB0bzoNCltNVl0g 4oCiCURlbHRhcyBhcmUgcmVwcmVzZW50ZWQgYXMgbnVtYmVycyBwcmVjZWRlZCBieSBhICsgb3Ig 4oCTIHNpZ24uDQpbTVZdIFRoZSB1c2Ugb2YgdGhlICsgc2lnbiBmb3IgcG9zaXRpdmUgZGVsdGFz IHJlcHJlc2VudHMgYW4gZXh0ZW5zaW9uIHRvDQpbTVZdIHRoZSBDQk9SIGRpYWdub3N0aWMgbm90 YXRpb24gYXMgZGVmaW5lZCBieSBbUkZDNzA0OV0gc2VjdGlvbiA2Lg0KDQpFbmQgcGFnZSA1OiDi gJx2YWx1ZSBuZWVk4oCdIC0+IOKAnHZhbHVlIG5lZWRz4oCdDQoNCltNVl0gRml4ZWQNCg0KU2Vj dGlvbiAzOiDigJx0aGUgc3BlY2lmaWNhdGlvbiBzdXBwb3J0cyB0aHJlZSB0eXBlcyBvZiBrZXlz LuKAnQ0KSSB3b3VsZCBzdWdnZXN0IG9ubHkgMjogY2hhcmFjdGVyIHN0cmluZ3MgYW5kIG51bWJl cnMuDQpUaGUgdXNlIG9mIGRlbHRhcyBpcyBlaXRoZXIgYXBwbGljYXRpb24gKENvT0wpIHNwZWNp ZmljIG9yIFlBTkcgdG8gQ0JPUiBtYXBwaW5nIHNwZWNpZmljLg0KSWYgaXQgaXMgWUFORyB0byBD Qk9SIHNwZWNpZmljLCBJIHdvdWxkIGVuY291cmFnZSB0aGUgdXNlIG9mIGFub3RoZXIgQ0JPUiB0 eXBlIHRoYXQgc3BlY2lmaWVzIGEgZGVsdGEuIEFzIHNwZWNpZmllZCBoZXJlIGl0cyB1c2UgaXMg YW1iaWd1b3VzOyBhbmQgZm9yY2VzIGVhY2ggYXBwbGljYXRpb24gdG8gc3BlY2lmeSBleHBsaWNp dGx5IHdoYXQgaXMgbWVhbnQuDQpJbiB0aGUgY2FzZSB0aGF0IHRoZSBkZWx0YSBpcyBDb09MIHNw ZWNpZmljLCBJIHJlY29tbWVuZCB0byByZW1vdmUgaXQgY29tcGxldGVseSBmcm9tIHRoaXMgZHJh ZnQsIGFuZCBleHBsYWluIHRoZSB1c2Ugb2YgRGVsdGFzIGluIHRoZSBhcHByb3ByaWF0ZSBDb09M IGRyYWZ0Lg0KSW4gdGhlIGxhdHRlciBjYXNlOiBXaGF0IHJlbWFpbnMgYXJlIHR3byBrZXkgdHlw ZXM6IG51bWJlciBhbmQgY2hhcmFjdGVyIHN0cmluZy4NCg0KW01WXSBUaGUgdXNlIG9mIGRlbHRh IHRvIGVuY29kZSBpbnRlZ2VyIGJhc2VkIGtleXMgKFNJRHMpIGlzIGFuIGludGVncmFsIHBhcnQg b2YgdGhlIFlBTkcgdG8gQ0JPUiBtYXBwaW5nLg0KW01WXSBUaGlzIG9wdGltaXphdGlvbiBpcyBw YXJ0IG9mIHRoZSBlbmNvZGluZyBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIGFwcGxpY2F0aW9uLg0K W01WXSBUaGUgZG9jdW1lbnQgaXMgdXBkYXRlZCB0byBrZWVwIG9ubHkgMiB0eXBlIG9mIGtleXMN Cg0KTGFzdCBhbGluZWEgb2Ygc2VjdGlvbiAzOiDigJxlbnRpdGllcyBnZW5lcmF0aW5n4oCdIHNo b3VsZCB0aGF0IG5vdCBiZeKAnSANCmFnZW50cyAocHJvY2Vzc2VzKSBnZW5lcmF0aW5n4oCd4oCm DQoNCltNVl0gVXBkYXRpbmcgdG8gImFwcGxpY2F0aW9uIGVudGl0aWVzIiAoZm9yIG5vdykNCltN Vl0gSSBjYW4ndCB1c2UgImFnZW50IiBiZWNhdXNlIHRoaXMgZW5jb2RpbmcgaXMgaW1wbGVtZW50 ZWQgYnkgYm90aCB0aGUgbWFuYWdlciAoY2xpZW50KSBhbmQgdGhlIGFnZW50IChzZXJ2ZXIpLg0K W01WXSBJIGFsc28gd2FudCB0byBzdGF5IGdlbmVyaWMgc2luY2UgdGhpcyBtYXBwaW5nIGlzIG5v dCBuZWNlc3NhcnkgcmVzdHJpY3RlZCBuZXR3b3JrIG1hbmFnZW1lbnQNCg0K4oCcVGhlIENvQVAg Y29udGVudC1Gb3JtYXQgT3B0aW9uIOKApi4gSW4gdGhlIGZpcnN0IHBsYWNlLuKAnSAgSSBkb27i gJl0IHVuZGVyc3RhbmQgdGhpcyBwaHJhc2UuDQoNCltNVl0gU2VudGVuY2UgcmVtb3ZlZA0KW01W XSBJIGFsc28gZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBpbnRlbnQgb2YgdGhpcyBzZW50ZW5jZSB3 aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkcmFmdC4NCg0KU2VjdGlvbiA0LjIgdGl0bGU6ICDi gJhjb250YWluZXLigJ0gU2NoZW1hIE5vZGUuIElzIOKAnENCT1IgbWFwIGtleeKAnSBub3QgYSBi ZXR0ZXIgdGl0bGU/DQoNCltNVl0gVGl0bGVzIG9mIHRoaXMgZHJhZnQgYXJlIGFsaWduZWQgd2l0 aCBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW5ldG1vZC15YW5nLWpzb24tMTAu dHh0IA0KW01WXSBJJ20gcmVuYW1pbmcgYWxsIHRpdGxlcyBvZiBzZWN0aW9uIDQgdG8gIkRhdGEg Tm9kZSIgdG8ga2VlcCB0aGlzIGFsaWdubWVudC4NCg0KQXMgc3VnZ2VzdGVkIGVhcmxpZXI6IFJl ZHVjZSB0aGlzIHRvIHN0cmluZyAobWFqb3IgdHlwZSAzKSBhbmQgbnVtYmVyIChtYWpvciB0eXBl IDApIGtleXMuDQoNCltNVl0gRG9uZQ0KDQpJIHRoaW5rIHRoYXQgYSBsYXJnZSBudW1iZXIgb2Yg dGhlIENCT1IgZW5jb2RpbmcgZXhhbXBsZXMgaW4gc2VjdGlvbiA0LjIgY2FuIGJlIGxlZnQgb3V0 Lg0KVGhleSBjYW4gYmUgZ2VuZXJhdGVkIGFueSB0aW1lIGJ5IGFuIGludGVyZXN0ZWQgaW1wbGVt ZW50ZXI7IGFuZCBub3cgY29uZnVzZSB0aGUgaXNzdWVzLg0KDQpbTVZdIEkgcmVjZWl2ZWQgbWFu eSBxdWVzdGlvbnMgYWJvdXQgdGhlIGZpbmFsIGVuY29kaW5nIGFuZCB0aGUgbnVtYmVyIG9mIGJ5 dGVzIHJlcXVpcmVkLg0KW01WXSBJZiBJIHJlbW92ZSB0aGVzZSBleGFtcGxlcywgSSdtIGNvbmNl cm4gdGhhdCBJIHdpbGwgcmVjZWl2ZSBldmVuIG1vcmUgb2YgdGhlc2UgcXVlc3Rpb25zLg0KW01W XSBJIGFncmVlIHRoYXQgdGhlc2UgZXhhbXBsZXMgYXJlIHVzZWxlc3MgZm9yIHBlb3BsZXMgd2l0 aCBhIGdvb2Qga25vd2xlZGdlIG9mIENCT1INCltNVl0gYnV0IHNlZW0gdmVyeSB3ZWxjb21lIGZy b20gbmV3Y29tZXJzLiANCg0KU2VjdGlvbiA0LjQ7IHRoZSBleGFtcGxlIGlzIHJlYWxseSBjb21w bGV4OyBzb21lIGV4cGxhbmF0aW9uIHdoYXQgdGhpcyBhbGwgaWxsdXN0cmF0ZXMgd291bGQgYmUg d2VsY29tZS4NCldoeSBpcyB0aGUgdXNlIG9mIGNob2ljZSBuZWNlc3NhcnkgdG8gdW5kZXJzdGFu ZCB0aGUgbGlzdCBlbmNvZGluZz8NCg0KW01WXSBJJ20gdHJ5aW5nIHRvIHVzZSByZWFsIGxpZmUg ZXhhbXBsZXMsIHRoZSBzZXJ2ZXIgbGlzdCBpcyB0aGUgc2ltcGxlc3QgZXhhbXBsZSBvZiBsaXN0 IEkgZm91bmQgaW4gYSBSRkMuDQpbTVZdIElmIEkgdXNlIGFuIHN1YnNldCBvZiB0aGUgbGlzdCwg SSBjYW4gcHJvYmFibHkgdXNlIHRoZSAiaW50ZXJmYWNlIiBsaXN0IGZyb20gUkZDIDcyMjMuDQpb TVZdIEEgc3VnZ2VzdGlvbiB3aWxsIGJlIHdlbGNvbWUuDQoNCkkgc3VnZ2VzdCB0byBmaXJzdCBw cmVzZW50IHRoZSBuYW1lcyBleGFtcGxlIGZvbGxvd2VkIGJ5IHRoZSBudW1iZXIgZXhhbXBsZS4N Cg0KW01WXSBTSURzIHNob3VsZCBiZSB0aGUgcHJldmFsZW50IG5hbWluZyB1c2VkIGJ5IHRoaXMg bWFwcGluZy4NCltNVl0gRm9yIHRoaXMgcmVhc29uLCBJIHByZWZlciB0byBzaG93IFNJRHMgZmly c3QuDQoNClNlY3Rpb24gNTogSSBuZWVkIG1vcmUgZXhwbGFuYXRpb24gdG8gcmVsYXRlIHRoZSBp bnN0YW5jZSBleGFtcGxlcyB0byB0aGUgdHlwZSBkZWZpbml0aW9ucy4NCkZvciBleGFtcGxlIHNl Y3Rpb24gNS4xOyBkb2VzIHRoZSAxMjgwIGNvbWUgZnJvbSB7bXR1OiAxMjgwfSA/DQpIZXJlIHdl IGRvIG5lZWQgdGhlIENCT1IgZW5jb2RpbmcgdG8gc2VlIHRoZSByZWxhdGlvbiBiZXR3ZWVuIHRo ZSB0eXBlIHNwZWNpZmljYXRpb24gYW5kIHRoZSBDQk9SIGVuY29kaW5nLg0KDQpbTVZdIEFkZGlu ZyBpcyBzZWN0aW9uIDUuMToNCltNVl0gVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHRoZSBl bmNvZGluZyBvZiBsZWFmICdtdHUnIHNldCB0byAxMjgwIGJ5dGVzLg0KW01WXSBBZGRpbmcgaXMg c2VjdGlvbiA1LjI6DQpbTVZdIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyB0aGUgZW5jb2Rp bmcgb2YgbGVhZiAnIHRpbWV6b25lLXV0Yy1vZmZzZXQnIHNldCB0byAtMzAwIG1pbnV0ZXMuDQpb TVZdIEFkZGluZyBpcyBzZWN0aW9uIDUuMzoNCltNVl0gVGhlIGZvbGxvd2luZyBleGFtcGxlIHNo b3dzIHRoZSBlbmNvZGluZyBvZiBsZWFmICdteS1kZWNpbWFsJyBzZXQgdG8gMi41NyBtaW51dGVz Lg0KW01WXSBBZGRpbmcgaXMgc2VjdGlvbiA1LjQ6DQpbTVZdIFRoZSBmb2xsb3dpbmcgZXhhbXBs ZSBzaG93cyB0aGUgZW5jb2Rpbmcgb2YgbGVhZiAnbmFtZScgc2V0IHRvICJldGgwIi4NCltNVl0g QWRkaW5nIGlzIHNlY3Rpb24gNS41Og0KW01WXSBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3Mg dGhlIGVuY29kaW5nIG9mIGxlYWYgJ2VuYWJsZWQnIHNldCB0byAndHJ1ZScuDQpbTVZdIEFkZGlu ZyBpcyBzZWN0aW9uIDUuNjoNCltNVl0gVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHRoZSBl bmNvZGluZyBvZiBsZWFmICdvcGVyLXN0YXR1cycgc2V0IHRvICd0ZXN0aW5nJy4NCltNVl0gQWRk aW5nIGlzIHNlY3Rpb24gNS43Og0KW01WXSBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhl IGVuY29kaW5nIG9mIGxlYWYgJ215Yml0cycgd2l0aCB0aGUgJ2Rpc2FibGUtbmFnbGUnIGFuZCAn MTAtTWItb25seScgc2V0Lg0KW01WXSBBZGRpbmcgaXMgc2VjdGlvbiA1Ljg6DQpbTVZdIFRoZSBm b2xsb3dpbmcgZXhhbXBsZSBzaG93cyB0aGUgZW5jb2Rpbmcgb2YgbGVhZiAnYWVzMTI4LWtleScg c2V0IHRvIHRoZSB2YWx1ZSAweDFmMWNlNmEzZjQyNjYwZDg4OGQ5MmE0ZDgwMzA0NzZlLg0KW01W XSBBZGRpbmcgaXMgc2VjdGlvbiA1Ljk6DQpbTVZdIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93 cyB0aGUgZW5jb2Rpbmcgb2YgbGVhZiAnaW50ZXJmYWNlLXN0YXRlLXJlZicgc2V0IHRvIHRoZSB2 YWx1ZSAiZXRoMSIuDQpbTVZdIEFkZGluZyBpcyBzZWN0aW9uIDUuMTA6DQpbTVZdIFRoZSBmb2xs b3dpbmcgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhlIGVuY29kaW5nIG9mIGxlYWYgJ3R5cGUn IHNldCB0byB0aGUgdmFsdWUgJ2V0aGVybmV0Q3NtYWNkJy4NCltNVl0gQWRkaW5nIGlzIHNlY3Rp b24gNS4xMToNCltNVl0gVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHRoZSBlbmNvZGluZyBv ZiBsZWFmICdpcy1yb3V0ZXInIHdoZW4gcHJlc2VudC4NCltNVl0gQWRkaW5nIGlzIHNlY3Rpb24g NS4xMjoNCltNVl0gVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHRoZSBlbmNvZGluZyBvZiBs ZWFmICdpcC1hZGRyZXNzJyB3aGVuIHNldCB0byAiMjAwMTpkYjg6YTBiOjEyZjA6OjEiLg0KW01W XSBBZGRpbmcgaXMgc2VjdGlvbiA1LjEzOg0KTW9yZSBhZGRlZCwgc2VlIGh0dHA6Ly9jb3JlLXdn LmdpdGh1Yi5pby95YW5nLWNib3IvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci1sYXRlc3QuaHRt bCBmb3IgZmluYWwgcmVzdWx0DQpTZWUgaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cveWFuZy1j Ym9yL2NvbW1pdC8yOGY1ZGFlMDRjMjBjMTM2NjdiNTc0OTU0MWYwMzZkM2RiZGI0YjQzI2RpZmYt MDgzZmQ1ZTcxZmZkNjNiMTJkOGNkMjg1NGMzYWQxYmYgZm9yIGEgZGlmZg0KDQpTZWN0aW9uIDUu MiBleGFtcGxlIGlsbHVzdHJhdGVzIG1ham9yIHR5cGUgMT8gTm90IGltbWVkaWF0ZWx5IGNsZWFy IHVubGVzcyB5b3UgZGVjb2RlIHRoZSBDQk9SLg0KDQpbTVZdIFNob3VsZCBJIGFkZCBtb3JlIHRl eHQgdGhhbiB0aGUgbm90ZSBhbHJlYWR5IGFkZGVkLiAoVGhpcyBleGFtcGxlIHNob3dzIHRoZSBl bmNvZGluZyBvZiBsZWFmICcgdGltZXpvbmUtdXRjLW9mZnNldCcgc2V0IHRvIC0zMDAgbWludXRl cy4pDQpbTVZdIElmIHNvLCBkbyB5b3UgaGF2ZSBhIHNlbnRlbmNlIHRvIHByb3Bvc2U/DQoNClNl Y3Rpb24gNS4zOyBTdGFydCBwaHJhc2UgZ290IGxvc3QgMyBsaW5lcyBsb3dlci4NCg0KW01WXSBG aXhlZA0KDQpJbiB0aGUgZXhhbXBsZSwgd2hlcmUgZG8gSSBmaW5kIGluIHRoZSBDQk9SIGVuY29k aW5nIHRoYXQgdGhlIGZyYWN0aW9uIGlzIDIgZGlnaXRzPw0KDQpbTVZdIFRoZSBudW1iZXIgb2Yg ZGlnaXRzIGlzIG5vdCBlbmNvZGVkLiBUaGlzIGluZm9ybWF0aW9uIGlzIGNvbnNpZGVyZWQgYW4g dW5uZWNlc3NhcnkgbWV0YWRhdGENCltNVl0gc2ltaWxhciB0byAidW5pdHMiLCB0ZXh0IG9mIGFu IGVudW1lcmF0aW9uLCBuYW1lIG9mIGEgZmxhZyB3aXRoaW4gYml0cy4gVGhpcyB3YXMgdGhlIGNv bnNlbnN1cw0KW01WXSBvZiB0aGUgZ3JvdXAgd2hpY2ggaXMgYWxpZ25lZCB3aXRoIHRoZSBzdGF0 ZW1lbnQgaW4gc2VjdGlvbiAzIChJbiBvcmRlciB0byBtaW5pbWl6ZSB0aGUgc2l6ZSBvZg0KW01W XSB0aGUgZW5jb2RlZCBkYXRhLCB0aGUgcHJvcG9zZWQgbWFwcGluZyBhdm9pZCBhbnkgdW5uZWNl c3NhcnkgbWV0YS1pbmZvcm1hdGlvbiBiZXlvbmQNCltNVl0gdGhvc2UgbmF0aXZlbHkgc3VwcG9y dGVkIGJ5IENCT1IuKQ0KW01WXSBJdCBtaWdodCBiZSB3b3J0aCBpdCB0byByYWlzZSB0aGlzIHRv cGljIHdpdGhpbiBhIGxhcmdlciBhdWRpZW5jZS4gDQoNClNlY3Rpb25zIDUuNCAtIDUuODsgc2Vl IGNvbW1lbnRzIG9uIHNlY3Rpb24gNS4xIFNlY3Rpb24gNS45IEhlcmUgbW9yZSB0ZXh0IGlzIG5l ZWRlZCB0byBjb25uZWN0IHRoZSBjb21wbGV4IFlBTkcgc3BlY2lmaWNhdGlvbiB0byDigJxldGgx 4oCdIHZhbHVlLg0KDQpbTVZdIERvbmUNCg0KU2VjdGlvbiA1LjEwOyB3aGF0IGlzIGEgbmFtZS1z cGFjZSBxdWFsaWZpZWQgZm9ybT8gSW4gWUFORy1KU09OIGl0IGlzIGRlZmluZWQgYnV0IG1heSBu ZWVkIHNvbWUgcmVwZXRpdGlvbiBoZXJlLg0KDQpbTVZdIEFkZGluZyAnbmFtZXNwYWNlLXF1YWxp ZmllZCcgaW4gdGhlIGxpc3Qgb2YgdGVybXMgbGlzdGVkIGluIHNlY3Rpb24gMi4NCltNVl0gQWRk aW5nICJOYW1lcyBhbmQgbmFtZXNwYWNlcyBhcmUgZGVmaW5lZCBpbiBbSS1ELmlldGYtbmV0bW9k LXlhbmctanNvbl0gc2VjdGlvbiA0LiIuDQoNCldoeSBpcyB0aGUgc3ViamVjdCBTSURzIGFzIGlk ZW50aXR5cmVmKiBzcGxpdCBpbiB0d28gcGFydHM/DQoNCltNVl0gVGhlIGludGVudCBpcyB0byBr ZWVwIHRoZSBuYW1lIGFuZCBTSUQgZXhhbXBsZSB0b2dldGhlci4NCltNVl0gUmVwbGFjaW5nIHRo ZSB0aXRsZSBpbiB0aGUgZXhhbXBsZSBzZWN0aW9uIHRvICJFbmNvZGluZyBleGFtcGxlIHVzaW5n IG5hbWUiLCAiRW5jb2RpbmcgZXhhbXBsZSB1c2luZyBTSUQiLA0KDQpBbmQgYWdhaW4gSSBmaW5k IHRoZSBDQk9SIGVuY29kaW5nIGRpZmZpY3VsdCB0byByZWxhdGUgdG8gdGhlIGRlZmluaXRpb24g ZXhhbXBsZS4NCg0KDQpTZWN0aW9uIDUuMTENCkNCT1IgZGlhZ25vc3RpYyBpczoge2lzcm91dGVy OiBbbnVsbF19ID8NCg0KW01WXSBZZXMsIGFuIGVtcHR5IGRhdGF0eXBlIGhhdmUgbm8gdmFsdWUN CltNVl0gV2hlbiBwcmVzZW50LCBpdCBpcyBzZXQgdG8gJ251bGwnLg0KW01WXSBkcmFmdC1pZXRm LW5ldG1vZC15YW5nLWpzb24tMTAgaW1wbGVtZW50cyB0aGUgc2FtZSBhcHByb2FjaC4NCg0KU2Vj dGlvbiA1LjEzLg0KSSBkb27igJl0IHVuZGVyc3RhbmQgaG93IHRoaXMgc2VjdGlvbiByZWxhdGVz IHRvIFlBTkcgdG8gQ0JPUiBtYXBwaW5nLiBJZiB0aGUgc2VjdGlvbiByZWZlcnMgdG8gc3BlY2lm eWluZyBhbiBpbnN0YW5jZSBpZGVudGlmaWVyIGluIHRoZSByZXF1ZXN0LCBJIHRoaW5rIGl0IGNh biBiZSByZW1vdmVkLiBUaGUgdXNlIG9mIFtrZXk9dmFsdWVdIGFzIGluc3RhbmNlIGlkZW50aWZp ZXIgaXMgd2VsbCBleHBsYWluZWQgaW4gcmVzdGNvbmYgZHJhZnQuIFRoZSB1c2Ugb2YgbnVtZXJp YyBpZGVudGlmaWVyIGlzIGN1cnJlbnRseSBkZXNjcmliZWQgaW4gQ29NSSBkcmFmdCwgYW5kIGRp ZmZlcmVudGx5IGluIENvT0wgZHJhZnQuIEkgcHJvcG9zZSB0byByZW1vdmUgdGhpcyBzZWN0aW9u IGFzIGl0IGRvZXMgbm90IGRpcmVjdGx5IHJlbGF0ZSB0byBDQk9SIGVuY29kaW5nLg0KDQpbTVZd IEFuIGluc3RhbmNlLWlkZW50aWZpZXIgaXMgYSBZQU5HIGRhdGF0eXBlIHdoaWNoIG5lZWQgdG8g YmUgc3VwcG9ydGVkLg0KW01WXSBTZWUgZXhhbXBsZSBsZWFmICdlcnJvci1wYXRoJyBpbiBodHRw Oi8vd3d3Lm5ldGNvbmZjZW50cmFsLm9yZy9tb2R1bGVyZXBvcnQvaWV0Zi1yZXN0Y29uZg0KW01W XSBXZSBzaW1wbHkgcmV1c2UgdGhpcyBZQU5HIGRhdGF0eXBlIGluIHRoZSBDb0FQIG1ldGhvZHMg dG8gbWluaW1pemUgb3ZlcmhhdWwgY29tcGxleGl0eS4NCg0KSG93ZXZlciwgSSBhbSBtaXNzaW5n IGhvdyB0byB0cmFuc3BvcnQgYSBnaXZlbiBsaXN0IGluc3RhbmNlIHdpdGggaXRzIGtleSB2YWx1 ZXMgaW4gdGhlIENCT1IgZW5jb2RpbmcuIFNlY3Rpb24gNC40IGRlc2NyaWJlcyB0aGUgZW5jb2Rp bmcgb2YgYSBjb21wbGV0ZSBsaXN0IG5vdCBhIHN1YnNldCBvZiBpdHMgaW5zdGFuY2VzLg0KDQpb TVZdIEEgbGlzdCBpbnN0YW5jZSBpcyBhIGNvbGxlY3Rpb24gd2hpY2ggaXMgZGVzY3JpYmVkIGlu IHNlY3Rpb24gNC4yLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpIb3Bl IHRoaXMgaGVscHMsDQpQZXRlcg0KDQoNCi0tDQpQZXRlciB2YW4gZGVyIFN0b2sNCnZhbmRlcnN0 b2sgY29uc3VsdGFuY3kNCm1haWx0bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmcNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGlu ZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUNCg== From nobody Fri Jul 8 16:14:08 2016 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 AEDA212D7EF; Fri, 8 Jul 2016 16:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708231359.32152.18300.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 16:13:59 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-yang-cbor-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:14:00 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Alexander Pelov Abhinav Somaraju Randy Turner Ana Minaburo Filename : draft-ietf-core-yang-cbor-02.txt Pages : 29 Date : 2016-07-08 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-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 Fri Jul 8 16:18:47 2016 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 9339812D984 for ; Fri, 8 Jul 2016 16:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 jPKvJoM4CYKY for ; Fri, 8 Jul 2016 16:18:43 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0132.outbound.protection.outlook.com [104.47.33.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC9012D97B for ; Fri, 8 Jul 2016 16:18:43 -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=orVUIefIxTD//KtIWHQRnhA1ACKp2aApLReHrfmRIWo=; b=Dcn/XJJfxXxEUhUUO1PMuCz24J/W6wafFlIgfJ2OH32vZsc2PFh6xHnk04xvZEhfxEUDUWSxmgVTMEcsCByMqB9CTTR5kyXCTHDbrtHOinx8mQN3uJoF0UVwNpyn+onjOcUPVqqn+pamGZvgigT5U6xUhtqFh5OY0GaBAXAq1v8= Received: from CY1PR0301MB1562.namprd03.prod.outlook.com (10.162.166.12) by CY1PR0301MB1562.namprd03.prod.outlook.com (10.162.166.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.528.16; Fri, 8 Jul 2016 23:18:41 +0000 Received: from CY1PR0301MB1562.namprd03.prod.outlook.com ([10.162.166.12]) by CY1PR0301MB1562.namprd03.prod.outlook.com ([10.162.166.12]) with mapi id 15.01.0528.024; Fri, 8 Jul 2016 23:18:41 +0000 From: Brian Raymor To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-03.txt Thread-Index: AQHR2WrZ4FcoQekMVEKDMoI5C9MBOqAPIw+g Date: Fri, 8 Jul 2016 23:18:41 +0000 Message-ID: References: <20160708224824.32172.32846.idtracker@ietfa.amsl.com> In-Reply-To: <20160708224824.32172.32846.idtracker@ietfa.amsl.com> 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=Brian.Raymor@microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 5817ed45-5f11-4721-3f19-08d3a7863323 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB1562; 6:3lYGI8QNPSDtigC+Lt6XZ+z9So3gEwQpyB5kOzj2E5G1r0O9oin9Elr+9roLxS89xsRV1Ohqinn+NA1/044vaBKdrMnpi0hW2RUST9PnIFtlLSmo4XQs0020ewJoish5qWPKRzqdkCvFN0fepsCPUZTzQrm64RDdHhRPz9Y4pJuhUNdTJuaxim+eSPQyczOY6p3kjkIUgqn+PT8ewW51RtjZ3gOSTxb+uo3BukrOkEBDJXDJT06F1ldMzOxtXrWCQJFP2is22vbIr76ijIBi+dbzvqG140AU/whQLQrfW/athxq3Z7SSvFmLZEdWz7xHk92jCM12Yv6lOARCVMtP3w==; 5:LgILVVIPtChT6eB8czGgVoWc4bNfLWzy6XB8NY6yNE8qS1A/fSkohXJk5qT+sXKm8FAZV3kPrDKCGkHpO77OGVvvoBwpWnfiA9MUqW24LPaTzO7G9qncv//RRYRSzHNbLz+pt8X09/iXhQ2ESLDb0w==; 24:LhkdgfVXHICYcVkrsIHgt9p2286IinBBkJMTvB0D/4iHwkEXvEyxn1mZcpRqLJbjoDpFWp3m8b6BTeZRs+G6aEowfEiafBW7U36ALhZDFLI=; 7:9Rr3/s/g2re27w519PoptILbQClxmOGK6bNaWmFTHtIaOG9c22nIRwGGVS/GQd7LhrgtEaaAnhtYlHYDqyrIC/tyjdVv8vtHml7W8XiBhw+GkPb1aT3cAuTRy29Moa3WRq1EGsy4tqiHztXCwFudRci0vrI3zKVjmlov0IEN93qjdSpHhY2yRK25jwvrVO56TsuBpF1xnZZOs8qRhLX5Ze+xDPmQBBQwQ6y0jwD1vwGNgMHmwyDfJwltI1pG1YJK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1562; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB1562; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB1562; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377424004)(189002)(377454003)(53434003)(199003)(110136002)(66066001)(189998001)(107886002)(81166006)(7696003)(7846002)(5003600100003)(7736002)(105586002)(586003)(81156014)(3660700001)(450100001)(15975445007)(2900100001)(2950100001)(77096005)(1730700003)(5002640100001)(87936001)(8676002)(19580395003)(305945005)(97736004)(19580405001)(3280700002)(101416001)(106116001)(76176999)(2906002)(92566002)(10090500001)(10290500002)(230783001)(106356001)(122556002)(99286002)(74316002)(76576001)(10400500002)(8990500004)(5005710100001)(33656002)(50986999)(86362001)(54356999)(6116002)(102836003)(9686002)(2501003)(3846002)(11100500001)(2351001)(8936002)(5640700001)(86612001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1562; H:CY1PR0301MB1562.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.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: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 23:18:41.3295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB1562 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 23:18:45 -0000 coap-tcp-tls-03 is the monster draft that consumed the related drafts: * draft-savolainen-core-coap-websockets-07 * draft-bormann-core-block-bert-01 * draft-bormann-core-coap-sig-02 Thanks to the chairs and authors who assisted in this process. Just a reminder that coap-tcp-tls has a github repo where you can easily vi= ew/open issues and pull requests:=20 https://github.com/core-wg/coap-tcp-tls/ https://github.com/core-wg/coap-tcp-tls/issues If you're new to github and need some pointers to get started, please reach= out to me.=20 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, July 8, 2016 3:48 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments of the IE= TF. Title : CoAP (Constrained Application Protocol) over TCP,= TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-03.txt Pages : 39 Date : 2016-07-08 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-tcp-tls-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sat Jul 9 00:26:30 2016 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 9ECAA12D0ED for ; Sat, 9 Jul 2016 00:26:29 -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 k9u4k3_xNwdt for ; Sat, 9 Jul 2016 00:26:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22F312B010 for ; Sat, 9 Jul 2016 00:26:27 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-93-5780a721cd41 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.73.12516.127A0875; Sat, 9 Jul 2016 09:26:25 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.78]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Sat, 9 Jul 2016 09:26:25 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1s?= =?utf-8?Q?inks-json?= Thread-Index: AQHR2bMz7Tbagpgj+0Ocj39VbJ2QKg== Date: Sat, 9 Jul 2016 07:26:25 +0000 Message-ID: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> 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: multipart/alternative; boundary="_000_4AA7AAD07BA74CCEA648476058DDDFB1ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7q67i8oZwg6+3lCz2vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFc7G5gLdgtU7Nhynr2B8R1/FyMnh4SAicT2dafYIWwxiQv3 1rN1MXJxCAkcYZS4s+onE4SziFFib9MfRpAqNgFniU/PGsE6RATUJFonvWIDsYUFMiUWPb/I DBHPk5jTu5oJwtaTuLv9GlicRUBF4tbi1WBzeAXsJS7fnwpWwwi0+fupNWA2s4C4xK0n85kg LhKQWLLnPDOELSrx8vE/VghbSWLR7c9ANRxA9ckS/x+VQ4wUlDg58wnLBEahWUgmzUKomoWk CiKsKbF+lz5EtaLElO6H7BC2hkTrnLlQtrXEx6bZLMhqFjByrGIULU4tLs5NNzLWSy3KTC4u zs/Ty0st2cQIjJODW37r7mBc/drxEKMAB6MSD6/Cq/pwIdbEsuLK3EOMEhzMSiK8f+c1hAvx piRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgnHks+UTqlgXZ jcLF/s1lC88bbzwf1rksxXfXsW6+dkaubrW8mWzVaxX7F079Iytz+vjdrVdEdXZPOvew29FG OPljRsObmqQ3qsLbc6wr77KHqc6okXcwPWD8e9MZS+HZH19edrnzZI9tYRw7w+dVVdvjDBZN j+FJaVX96tG5OO/US8tKIdsyJZbijERDLeai4kQAZK868I8CAAA= Archived-At: Subject: [core] =?utf-8?q?_=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-li?= =?utf-8?q?nks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jul 2016 07:26:29 -0000 --_000_4AA7AAD07BA74CCEA648476058DDDFB1ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGlzIGlzIHRoZSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgdGhlICJS ZXByZXNlbnRpbmcgQ29SRSBGb3JtYXRzIGluIEpTT04gYW5kIENCT1LigJ0gZG9jdW1lbnQuDQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWxpbmtzLWpzb24tMDYN Cg0KRHVlIHRvIHRoZSBJRVRGIG1lZXRpbmcsIHRoZSBjYWxsIGlzIHBsYW5uZWQgdG8gZW5kIHRo cmVlIHdlZWtzIGZyb20gbm93IGJ5IEp1bHkgMzB0aC4gSWYgcG9zc2libGUsIGNvbW1lbnRzIHNo b3VsZCBiZSBwcm92aWRlZCBlYXJseSBzbyB0aGF0IHdlIGNhbiBkaXNjdXNzIHRoaXMgZHVyaW5n IHRoZSBDb1JFIHNlc3Npb25zIG9uIElFVEY5Ni4NCg0KQlIsDQotIC0gSmFpbWUgSmltZW5leg0K DQo= --_000_4AA7AAD07BA74CCEA648476058DDDFB1ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <678177DDA2C0594AB9EE75B21958697B@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRoaXMgaXMgdGhlIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciB0 aGUgJnF1b3Q7UmVwcmVzZW50aW5nIENvUkUgRm9ybWF0cyBpbiBKU09OIGFuZCBDQk9S4oCdIGRv Y3VtZW50LjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNvcmUtbGlua3MtanNvbi0wNiIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1saW5rcy1qc29uLTA2PC9hPiZuYnNwOyZuYnNw OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkR1ZSB0byB0aGUgSUVURiBtZWV0aW5nLCB0 aGUgY2FsbCBpcyBwbGFubmVkIHRvIGVuZCB0aHJlZSB3ZWVrcyBmcm9tIG5vdyBieSBKdWx5IDMw dGguIElmIHBvc3NpYmxlLCBjb21tZW50cyBzaG91bGQgYmUgcHJvdmlkZWQgZWFybHkgc28gdGhh dCB3ZSBjYW4gZGlzY3VzcyB0aGlzIGR1cmluZyB0aGUgQ29SRSBzZXNzaW9ucyBvbiBJRVRGOTYu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQlIsPGJyIGNsYXNzPSIiPg0KLSAtIEphaW1l IEppbWVuZXo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4AA7AAD07BA74CCEA648476058DDDFB1ericssoncom_-- From nobody Sat Jul 9 00:54:59 2016 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 0B85512D0F3; Sat, 9 Jul 2016 00:54:57 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 4zEfPybwAdKW; Sat, 9 Jul 2016 00:54:54 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BD912D0A4; Sat, 9 Jul 2016 00:54:54 -0700 (PDT) Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id D57A641C086; Sat, 9 Jul 2016 09:54:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lh0dq0m288Ge; Sat, 9 Jul 2016 09:54:51 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id BF1A241C074; Sat, 9 Jul 2016 09:54:50 +0200 (CEST) Message-ID: <5780ADC8.6030900@tzi.org> Date: Sat, 09 Jul 2016 09:54:48 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" References: <577CF1BD.9050201@tzi.org> In-Reply-To: <577CF1BD.9050201@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core-chairs@ietf.org Subject: Re: [core] CoRE agenda @ietf96 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jul 2016 07:54:57 -0000 The agenda draft is now updated with what was actually submitted and at the official site: https://www.ietf.org/proceedings/96/agenda/agenda-96-core It is getting pretty compressed in the Thursday meeting. Much of the discussion, in particular in the last half hour, is about assessing documents with respect to readiness for last-call or WG adoption -- maybe we can have some discussion of these on the mailing list already so this compressed f2f form works in the time we have. Again, slot leaders, please check your time allocation and objectives, and send any updates to the list or to the chairs. Now, everybody, please use the time up to the meeting to read the drafts -- for your convenience, they are all properly linked from the agenda. Grüße, Carsten Carsten Bormann wrote: > Jaime and I have started preparing a draft agenda for the CoRE meetings > in Berlin. > > https://github.com/core-wg/ietf96/wiki > > (Please ignore for now the weird formatting issues github creates...) > > Those of you who put in a slot request: > Please check that it is covered by this draft agenda. > > We haven't written down the slot leaders ("presenters") everywhere, so > if you think you will be holding the microphone, please let Jaime and me > know (core-chairs@ietf.org). > > Please also check the objectives: Is this a reasonable summary of what > we are trying to achieve? > > Anything else we are missing? > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Mon Jul 11 00:06:11 2016 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 462C012B062 for ; Mon, 11 Jul 2016 00:06:10 -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 tZxBHIYsgUEi for ; Mon, 11 Jul 2016 00:06:08 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78E312B00A for ; Mon, 11 Jul 2016 00:06:07 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-8e-5783455c2fd1 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.67.18043.C5543875; Mon, 11 Jul 2016 09:06:04 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.78]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Mon, 11 Jul 2016 09:06:03 +0200 From: Oscar Novo To: 'Michael Koster' Thread-Topic: CoRE RD update in SVN repository Thread-Index: AQHR2KJ+MrRWLEJQxU+Evo2gdLYdH6AOE9tQgABlpACABFKpgA== Date: Mon, 11 Jul 2016 07:06:02 +0000 Message-ID: <70042F5265E5294E98CC25207D5E7EFF17B5E11F@ESESSMB307.ericsson.se> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> <6785197d8de0eb0c0e0cfc259913d07a@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D56A9@DEFTHW99EL4MSX.ww902.siemens.net> <1722A6E8-FFA7-4DA5-8831-D7B4584DFA97@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017D5971@DEFTHW99EL4MSX.ww902.siemens.net> <3ed1d21cb0ff090a71ea7f6f75a52658@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C017D71A8@DEFTHW99EL4MSX.ww902.siemens.net> <1DD58EF2-5C0D-4613-AC51-DA9C6A3AA275@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C017E08AD@DEFTHW99EL4MSX.ww902.siemens.net> <70042F5265E5294E98CC25207D5E7EFF17B5DD69@ESESSMB307.ericsson.se> <6E015256-34B8-45ED-8CD2-4F5FA77F1178@smartthings.com> In-Reply-To: <6E015256-34B8-45ED-8CD2-4F5FA77F1178@smartthings.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_70042F5265E5294E98CC25207D5E7EFF17B5E11FESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUyM2K7mW6Ma3O4wf4j8hZHptxltXi0fxWb xb6365ktrn8/wmJxc8YpJotnz1sYLRpfb2CxuHTtCbsDh8eaeWsYPZYs+cnkcfv1fGaPaUsf s3h8ufyZzWPaokyPEw3b2QPYo7hsUlJzMstSi/TtErgyXreeYyxYVVIxeeUnpgbGGYVdjBwc EgImEoeeJHUxcgKZYhIX7q1n62Lk4hASOMIoMXPNDxYIZzGjxI2NE5lAqtgEtCQ+33/BAmKL CJhKvLu5mRWkiFngPZPEiUuPwBLCAroSCzY8Y4Yo0pNYvGs1I4TtJLF6xyo2EJtFQFVi+vcj YDW8Ar4S/yZNYYLYdo9NYtvGbrBtnALOEv873oE1MwLd9/3UGrA4s4C4xK0n85kg7haQWLLn PDOELSrx8vE/VojXFCWW98tBlOdL/JnSxAixS1Di5MwnLBMYRWchmTQLSdksJGWzgCYxC2hK rN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgbF9 cMtvqx2MB587HmIU4GBU4uFNONoULsSaWFZcmXuIUYKDWUmEd6Z9c7gQb0piZVVqUX58UWlO avEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkGRhFpSZ9Zx+0nm67vui49vWqFWaL3 xTMl869u/7spW+f4+ojQpOfdbc+0dMyFEsPLpmyY49Ck+WCFlEpugsv9OerTRb88j/WNWFX7 TGn/o8eh2mdtT57x1y/rOPXyyXN9JraZwQvzfj7sOGUgeOpHV/kMUeE5Ou53rk1exczhaqPc EpHwZv7Sj0osxRmJhlrMRcWJAKh/BezpAgAA Archived-At: Cc: "draft-ietf-core-resource-directory@tools.ietf.org" , "core@ietf.org" , Hannes Tschofenig Subject: Re: [core] CoRE RD update in SVN repository X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 07:06:10 -0000 --_000_70042F5265E5294E98CC25207D5E7EFF17B5E11FESESSMB307erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KVGhhbmtzIGZvciB0aGUgYW5zd2VyLiBJIHRoaW5rIHRoZSBibG9ja3dp c2UgdHJhbnNmZXIgaW4gQ29BUCBtZXRob2QgaXMgYWxyZWFkeSB0YWtpbmcgY2FyZSBvZiBwcm9j ZXNzaW5nIGxhcmdlIHBheWxvYWRzIGFuZCBmcmFnbWVudGluZyBpdC4NCkkg4oCTc29tZWhvdy0g dW5kZXJzdGFuZCBzb21lIGNsaWVudHMgbWlnaHQgd2FudCB0byBsaW1pdCB0aGUgbnVtYmVyIG9m IGVudHJpZXMgaW4gYSBsb29rdXAgdG8gYSBjZXJ0YWluIG51bWJlci4gVGh1cywgdGhleSBjYW4g bGltaXQgdGhlIHByb2Nlc3NpbmcgdGltZSBvZiBhIGxvb2t1cOKAmXMgcmVzcG9uc2UuDQpIb3dl dmVyLCBJIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIHVzZSBvZiB0aGUgcGFnaW5hdGlv biBpZiB0aGUgYmxvY2t3aXNlIG1ldGhvZCBpcyBhbHJlYWR5IHNvbHZpbmcgaXQuIEluIGFkZGl0 aW9uLCBob3cgZG9lcyBhIGNsaWVudCBrbm93IGhvdyB0byBmcmFnbWVudCBhIHJlcXVlc3QgaWYg aXQgY2Fubm90IGtub3cgdGhlIG91dGNvbWUgb2YgYSByZXF1ZXN0PyBJbiBtYW55IGNhc2VzLCB0 aGUgQ29BUCBzZXJ2ZXIgd2lsbCBoYXZlIHRvIHVzZSBibG9ja3dpc2UgYW55d2F5IHRvIGZyYWdt ZW50IHNvbWUgb2YgdGhlIHBhZ2luYXRpb25zLiBJIGFtIG5vdCBzdXJlIGhvdyB0byBpbXBsZW1l bnQgaXQgb25jZSB5b3UgaGF2ZSBzZXZlcmFsIHBhZ2VzLiBIb3cgZG8geW91IGhhbmRsZSB0aGUg ZXJyb3JzIHVzaW5nIHRoaXMgbWV0aG9kPyBGb3IgaW5zdGFuY2UsIGlmIG9uZSBwYWdlIGlzIGxv c3QgaW4gdGhlIG5ldHdvcmsuIEFyZSB0aGUgcGFnZXMgc2VudCBpbiBzZXF1ZW5jZT8gSG93IGRv ZXMgdGhlIGNsaWVudCBrbm93IHRoZSBvcmRlciBvZiB0aGUgcGFnZXM/IEFyZSB0aGUgcGFnZXMg ZW51bWVyYXRlZD8gIEhvdyBkb2VzIHRoZSBjbGllbnQgaW5mb3JtIHRoZSBzZXJ2ZXIgdGhhdCBh IHBhZ2UgaGFzIGJlZW4gc3VjY2Vzc2Z1bCBzZW50PyBJIHRoaW5rIHRoZXJlIGFyZSBtYW55IGlz c3VlcyB1bnNvbHZlZCB1c2luZyB0aGlzIG1ldGhvZC4gSXNzdWVzIHRoYXQgYXJlIGFscmVhZHkg c29sdmUgaW4gdGhlIGJsb2Nrd2lzZSBtZXRob2QuDQoNCkkgd291bGQgcmF0aGVyIHJlbW92ZSB0 aGUgUGFnZSBwYXJhbWV0ZXIgYW5kIHVzZSB0aGUgQ291bnQgcGFyYW1ldGVyIGFzIHRoZSBtYXhp bXVtIG51bWJlciBvZiBlbnRyaWVzIGluIGEgbG9va3VwIHJlc3BvbnNlLiBXb3VsZCB0aGF0IG1h a2Ugc2Vuc2U/DQoNCk9zY2FyDQoNCkZyb206IE1pY2hhZWwgS29zdGVyIFttYWlsdG86bWljaGFl bC5rb3N0ZXJAc21hcnR0aGluZ3MuY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDA4LCAyMDE2IDU6 MzcgUE0NClRvOiBPc2NhciBOb3ZvDQpDYzogZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVj dG9yeUB0b29scy5pZXRmLm9yZzsgY29yZUBpZXRmLm9yZzsgY29uc3VsdGFuY3lAdmFuZGVyc3Rv ay5vcmc7IEtvdmF0c2NoIE1hdHRoaWFzOyBIYW5uZXMgVHNjaG9mZW5pZzsgWmFjaCBTaGVsYnk7 IENhcnN0ZW4gQm9ybWFubg0KU3ViamVjdDogUmU6IENvUkUgUkQgdXBkYXRlIGluIFNWTiByZXBv c2l0b3J5DQoNClRoaXMgaXMgaW1wb3J0YW50IGZvciBjbGllbnRzIHRoYXQgY2FuIG5vdCBwcm9j ZXNzIGxhcmdlIHBheWxvYWRzLCB0byBiZSBhYmxlIHRwIHBhZ2luYXRlIHRoZSBvdXRwdXQuDQoN Ckl0IGlzIG1lYW50IHRvIHdvcmsgbGlrZSB0aGUgY29tbW9uID9zdGFydD0yMSZjb3VudD0xMCB1 c2VkIGZvciB3ZWIgcGFnZXMuDQoNCkkgZG9uJ3Qga25vdyB3aHkgInBhZ2UiIGFuZCBub3QgInN0 YXJ0Ii4NCg0KSSBjb3VsZCBhZGQgc29tZSB0ZXh0IGFuZCBhbiBleGFtcGxlLg0KDQpNaWNoYWVs DQoNCk9uIEp1bCA3LCAyMDE2LCBhdCAxMTo0MiBQTSwgT3NjYXIgTm92byA8b3NjYXIubm92b0Bl cmljc3Nvbi5jb208bWFpbHRvOm9zY2FyLm5vdm9AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCiAg ICAgICAgIEkgcHJvdmlkZWQgeW91IHNvbWUgY29tbWVudCBhYm91dCBQYWdlIGFuZCBjb3VudCBp biB0aGUgbG9va3VwIHNvbWUgdGltZSBhZ28uIEkgdGhpbmsgdGhvc2UgdHdvIGVsZW1lbnRzIGFy ZSBleHRyZW1lbHkgdW5jbGVhciBhbmQgbmVlZCB0byBiZSBleHBsYWluZWQgYmV0dGVyIG9yIHJl bW92ZWQuDQrigKIgICAgICAgICBXaGF0IGRvZXMgdGhlIGN0OjQwIG1lYW5zIGluIHRoZSBmb2xs b3dpbmcgZXhhbXBsZT8NCg0KDQo= --_000_70042F5265E5294E98CC25207D5E7EFF17B5E11FESESSMB307erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBNaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgYW5z d2VyLiBJIHRoaW5rIHRoZSBibG9ja3dpc2UgdHJhbnNmZXIgaW4gQ29BUCBtZXRob2QgaXMgYWxy ZWFkeSB0YWtpbmcgY2FyZSBvZiBwcm9jZXNzaW5nIGxhcmdlIHBheWxvYWRzIGFuZCBmcmFnbWVu dGluZyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSDigJNzb21laG93LSB1bmRl cnN0YW5kIHNvbWUgY2xpZW50cyBtaWdodCB3YW50IHRvIGxpbWl0IHRoZSBudW1iZXIgb2YgZW50 cmllcyBpbiBhIGxvb2t1cCB0byBhIGNlcnRhaW4gbnVtYmVyLiBUaHVzLCB0aGV5IGNhbiBsaW1p dCB0aGUgcHJvY2Vzc2luZyB0aW1lIG9mIGENCiBsb29rdXDigJlzIHJlc3BvbnNlLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgSSBkb27igJl0IHJlYWxseSB1bmRlcnN0 YW5kIHRoZSB1c2Ugb2YgdGhlIHBhZ2luYXRpb24gaWYgdGhlIGJsb2Nrd2lzZSBtZXRob2QgaXMg YWxyZWFkeSBzb2x2aW5nIGl0LiBJbiBhZGRpdGlvbiwgaG93IGRvZXMgYSBjbGllbnQga25vdyBo b3cgdG8gZnJhZ21lbnQNCiBhIHJlcXVlc3QgaWYgaXQgY2Fubm90IGtub3cgdGhlIG91dGNvbWUg b2YgYSByZXF1ZXN0PyBJbiBtYW55IGNhc2VzLCB0aGUgQ29BUCBzZXJ2ZXIgd2lsbCBoYXZlIHRv IHVzZSBibG9ja3dpc2UgYW55d2F5IHRvIGZyYWdtZW50IHNvbWUgb2YgdGhlIHBhZ2luYXRpb25z LiBJIGFtIG5vdCBzdXJlIGhvdyB0byBpbXBsZW1lbnQgaXQgb25jZSB5b3UgaGF2ZSBzZXZlcmFs IHBhZ2VzLiBIb3cgZG8geW91IGhhbmRsZSB0aGUgZXJyb3JzIHVzaW5nIHRoaXMNCiBtZXRob2Q/ IEZvciBpbnN0YW5jZSwgaWYgb25lIHBhZ2UgaXMgbG9zdCBpbiB0aGUgbmV0d29yay4gQXJlIHRo ZSBwYWdlcyBzZW50IGluIHNlcXVlbmNlPyBIb3cgZG9lcyB0aGUgY2xpZW50IGtub3cgdGhlIG9y ZGVyIG9mIHRoZSBwYWdlcz8gQXJlIHRoZSBwYWdlcyBlbnVtZXJhdGVkPyAmbmJzcDtIb3cgZG9l cyB0aGUgY2xpZW50IGluZm9ybSB0aGUgc2VydmVyIHRoYXQgYSBwYWdlIGhhcyBiZWVuIHN1Y2Nl c3NmdWwgc2VudD8gSSB0aGluayB0aGVyZQ0KIGFyZSBtYW55IGlzc3VlcyB1bnNvbHZlZCB1c2lu ZyB0aGlzIG1ldGhvZC4gSXNzdWVzIHRoYXQgYXJlIGFscmVhZHkgc29sdmUgaW4gdGhlIGJsb2Nr d2lzZSBtZXRob2QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgcmF0aGVyIHJlbW92ZSB0aGUNCjx1PlBh Z2U8L3U+IHBhcmFtZXRlciBhbmQgdXNlIHRoZSA8dT5Db3VudDwvdT4gcGFyYW1ldGVyIGFzIHRo ZSBtYXhpbXVtIG51bWJlciBvZiBlbnRyaWVzIGluIGEgbG9va3VwIHJlc3BvbnNlLiBXb3VsZCB0 aGF0IG1ha2Ugc2Vuc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Pc2NhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNaWNoYWVsIEtvc3RlciBbbWFpbHRvOm1pY2hhZWwua29zdGVy QHNtYXJ0dGhpbmdzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMDgsIDIw MTYgNTozNyBQTTxicj4NCjxiPlRvOjwvYj4gT3NjYXIgTm92bzxicj4NCjxiPkNjOjwvYj4gZHJh ZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeUB0b29scy5pZXRmLm9yZzsgY29yZUBpZXRm Lm9yZzsgY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7IEtvdmF0c2NoIE1hdHRoaWFzOyBIYW5u ZXMgVHNjaG9mZW5pZzsgWmFjaCBTaGVsYnk7IENhcnN0ZW4gQm9ybWFubjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogQ29SRSBSRCB1cGRhdGUgaW4gU1ZOIHJlcG9zaXRvcnk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoaXMgaXMgaW1wb3J0YW50IGZvciBjbGllbnRz IHRoYXQgY2FuIG5vdCBwcm9jZXNzIGxhcmdlIHBheWxvYWRzLCB0byBiZSBhYmxlIHRwIHBhZ2lu YXRlIHRoZSBvdXRwdXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkl0 IGlzIG1lYW50IHRvIHdvcmsgbGlrZSB0aGUgY29tbW9uID9zdGFydD0yMSZhbXA7Y291bnQ9MTAg dXNlZCBmb3Igd2ViIHBhZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPkkgZG9uJ3Qga25vdyB3aHkgJnF1b3Q7cGFnZSZxdW90OyBhbmQgbm90ICZxdW90 O3N0YXJ0JnF1b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPkkgY291bGQgYWRkIHNvbWUgdGV4dCBhbmQgYW4gZXhhbXBsZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5NaWNoYWVsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIEp1 bCA3LCAyMDE2LCBhdCAxMTo0MiBQTSwgT3NjYXIgTm92byAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9z Y2FyLm5vdm9AZXJpY3Nzb24uY29tIj5vc2Nhci5ub3ZvQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50 Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHByb3ZpZGVkDQogeW91IHNvbWUgY29tbWVu dCBhYm91dDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 dT5QYWdlIGFuZCBjb3VudDwvdT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+aW4gdGhlIGxvb2t1cCBzb21lIHRpbWUgYWdvLiBJIHRoaW5rIHRob3NlIHR3 byBlbGVtZW50cyBhcmUgZXh0cmVtZWx5IHVuY2xlYXIgYW5kIG5lZWQgdG8gYmUgZXhwbGFpbmVk IGJldHRlciBvciByZW1vdmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sO2NvbG9yOiMxRjQ5N0QiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hhdA0KIGRv ZXMgdGhlIGN0OjQwIG1lYW5zIGluIHRoZSBmb2xsb3dpbmcgZXhhbXBsZT88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_70042F5265E5294E98CC25207D5E7EFF17B5E11FESESSMB307erics_-- From nobody Mon Jul 11 07:11:20 2016 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 051EA12D1D1 for ; Mon, 11 Jul 2016 07:11: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.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 AsYLEEkWz7X1 for ; Mon, 11 Jul 2016 07:11:08 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 C8D3512D1E6 for ; Mon, 11 Jul 2016 07:10:57 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id x130so13033031vkc.0 for ; Mon, 11 Jul 2016 07:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QS4EREFz5/WfsO/U1t8+/FgVFED/xp7xq5VoJYxTZk0=; b=mZodHUpom5r8g/+g8r88cel1cpjrZx+zxUz3Xg1OpmFUnlhNW0Qv+E05gkUsd2nieY boUDL7mx4cW5/5ON55wLGIwMUFxP1QPOu09A78sEybxpigBSneFW5ok4hmC2kRc/XW9G X+lyFU9/JBWQDk3De2uJ9wTzZ3wrcmL+atw8DhB1WbfS831h5twa4kmaYf7eVOW55YCk uh5Ug+jULuHf+hOnEB0l+BphhqPc/L6j6ixCWXxG3X0xRqiS5Uc11pJtPQ3UZ+qq0J1j IE0Oo3KofsBBoRNfWQwafR0EI955H7Zu8vETSSprqV23B1i8DONjPs+RnAx/0nD6Qfii liaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QS4EREFz5/WfsO/U1t8+/FgVFED/xp7xq5VoJYxTZk0=; b=Ts0x5waY1CTBFZkP6CYiHhlRYhi17ONXO72ExbHUn/l7JgIEoxUmQrHeMZFACKm5fi 2eFEnAaNslvjGQt74WAj26RIHbwiar4Fv7CxoWH6t3PZxssmdAsvdT/zozJcarRt0+rS H63h26KiBCPl4eg2hIFVSk0Ndr2NvCX/7hRA8Xc/6eOe+bzCUG6CSSEfHDJCGBLPeuZV rcx2zPdu93rpIWkxNlZLhft4CChl+HIwr4viWSMtoMQpwbO4nKZdErn+wE1PGxsMNv/2 XCaD5+BgUbuKEnLiutnHTFmcWtVE0jkW5DuhSGJidpEsdfdc2o18jSfBaFpAvMW0DbdP 3kTg== X-Gm-Message-State: ALyK8tJSgt3PtZYEJGXZKTCWj8Kr2QPgzESQCw4p+FdW5atsAdOJYj7CRdQHmvkh73+4khgo1NMqn1WsiL3TG6Xh X-Received: by 10.159.33.5 with SMTP id 5mr707485uab.36.1468246256671; Mon, 11 Jul 2016 07:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.87.74 with HTTP; Mon, 11 Jul 2016 07:10:56 -0700 (PDT) In-Reply-To: References: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> From: Marco Tiloca Date: Mon, 11 Jul 2016 16:10:56 +0200 Message-ID: To: Francesca Palombini Content-Type: multipart/alternative; boundary=94eb2c0b60c49284bf05375cb859 Archived-At: Cc: "Ace@ietf.org" , "core@ietf.org" , "cose@ietf.org" Subject: Re: [core] [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 14:11:10 -0000 --94eb2c0b60c49284bf05375cb859 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Francesca and all, I have reviewed this last version and I believe it is in a very good shape! Please, find below some suggestions for minor changes/updates. Best regards, /Marco ---------------------------- 1) In Section 2, I would refer the usage of a COSE object as soon as possible, rather than at the end of page 5 where you describe how to prepare the protected CoAP message. For instance, the very first sentence in Section 2 can be followed by something like: "This is achieved by means of a COSE object included in the protected CoAP message, as detailed below"= . 2) In Section 2 (page 5), I would move the sentence "An endpoint receiving [...] treat it as malformed and reject it." at the end of the first element of the bullet list below, since it concerns CoAP messages with payload. 3) Following the same reasoning of point 2), I would extend the second element in the dotted list at the end of page 5 with: "An endpoint receiving a CoAP message without payload, that also contains an empty Object-Security option SHALL treat it as malformed and reject it". 4) Section 3.1, page 6, "The endpoint verifies the message received" --> "The endpoint verifies the messages received". 5) Section 5, page 13, add "(see Section 5.1)" after "is computed from the Plaintext", and "(see Section 5.2)" after "and the Additional Authenticated Data (AAD)". 6) Section 6.2, page 16, step 1. In the last sentences about renewing the security context on the client, it would be good to mention also that this involves informing the server, so that it can update its own Receiver-* parameters on its own context. 7) Section 6.2, page 16, step 2. "Store the MAC of each fragment" --> "Store the MAC of each last-sent fragment". 8) Section 6.3, page 17, step 2. "Store the MAC of each fragment" --> "Store the MAC of each last-received fragment". 9) Section 6.4, page 18, step 1. In the last sentences about renewing the security context on the server, it would be good to mention also that this involves informing the client, so that it can update its own Receiver-* parameters on its own context. 10) Section 6.4, page 18, step 2. "Store the MAC of each fragment" --> "Store the MAC of each last-sent fragment". 11) Section 6.5, page 19, step 2. "Store the MAC of each fragment" --> "Store the MAC of each last-received fragment". 12) Section 6.5, page 20, first paragraph. After the last sentence "DTLS and OSCOAP can be combined", I would restate what said in Section 1 (page 4), that is "thereby enabling end-to-end ..." 13) Section 6.5, page 20, third paragraph. "The use of COSE to protected CoAP messages" --> "The use of COSE to protect CoAP messages" On Fri, Jul 8, 2016 at 9:03 AM, Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Dear CoRE, COSE and ACE members, > > We have submitted an update to the OSCOAP draft: > https://tools.ietf.org/html/draft-selander-ace-object-security-05 > > For those who don=E2=80=99t know, OSCOAP is an application layer security= protocol > for CoAP, based on wrapping request and response messages in COSE objects > which are sent in a CoAP message exchange. > > With this version, we aimed for improved readability and we added the > blockwise functionality, as discussed during last f2f meeting. > > We are now looking for reviews. Any comment or feedback would be greatly > appreciated! > > Best regards, > Francesca > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: den 7 juli 2016 18:37 > To: G=C3=B6ran Selander ; Ludwig Seitz < > ludwig@sics.se>; John Mattsson ; G=C3=B6ran > Selander ; Francesca Palombini < > francesca.palombini@ericsson.com> > Subject: New Version Notification for > draft-selander-ace-object-security-05.txt > > > A new version of I-D, draft-selander-ace-object-security-05.txt > has been successfully submitted by Francesca Palombini and posted to the > IETF repository. > > Name: draft-selander-ace-object-security > Revision: 05 > Title: Object Security of CoAP (OSCOAP) > Document date: 2016-07-07 > Group: Individual Submission > Pages: 36 > URL: > https://www.ietf.org/internet-drafts/draft-selander-ace-object-security-0= 5.txt > Status: > https://datatracker.ietf.org/doc/draft-selander-ace-object-security/ > Htmlized: > https://tools.ietf.org/html/draft-selander-ace-object-security-05 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-selander-ace-object-security-05 > > Abstract: > This memo defines Object Security of CoAP (OSCOAP), a method for > application layer protection of message exchanges with the > Constrained Application Protocol (CoAP), using the CBOR Object > Signing and Encryption (COSE) format. OSCOAP provides end-to-end > encryption, integrity and replay protection to CoAP payload, options, > and header fields, as well as a secure binding between CoAP request > and response messages. The use of OSCOAP is signaled with the CoAP > option Object-Security, also defined in this memo. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --94eb2c0b60c49284bf05375cb859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Francesca and all,

I have reviewed this last = version and I believe it is in a very good shape!

Please, find below= some suggestions for minor changes/updates.

Best regards,
/Marco=

----------------------------

1) In Section 2, I would refer = the usage of a COSE object as soon as possible, rather than at the end of p= age 5 where you describe how to prepare the protected CoAP message. For ins= tance, the very first sentence in Section 2 can be followed by something li= ke: "This is achieved by means of a COSE object included in the protec= ted CoAP message, as detailed below".

2) In Section 2 (page 5),= I would move the sentence "An endpoint receiving [...] treat it as ma= lformed and reject it." at the end of the first element of the bullet = list below, since it concerns CoAP messages with payload.

3) Followi= ng the same reasoning of point 2), I would extend the second element in the= dotted list at the end of page 5 with: "An endpoint receiving a CoAP = message without payload, that also contains an empty Object-Security option= SHALL treat it as malformed and reject it".

4) Section 3.1, pa= ge 6, "The endpoint verifies the message received" --> "T= he endpoint verifies the messages received".

5) Section 5, page= 13, add "(see Section 5.1)" after "is computed from the Pla= intext", and "(see Section 5.2)" after "and the Additio= nal Authenticated Data (AAD)".

6) Section 6.2, page 16, step 1.= In the last sentences about renewing the security context on the client, i= t would be good to mention also that this involves informing the server, so= that it can update its own Receiver-* parameters on its own context.
7) Section 6.2, page 16, step 2. "Store the MAC of each fragment&quo= t; --> "Store the MAC of each last-sent fragment".

8) S= ection 6.3, page 17, step 2. "Store the MAC of each fragment" --&= gt; "Store the MAC of each last-received fragment".

9) Sec= tion 6.4, page 18, step 1. In the last sentences about renewing the securit= y context on the server, it would be good to mention also that this involve= s informing the client, so that it can update its own Receiver-* parameters= on its own context.

10) Section 6.4, page 18, step 2. "Store t= he MAC of each fragment" --> "Store the MAC of each last-sent = fragment".

11) Section 6.5, page 19, step 2. "Store the MA= C of each fragment" --> "Store the MAC of each last-received f= ragment".

12) Section 6.5, page 20, first paragraph. After the = last sentence "DTLS and OSCOAP can be combined", I would restate = what said in Section 1 (page 4), that is "thereby enabling end-to-end = ..."

13) Section 6.5, page 20, third paragraph. "The use o= f COSE to protected CoAP messages" --> "The use of COSE to pro= tect CoAP messages"

On Fri, Jul 8, 2016 at 9:03 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:
Dear CoRE, COSE and ACE members,

We have submitted an update to the OSCOAP draft:
https://tools.ietf.org/html/draft-s= elander-ace-object-security-05

For those who don=E2=80=99t know, OSCOAP is an application layer security p= rotocol for CoAP, based on wrapping request and response messages in COSE o= bjects which are sent in a CoAP message exchange.

With this version, we aimed for improved readability and we added the block= wise functionality, as discussed during last f2f meeting.

We are now looking for reviews. Any comment or feedback would be greatly ap= preciated!

Best regards,
Francesca

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: den 7 juli 2016 18:37
To: G=C3=B6ran Selander <= goran.selander@ericsson.com>; Ludwig Seitz <ludwig@sics.se>; John Mattsson <john.mattsson@ericsson.com>; G=C3=B6ran Se= lander <goran.selander@er= icsson.com>; Francesca Palombini <francesca.palombini@ericsson.com>
Subject: New Version Notification for draft-selander-ace-object-security-05= .txt


A new version of I-D, draft-selander-ace-object-security-05.txt
has been successfully submitted by Francesca Palombini and posted to the IE= TF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-selander-ace-object-sec= urity
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Object Security of CoAP (OSCOAP) Document date:=C2=A0 2016-07-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 36
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-selander= -ace-object-security-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-selander-ace-object-securit= y/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-selander-ace-object-security-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-selander-ace-o= bject-security-05

Abstract:
=C2=A0 =C2=A0This memo defines Object Security of CoAP (OSCOAP), a method f= or
=C2=A0 =C2=A0application layer protection of message exchanges with the
=C2=A0 =C2=A0Constrained Application Protocol (CoAP), using the CBOR Object=
=C2=A0 =C2=A0Signing and Encryption (COSE) format.=C2=A0 OSCOAP provides en= d-to-end
=C2=A0 =C2=A0encryption, integrity and replay protection to CoAP payload, o= ptions,
=C2=A0 =C2=A0and header fields, as well as a secure binding between CoAP re= quest
=C2=A0 =C2=A0and response messages.=C2=A0 The use of OSCOAP is signaled wit= h the CoAP
=C2=A0 =C2=A0option Object-Security, also defined in this memo.




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

The IETF Secretariat

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

--94eb2c0b60c49284bf05375cb859-- From nobody Mon Jul 11 08:16:43 2016 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 A476F12D1C1; Mon, 11 Jul 2016 08:16:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160711151636.9432.75868.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2016 08:16:36 -0700 Archived-At: Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-block@ietf.org, rfc-editor@rfc-editor.org Subject: [core] Protocol Action: 'Block-wise transfers in CoAP' to Proposed Standard (draft-ietf-core-block-21.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:16:36 -0000 The IESG has approved the following document: - 'Block-wise transfers in CoAP' (draft-ietf-core-block-21.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ Technical Summary This specification extends the CoAP protocol (RFC 7252) with a pair of "Block" options to enable the transport of large payloads through multiple request-response pairs. In constrained environments, these blockwise transfers have an advantage over fragmentation at lower layers (e.g., IP), since the server can be truly stateless with no need for a connection setup or other server-side memory of previous block transfers. The specification is intended for standards-track, as it is a widely implemented extension of a standards-track protocol. Review and Consensus The specification was developed along with the base CoAP specification and received significant review by active WG members and implementers. Two major discussions were had and resolved while finding consensus. Several implementations of this final version have completed an interoperability test event with a very good score. Further implementer feedback also was positive. Personnel Matthias Kovatsch is the document shepherd. Alexey Melnikov is the responsible Area Director. From nobody Tue Jul 12 00:51:55 2016 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 3934112D744; Tue, 12 Jul 2016 00:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 2tcsIQnHYTS6; Tue, 12 Jul 2016 00:51:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EBCAE12D73D; Tue, 12 Jul 2016 00:51:52 -0700 (PDT) Received: from localhost ([::1]:57569 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bMsTv-0005Ey-5i; Tue, 12 Jul 2016 00:51:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-senml@ietf.org, ari.keranen@ericsson.com X-Trac-Project: core Date: Tue, 12 Jul 2016 07:51:51 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/407#comment:1 Message-ID: <079.c075336b651bf980ac1519bf22addff9@trac.tools.ietf.org> References: <064.66056f64a3dd3faf69992ec5f1eba532@trac.tools.ietf.org> X-Trac-Ticket-ID: 407 In-Reply-To: <064.66056f64a3dd3faf69992ec5f1eba532@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-senml@ietf.org, ari.keranen@ericsson.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-senml@ietf.org Resent-Message-Id: <20160712075152.EBCAE12D73D@ietfa.amsl.com> Resent-Date: Tue, 12 Jul 2016 00:51:52 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #407 (senml): SenML extensions and label registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 07:51:54 -0000 #407: SenML extensions and label registry Changes (by ari.keranen@ericsson.com): * status: new => closed * resolution: => fixed Comment: The SenML label registry is now defined in Section 11.2 Section 4 now describes the structure and how to extend that. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core- ari.keranen@ericsson.com | senml@ietf.org Type: task | Status: closed Priority: major | Milestone: Component: senml | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Tue Jul 12 00:57:14 2016 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 2F13312D757 for ; Tue, 12 Jul 2016 00:57:13 -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 PXBJpA9bZBdR for ; Tue, 12 Jul 2016 00:57:11 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378C112B062 for ; Tue, 12 Jul 2016 00:57:10 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-6b-5784a2d4cddf Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.DE.27088.4D2A4875; Tue, 12 Jul 2016 09:57:08 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.140]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0294.000; Tue, 12 Jul 2016 09:57:07 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] I-D Action: draft-ietf-core-senml-02.txt Thread-Index: AQHR2Tx9t7YoOFnGK0CjsIRAVKc5pKAUUfkA Date: Tue, 12 Jul 2016 07:57:07 +0000 Message-ID: <83531477-4BC5-4F9B-A975-46E91988C51A@ericsson.com> References: <20160708171607.32042.80416.idtracker@ietfa.amsl.com> In-Reply-To: <20160708171607.32042.80416.idtracker@ietfa.amsl.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbFdS/fKopZwg2sPpS32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEMTJ7EVzBOqWDRrKlMD40feLkZODgkBE4kvLztZIWwxiQv3 1rN1MXJxCAkcYZSY/6qZFcJZwijx6e02RpAqNgF7iclrPoLZIgISEp1f97OD2MICNhKPXs1j hYjbSkyfvp+li5EDyDaSuLY6ByTMIqAq0XNhLQuIzQs05uTrdWwgtpCAo8SFmweZQGxOASeJ tq2bwUYyAh30/dQasDizgLjErSfzmSAOFZBYsuc8M4QtKvHy8T+oB5Qk1h7ezgJRrydxY+oU NgjbWuLLu7WMELa2xLKFr5khbhCUODnzCcsERrFZSFbMQtI+C0n7LCTts5C0L2BkXcUoWpxa nJSbbmSkl1qUmVxcnJ+nl5dasokRGEMHt/w22MH48rnjIUYBDkYlHt4F95rDhVgTy4orcw8x SnAwK4nw6sxoCRfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUgtQgmy8TB KdXAaNRz8Rr/XDM5lXCRcyLXuM4Lfb4rN2XVgdMyq28d+ejzsDRL0u7qmQM/HhumbP09kZ39 0cKY/gVbFoV7r8lR+9WbZDQp5F2aQwyrjKZ9+Ka0BUdKzs29o7F0o9mZjBenVswzlmeoMPGo zRNl/hsvuLX2s1pjxYf1xcUHhXvfdf93q5HPUl30RomlOCPRUIu5qDgRAGSbMQCdAgAA Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 07:57:13 -0000 Hi all, Note that we updated the draft twice before the DL so the diff from the pre= vious version does not contain all the recent updates. It is better to use = the diff from -00 version: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-senml-00&url2=3Ddraft-i= etf-core-senml-02 Cheers, Ari > On 08 Jul 2016, at 20:16, Internet-Drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments of the = IETF. >=20 > Title : Media Types for Sensor Markup Language (SenML) > Authors : Cullen Jennings > Zach Shelby > Jari Arkko > Ari Keranen > Carsten Bormann > Filename : draft-ietf-core-senml-02.txt > Pages : 32 > Date : 2016-07-08 >=20 > Abstract: > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Markup Language > (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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-core-senml-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 12 01:15:10 2016 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 48C8F12B013; Tue, 12 Jul 2016 01:15:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 CMaZQo8SEJyS; Tue, 12 Jul 2016 01:15:01 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEF512B00C; Tue, 12 Jul 2016 01:15:00 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-68-5784a702c8d3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.55.12516.207A4875; Tue, 12 Jul 2016 10:14:58 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 12 Jul 2016 10:14:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uLQEgfqFVM+1kaTEGx3cpqqwhsNihCfnxA7qfhzq7xQ=; b=h8Cc7w8lzMtLvCCnFpU62+bqOt3KOu1AhHl6HXsDcu8sYpq2bPrVaS/yZaHrCBaKwcWraz/srPPUrqE3c11bpwQZelzzjwZUVTwAVo67f9wav7x5woBJDiy5k87+iFF4TBj0hfHCuDXplovCfEl10VmZlqkis0A016yTT53aW4g= Received: from AMXPR07MB070.eurprd07.prod.outlook.com (10.242.70.148) by AMXPR07MB069.eurprd07.prod.outlook.com (10.242.70.147) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 12 Jul 2016 08:14:56 +0000 Received: from AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) by AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) with mapi id 15.01.0528.026; Tue, 12 Jul 2016 08:14:56 +0000 From: Francesca Palombini To: Marco Tiloca Thread-Topic: [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt Thread-Index: AQHR2G3dJR4k7DwmmE2nHZmL8yaTPqAOF8bQgAUzcwCAAS6UIA== Date: Tue, 12 Jul 2016 08:14:56 +0000 Message-ID: References: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [80.216.62.213] x-ms-office365-filtering-correlation-id: 6926452e-107a-488c-ccb2-08d3aa2c9c0d x-microsoft-exchange-diagnostics: 1; AMXPR07MB069; 6:vf49FYy5sKAjPfik19NZjIP14nnHI9id7WwpvGWbmu1l1lSdGQPEB8HWI92PDb+/5LfgWNUYYaAluO1bON9qfg9+SB+VpcFI1LzsHnirCqwyn+BbnJ7Zj67coFlhrxHsq3uutOysPn88yPowQxw7c+Hw0Xp5crXOmrP8/oulxRFbbtKDj5CiS2sy40FLaNKSzcWrbLTzvk+No7RsLPkFmccBFxhBJ4amM7bG8SD4pGuMyJ+tk5NHUplcZp71Sh8svUw0DF1C0L5ka1lCxTl/VQ6z/FQJVsUScQR5/XRmN4g=; 5:LBGSTOK/lOl39o8QEALmWZswwSxXTvMCbb7nQ86DzLl+cmqcnwSs8A2ss6lPycyaVgbYBXjnu0roH9Ch0ebwidR5uOk/7T5GhqN/jbLpALPgrmSU/BwgDt+916buEcIYcZKiBI6VE3wBt70zK2YE7w==; 24:RBnX7sscbbWoFwzUkQSzR0o/OeXwFFuPyZWqqB7QxsmWhgR0RbQUwbwYlYIqzzQsZOzHXry3DGNsRR1x5wdcuZ800/3k6LA+yCYKMV+aSfE=; 7:X5b+iyb1+Bi205ubX0e20o+yNTcrD9Av/2ZXsW81XQnmAKcgqsxmVgJfhYEMY8nvHPdmcFOwLj5nzQOZL9jfQZf0fhGO/nVjhXd4ONJCkue9rIuYfUd8TfBI1CYBmYYRA6E4RZ0nxisT8J9tdlG8p9nYo/c/D85uSYH42Oi11XqxKazUEplXUW+otOw+VgIZxKR4UDZoY8qWTbNFRuA50fyUfrlMnHnTr283ePKSESyrKetUuRnuvIv3AnZ30LXR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB069; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(120809045254105)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMXPR07MB069; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB069; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(13464003)(189002)(377454003)(199003)(377424004)(24454002)(101416001)(2906002)(106356001)(54356999)(50986999)(19617315012)(105586002)(106116001)(76176999)(16601075003)(19580395003)(7696003)(3660700001)(7736002)(5003600100003)(2420400007)(19580405001)(19609705001)(68736007)(7846002)(9326002)(230783001)(81166006)(7906003)(3280700002)(81156014)(19625215002)(74316002)(8676002)(8936002)(15650500001)(19300405004)(33656002)(92566002)(4326007)(110136002)(14971765001)(122556002)(189998001)(86362001)(87936001)(790700001)(6116002)(16236675004)(10400500002)(102836003)(3846002)(10710500007)(97736004)(7110500001)(11100500001)(15975445007)(2900100001)(2950100001)(66066001)(9686002)(586003)(76576001)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB069; H:AMXPR07MB070.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMXPR07MB070FAF73F930DEF19972C8698300AMXPR07MB070eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 08:14:56.1234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB069 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XbOzo7Dwee8vVqQrrySl24wUKIsSYLugeYf6tCTjuYmO8tS KCwdiGa4vNTmLKnl8pYtpmlk0igzobIUyxmCNMOREmmmJUjbzgL/+73P+/B87wMfTYit/FBa rtQwaqVMIaGEpD7jSVQcz1yRntg9tFW68vsaIX2+0E1IG3sa+FJj1wC1j0wzmf7w0mqG1qjj vExhch6jkBcz6oS9OcKCtnUHWTQxgi5Wv75JlqEHr1AV8qEB7wbTwzEvB8HodDdVhYS0GL9E UNk65x2GEYxXTgjcA4lrCKiq/om4zTgC+/pbr20IQZnFQLnDKJwMozM/+G4OwGFg0VcSbiYw A7PNHzy6P86GyV6rgPPkwKLjNsVxCrRPTfHcTOII0K0sePwinAmfVls8fjGeRPDIkOVmH3wC 9E2dnnzkKrEy0snj3goGu+MOjyuHwfTsPcFxIDi/rvM5fy6MT10XcHo4LF8ZoDg+Am1Xv/Hc xQAvUKDtNHuDUqGh7LOLaRfLYXDxJCdfAqf2BsX5uxBU3R3whm6G3vkxb5BWAJZZG8E1YMDc pUW1KNaw4ViDK5fAKmh1pho8nf3gjd5BcnIMdD9N4NzhUF89I+A4GrTGZsFGvQUJ2lEgy7Bs Yf7OXfGMWp7LsiplvJLRPEauv/TCuhbXhzq+77chTCOJr6hlujxdzJcVsyWFNgQ0IQkQfTRV pItFebKSUkatylafVzCsDW2iSUmw6JgzPF2M82Ua5hzDFDHq/1se7RNahqJF/V3L7+Yyt99v 1gz2px3Nujdh81tpL65bMpaGhITqHL4juUv2uoAtYRAgz+uJ6LB8McZF/k1pklfPH5i11tfE WOwV/kGrbbUNzSbdED7bqNJJY4+dOr0t49dksq7cbJ1J0uYccl6OOWhXJHf27YmM6h9OvHD4 VtOZpJCI8BIJyRbIdsQSalb2D0VcQ9hHAwAA Archived-At: Cc: "Ace@ietf.org" , "core@ietf.org" , "cose@ietf.org" Subject: Re: [core] [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 08:15:05 -0000 --_000_AMXPR07MB070FAF73F930DEF19972C8698300AMXPR07MB070eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyY28sDQoNClRoYW5rIHlvdSBzbyBtdWNoIGZvciBhbiBleHRlbmRlZCByZXZpZXchIEkg YWdyZWUgd2l0aCBhbGwgeW91ciBjb21tZW50cyBhbmQgSSB0aGluayB0aGV5IHdpbGwgaW1wcm92 ZSB0aGUgcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0Lg0KSSBqdXN0IGhhdmUgYSBxdWVzdGlvbiBm b3IgMSk6DQoNCldlIGludHJvZHVjZSB0aGUgdXNlIG9mIENPU0Ugb2JqZWN0cyBhbHJlYWR5IGlu IFNlY3Rpb24gMS4gSW50cm9kdWN0aW9uLCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgcGFnZSAz ICjigJxPU0NPQVAgYnVpbGRzIG9uIENCT1IgT2JqZWN0IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24g KENPU0UpIOKApuKAnSkuIFdhcyB0aGVyZSBhIHJlYXNvbiB3aHkgeW91IHdhbnRlZCBpdCBtZW50 aW9uZWQgaW4gdGhlIE9iamVjdCBTZWN1cml0eSBvcHRpb24gc2VjdGlvbiwgc3BlY2lmaWNhbGx5 Pw0KDQpCZXN0LA0KRnJhbmNlc2NhDQoNCg0KRnJvbTogTWFyY28gVGlsb2NhIFttYWlsdG86bWFy Y29Ac2ljcy5zZV0NClNlbnQ6IGRlbiAxMSBqdWxpIDIwMTYgMTY6MTENClRvOiBGcmFuY2VzY2Eg UGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NCkNjOiBjb3JlQGll dGYub3JnOyBjb3NlQGlldGYub3JnOyBBY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0 LXNlY3VyaXR5LTA1LnR4dA0KDQpIZWxsbyBGcmFuY2VzY2EgYW5kIGFsbCwNCg0KSSBoYXZlIHJl dmlld2VkIHRoaXMgbGFzdCB2ZXJzaW9uIGFuZCBJIGJlbGlldmUgaXQgaXMgaW4gYSB2ZXJ5IGdv b2Qgc2hhcGUhDQoNClBsZWFzZSwgZmluZCBiZWxvdyBzb21lIHN1Z2dlc3Rpb25zIGZvciBtaW5v ciBjaGFuZ2VzL3VwZGF0ZXMuDQoNCkJlc3QgcmVnYXJkcywNCi9NYXJjbw0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCjEpIEluIFNlY3Rpb24gMiwgSSB3b3VsZCByZWZlciB0aGUg dXNhZ2Ugb2YgYSBDT1NFIG9iamVjdCBhcyBzb29uIGFzIHBvc3NpYmxlLCByYXRoZXIgdGhhbiBh dCB0aGUgZW5kIG9mIHBhZ2UgNSB3aGVyZSB5b3UgZGVzY3JpYmUgaG93IHRvIHByZXBhcmUgdGhl IHByb3RlY3RlZCBDb0FQIG1lc3NhZ2UuIEZvciBpbnN0YW5jZSwgdGhlIHZlcnkgZmlyc3Qgc2Vu dGVuY2UgaW4gU2VjdGlvbiAyIGNhbiBiZSBmb2xsb3dlZCBieSBzb21ldGhpbmcgbGlrZTogIlRo aXMgaXMgYWNoaWV2ZWQgYnkgbWVhbnMgb2YgYSBDT1NFIG9iamVjdCBpbmNsdWRlZCBpbiB0aGUg cHJvdGVjdGVkIENvQVAgbWVzc2FnZSwgYXMgZGV0YWlsZWQgYmVsb3ciLg0KDQoyKSBJbiBTZWN0 aW9uIDIgKHBhZ2UgNSksIEkgd291bGQgbW92ZSB0aGUgc2VudGVuY2UgIkFuIGVuZHBvaW50IHJl Y2VpdmluZyBbLi4uXSB0cmVhdCBpdCBhcyBtYWxmb3JtZWQgYW5kIHJlamVjdCBpdC4iIGF0IHRo ZSBlbmQgb2YgdGhlIGZpcnN0IGVsZW1lbnQgb2YgdGhlIGJ1bGxldCBsaXN0IGJlbG93LCBzaW5j ZSBpdCBjb25jZXJucyBDb0FQIG1lc3NhZ2VzIHdpdGggcGF5bG9hZC4NCg0KMykgRm9sbG93aW5n IHRoZSBzYW1lIHJlYXNvbmluZyBvZiBwb2ludCAyKSwgSSB3b3VsZCBleHRlbmQgdGhlIHNlY29u ZCBlbGVtZW50IGluIHRoZSBkb3R0ZWQgbGlzdCBhdCB0aGUgZW5kIG9mIHBhZ2UgNSB3aXRoOiAi QW4gZW5kcG9pbnQgcmVjZWl2aW5nIGEgQ29BUCBtZXNzYWdlIHdpdGhvdXQgcGF5bG9hZCwgdGhh dCBhbHNvIGNvbnRhaW5zIGFuIGVtcHR5IE9iamVjdC1TZWN1cml0eSBvcHRpb24gU0hBTEwgdHJl YXQgaXQgYXMgbWFsZm9ybWVkIGFuZCByZWplY3QgaXQiLg0KDQo0KSBTZWN0aW9uIDMuMSwgcGFn ZSA2LCAiVGhlIGVuZHBvaW50IHZlcmlmaWVzIHRoZSBtZXNzYWdlIHJlY2VpdmVkIiAtLT4gIlRo ZSBlbmRwb2ludCB2ZXJpZmllcyB0aGUgbWVzc2FnZXMgcmVjZWl2ZWQiLg0KDQo1KSBTZWN0aW9u IDUsIHBhZ2UgMTMsIGFkZCAiKHNlZSBTZWN0aW9uIDUuMSkiIGFmdGVyICJpcyBjb21wdXRlZCBm cm9tIHRoZSBQbGFpbnRleHQiLCBhbmQgIihzZWUgU2VjdGlvbiA1LjIpIiBhZnRlciAiYW5kIHRo ZSBBZGRpdGlvbmFsIEF1dGhlbnRpY2F0ZWQgRGF0YSAoQUFEKSIuDQoNCjYpIFNlY3Rpb24gNi4y LCBwYWdlIDE2LCBzdGVwIDEuIEluIHRoZSBsYXN0IHNlbnRlbmNlcyBhYm91dCByZW5ld2luZyB0 aGUgc2VjdXJpdHkgY29udGV4dCBvbiB0aGUgY2xpZW50LCBpdCB3b3VsZCBiZSBnb29kIHRvIG1l bnRpb24gYWxzbyB0aGF0IHRoaXMgaW52b2x2ZXMgaW5mb3JtaW5nIHRoZSBzZXJ2ZXIsIHNvIHRo YXQgaXQgY2FuIHVwZGF0ZSBpdHMgb3duIFJlY2VpdmVyLSogcGFyYW1ldGVycyBvbiBpdHMgb3du IGNvbnRleHQuDQoNCjcpIFNlY3Rpb24gNi4yLCBwYWdlIDE2LCBzdGVwIDIuICJTdG9yZSB0aGUg TUFDIG9mIGVhY2ggZnJhZ21lbnQiIC0tPiAiU3RvcmUgdGhlIE1BQyBvZiBlYWNoIGxhc3Qtc2Vu dCBmcmFnbWVudCIuDQoNCjgpIFNlY3Rpb24gNi4zLCBwYWdlIDE3LCBzdGVwIDIuICJTdG9yZSB0 aGUgTUFDIG9mIGVhY2ggZnJhZ21lbnQiIC0tPiAiU3RvcmUgdGhlIE1BQyBvZiBlYWNoIGxhc3Qt cmVjZWl2ZWQgZnJhZ21lbnQiLg0KDQo5KSBTZWN0aW9uIDYuNCwgcGFnZSAxOCwgc3RlcCAxLiBJ biB0aGUgbGFzdCBzZW50ZW5jZXMgYWJvdXQgcmVuZXdpbmcgdGhlIHNlY3VyaXR5IGNvbnRleHQg b24gdGhlIHNlcnZlciwgaXQgd291bGQgYmUgZ29vZCB0byBtZW50aW9uIGFsc28gdGhhdCB0aGlz IGludm9sdmVzIGluZm9ybWluZyB0aGUgY2xpZW50LCBzbyB0aGF0IGl0IGNhbiB1cGRhdGUgaXRz IG93biBSZWNlaXZlci0qIHBhcmFtZXRlcnMgb24gaXRzIG93biBjb250ZXh0Lg0KDQoxMCkgU2Vj dGlvbiA2LjQsIHBhZ2UgMTgsIHN0ZXAgMi4gIlN0b3JlIHRoZSBNQUMgb2YgZWFjaCBmcmFnbWVu dCIgLS0+ICJTdG9yZSB0aGUgTUFDIG9mIGVhY2ggbGFzdC1zZW50IGZyYWdtZW50Ii4NCg0KMTEp IFNlY3Rpb24gNi41LCBwYWdlIDE5LCBzdGVwIDIuICJTdG9yZSB0aGUgTUFDIG9mIGVhY2ggZnJh Z21lbnQiIC0tPiAiU3RvcmUgdGhlIE1BQyBvZiBlYWNoIGxhc3QtcmVjZWl2ZWQgZnJhZ21lbnQi Lg0KDQoxMikgU2VjdGlvbiA2LjUsIHBhZ2UgMjAsIGZpcnN0IHBhcmFncmFwaC4gQWZ0ZXIgdGhl IGxhc3Qgc2VudGVuY2UgIkRUTFMgYW5kIE9TQ09BUCBjYW4gYmUgY29tYmluZWQiLCBJIHdvdWxk IHJlc3RhdGUgd2hhdCBzYWlkIGluIFNlY3Rpb24gMSAocGFnZSA0KSwgdGhhdCBpcyAidGhlcmVi eSBlbmFibGluZyBlbmQtdG8tZW5kIC4uLiINCg0KMTMpIFNlY3Rpb24gNi41LCBwYWdlIDIwLCB0 aGlyZCBwYXJhZ3JhcGguICJUaGUgdXNlIG9mIENPU0UgdG8gcHJvdGVjdGVkIENvQVAgbWVzc2Fn ZXMiIC0tPiAiVGhlIHVzZSBvZiBDT1NFIHRvIHByb3RlY3QgQ29BUCBtZXNzYWdlcyINCg0KT24g RnJpLCBKdWwgOCwgMjAxNiBhdCA5OjAzIEFNLCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2Vz Y2EucGFsb21iaW5pQGVyaWNzc29uLmNvbTxtYWlsdG86ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmlj c3Nvbi5jb20+PiB3cm90ZToNCkRlYXIgQ29SRSwgQ09TRSBhbmQgQUNFIG1lbWJlcnMsDQoNCldl IGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZSB0byB0aGUgT1NDT0FQIGRyYWZ0Og0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUN Cg0KRm9yIHRob3NlIHdobyBkb27igJl0IGtub3csIE9TQ09BUCBpcyBhbiBhcHBsaWNhdGlvbiBs YXllciBzZWN1cml0eSBwcm90b2NvbCBmb3IgQ29BUCwgYmFzZWQgb24gd3JhcHBpbmcgcmVxdWVz dCBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgaW4gQ09TRSBvYmplY3RzIHdoaWNoIGFyZSBzZW50IGlu IGEgQ29BUCBtZXNzYWdlIGV4Y2hhbmdlLg0KDQpXaXRoIHRoaXMgdmVyc2lvbiwgd2UgYWltZWQg Zm9yIGltcHJvdmVkIHJlYWRhYmlsaXR5IGFuZCB3ZSBhZGRlZCB0aGUgYmxvY2t3aXNlIGZ1bmN0 aW9uYWxpdHksIGFzIGRpc2N1c3NlZCBkdXJpbmcgbGFzdCBmMmYgbWVldGluZy4NCg0KV2UgYXJl IG5vdyBsb29raW5nIGZvciByZXZpZXdzLiBBbnkgY29tbWVudCBvciBmZWVkYmFjayB3b3VsZCBi ZSBncmVhdGx5IGFwcHJlY2lhdGVkIQ0KDQpCZXN0IHJlZ2FyZHMsDQpGcmFuY2VzY2ENCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPl0NClNlbnQ6IGRlbiA3IGp1 bGkgMjAxNiAxODozNw0KVG86IEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nz b24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PjsgTHVkd2lnIFNlaXR6 IDxsdWR3aWdAc2ljcy5zZTxtYWlsdG86bHVkd2lnQHNpY3Muc2U+PjsgSm9obiBNYXR0c3NvbiA8 am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24u Y29tPj47IEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0 bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PjsgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJh bmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb208bWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJpbmlA ZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2NhIFBhbG9tYmluaSBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1zZWxh bmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5DQpSZXZpc2lvbjogICAgICAgMDUNClRpdGxlOiAgICAg ICAgICBPYmplY3QgU2VjdXJpdHkgb2YgQ29BUCAoT1NDT0FQKQ0KRG9jdW1lbnQgZGF0ZTogIDIw MTYtMDctMDcNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAg ICAgICAgICAzNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1LnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNlbGFuZGVy LWFjZS1vYmplY3Qtc2VjdXJpdHkvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUNCkRpZmY6ICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc2VsYW5kZXIt YWNlLW9iamVjdC1zZWN1cml0eS0wNQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBkZWZpbmVz IE9iamVjdCBTZWN1cml0eSBvZiBDb0FQIChPU0NPQVApLCBhIG1ldGhvZCBmb3INCiAgIGFwcGxp Y2F0aW9uIGxheWVyIHByb3RlY3Rpb24gb2YgbWVzc2FnZSBleGNoYW5nZXMgd2l0aCB0aGUNCiAg IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSwgdXNpbmcgdGhlIENCT1Ig T2JqZWN0DQogICBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKSBmb3JtYXQuICBPU0NPQVAg cHJvdmlkZXMgZW5kLXRvLWVuZA0KICAgZW5jcnlwdGlvbiwgaW50ZWdyaXR5IGFuZCByZXBsYXkg cHJvdGVjdGlvbiB0byBDb0FQIHBheWxvYWQsIG9wdGlvbnMsDQogICBhbmQgaGVhZGVyIGZpZWxk cywgYXMgd2VsbCBhcyBhIHNlY3VyZSBiaW5kaW5nIGJldHdlZW4gQ29BUCByZXF1ZXN0DQogICBh bmQgcmVzcG9uc2UgbWVzc2FnZXMuICBUaGUgdXNlIG9mIE9TQ09BUCBpcyBzaWduYWxlZCB3aXRo IHRoZSBDb0FQDQogICBvcHRpb24gT2JqZWN0LVNlY3VyaXR5LCBhbHNvIGRlZmluZWQgaW4gdGhp cyBtZW1vLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBp ZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UNCg0K --_000_AMXPR07MB070FAF73F930DEF19972C8698300AMXPR07MB070eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBNYXJjbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91 IHNvIG11Y2ggZm9yIGFuIGV4dGVuZGVkIHJldmlldyEgSSBhZ3JlZSB3aXRoIGFsbCB5b3VyIGNv bW1lbnRzIGFuZCBJIHRoaW5rIHRoZXkgd2lsbCBpbXByb3ZlIHRoZSByZWFkYWJpbGl0eSBvZiB0 aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JIGp1c3QgaGF2ZSBhIHF1ZXN0aW9uIGZvciAxKTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+V2UgaW50cm9kdWNlIHRoZSB1c2Ugb2YgQ09TRSBvYmplY3RzIGFscmVhZHkgaW4gU2VjdGlv biAxLiBJbnRyb2R1Y3Rpb24sIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBwYWdlIDMgKOKAnE9T Q09BUCBidWlsZHMgb24gQ0JPUiBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkg 4oCm4oCdKS4gV2FzDQogdGhlcmUgYSByZWFzb24gd2h5IHlvdSB3YW50ZWQgaXQgbWVudGlvbmVk IGluIHRoZSBPYmplY3QgU2VjdXJpdHkgb3B0aW9uIHNlY3Rpb24sIHNwZWNpZmljYWxseT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1hcmNvQHNpY3Muc2VdDQo8YnI+DQo8Yj5TZW50OjwvYj4g ZGVuIDExIGp1bGkgMjAxNiAxNjoxMTxicj4NCjxiPlRvOjwvYj4gRnJhbmNlc2NhIFBhbG9tYmlu aSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBjb3JlQGlldGYub3JnOyBjb3NlQGlldGYub3JnOyBBY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtBY2VdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gRnJhbmNlc2NhIGFuZCBhbGwsPGJyPg0KPGJyPg0KSSBo YXZlIHJldmlld2VkIHRoaXMgbGFzdCB2ZXJzaW9uIGFuZCBJIGJlbGlldmUgaXQgaXMgaW4gYSB2 ZXJ5IGdvb2Qgc2hhcGUhPGJyPg0KPGJyPg0KUGxlYXNlLCBmaW5kIGJlbG93IHNvbWUgc3VnZ2Vz dGlvbnMgZm9yIG1pbm9yIGNoYW5nZXMvdXBkYXRlcy48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMs PGJyPg0KL01hcmNvPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N Cjxicj4NCjEpIEluIFNlY3Rpb24gMiwgSSB3b3VsZCByZWZlciB0aGUgdXNhZ2Ugb2YgYSBDT1NF IG9iamVjdCBhcyBzb29uIGFzIHBvc3NpYmxlLCByYXRoZXIgdGhhbiBhdCB0aGUgZW5kIG9mIHBh Z2UgNSB3aGVyZSB5b3UgZGVzY3JpYmUgaG93IHRvIHByZXBhcmUgdGhlIHByb3RlY3RlZCBDb0FQ IG1lc3NhZ2UuIEZvciBpbnN0YW5jZSwgdGhlIHZlcnkgZmlyc3Qgc2VudGVuY2UgaW4gU2VjdGlv biAyIGNhbiBiZSBmb2xsb3dlZCBieSBzb21ldGhpbmcgbGlrZToNCiAmcXVvdDtUaGlzIGlzIGFj aGlldmVkIGJ5IG1lYW5zIG9mIGEgQ09TRSBvYmplY3QgaW5jbHVkZWQgaW4gdGhlIHByb3RlY3Rl ZCBDb0FQIG1lc3NhZ2UsIGFzIGRldGFpbGVkIGJlbG93JnF1b3Q7Ljxicj4NCjxicj4NCjIpIElu IFNlY3Rpb24gMiAocGFnZSA1KSwgSSB3b3VsZCBtb3ZlIHRoZSBzZW50ZW5jZSAmcXVvdDtBbiBl bmRwb2ludCByZWNlaXZpbmcgWy4uLl0gdHJlYXQgaXQgYXMgbWFsZm9ybWVkIGFuZCByZWplY3Qg aXQuJnF1b3Q7IGF0IHRoZSBlbmQgb2YgdGhlIGZpcnN0IGVsZW1lbnQgb2YgdGhlIGJ1bGxldCBs aXN0IGJlbG93LCBzaW5jZSBpdCBjb25jZXJucyBDb0FQIG1lc3NhZ2VzIHdpdGggcGF5bG9hZC48 YnI+DQo8YnI+DQozKSBGb2xsb3dpbmcgdGhlIHNhbWUgcmVhc29uaW5nIG9mIHBvaW50IDIpLCBJ IHdvdWxkIGV4dGVuZCB0aGUgc2Vjb25kIGVsZW1lbnQgaW4gdGhlIGRvdHRlZCBsaXN0IGF0IHRo ZSBlbmQgb2YgcGFnZSA1IHdpdGg6ICZxdW90O0FuIGVuZHBvaW50IHJlY2VpdmluZyBhIENvQVAg bWVzc2FnZSB3aXRob3V0IHBheWxvYWQsIHRoYXQgYWxzbyBjb250YWlucyBhbiBlbXB0eSBPYmpl Y3QtU2VjdXJpdHkgb3B0aW9uIFNIQUxMIHRyZWF0IGl0IGFzIG1hbGZvcm1lZA0KIGFuZCByZWpl Y3QgaXQmcXVvdDsuPGJyPg0KPGJyPg0KNCkgU2VjdGlvbiAzLjEsIHBhZ2UgNiwgJnF1b3Q7VGhl IGVuZHBvaW50IHZlcmlmaWVzIHRoZSBtZXNzYWdlIHJlY2VpdmVkJnF1b3Q7IC0tJmd0OyAmcXVv dDtUaGUgZW5kcG9pbnQgdmVyaWZpZXMgdGhlIG1lc3NhZ2VzIHJlY2VpdmVkJnF1b3Q7Ljxicj4N Cjxicj4NCjUpIFNlY3Rpb24gNSwgcGFnZSAxMywgYWRkICZxdW90OyhzZWUgU2VjdGlvbiA1LjEp JnF1b3Q7IGFmdGVyICZxdW90O2lzIGNvbXB1dGVkIGZyb20gdGhlIFBsYWludGV4dCZxdW90Oywg YW5kICZxdW90OyhzZWUgU2VjdGlvbiA1LjIpJnF1b3Q7IGFmdGVyICZxdW90O2FuZCB0aGUgQWRk aXRpb25hbCBBdXRoZW50aWNhdGVkIERhdGEgKEFBRCkmcXVvdDsuPGJyPg0KPGJyPg0KNikgU2Vj dGlvbiA2LjIsIHBhZ2UgMTYsIHN0ZXAgMS4gSW4gdGhlIGxhc3Qgc2VudGVuY2VzIGFib3V0IHJl bmV3aW5nIHRoZSBzZWN1cml0eSBjb250ZXh0IG9uIHRoZSBjbGllbnQsIGl0IHdvdWxkIGJlIGdv b2QgdG8gbWVudGlvbiBhbHNvIHRoYXQgdGhpcyBpbnZvbHZlcyBpbmZvcm1pbmcgdGhlIHNlcnZl ciwgc28gdGhhdCBpdCBjYW4gdXBkYXRlIGl0cyBvd24gUmVjZWl2ZXItKiBwYXJhbWV0ZXJzIG9u IGl0cyBvd24gY29udGV4dC48YnI+DQo8YnI+DQo3KSBTZWN0aW9uIDYuMiwgcGFnZSAxNiwgc3Rl cCAyLiAmcXVvdDtTdG9yZSB0aGUgTUFDIG9mIGVhY2ggZnJhZ21lbnQmcXVvdDsgLS0mZ3Q7ICZx dW90O1N0b3JlIHRoZSBNQUMgb2YgZWFjaCBsYXN0LXNlbnQgZnJhZ21lbnQmcXVvdDsuPGJyPg0K PGJyPg0KOCkgU2VjdGlvbiA2LjMsIHBhZ2UgMTcsIHN0ZXAgMi4gJnF1b3Q7U3RvcmUgdGhlIE1B QyBvZiBlYWNoIGZyYWdtZW50JnF1b3Q7IC0tJmd0OyAmcXVvdDtTdG9yZSB0aGUgTUFDIG9mIGVh Y2ggbGFzdC1yZWNlaXZlZCBmcmFnbWVudCZxdW90Oy48YnI+DQo8YnI+DQo5KSBTZWN0aW9uIDYu NCwgcGFnZSAxOCwgc3RlcCAxLiBJbiB0aGUgbGFzdCBzZW50ZW5jZXMgYWJvdXQgcmVuZXdpbmcg dGhlIHNlY3VyaXR5IGNvbnRleHQgb24gdGhlIHNlcnZlciwgaXQgd291bGQgYmUgZ29vZCB0byBt ZW50aW9uIGFsc28gdGhhdCB0aGlzIGludm9sdmVzIGluZm9ybWluZyB0aGUgY2xpZW50LCBzbyB0 aGF0IGl0IGNhbiB1cGRhdGUgaXRzIG93biBSZWNlaXZlci0qIHBhcmFtZXRlcnMgb24gaXRzIG93 biBjb250ZXh0Ljxicj4NCjxicj4NCjEwKSBTZWN0aW9uIDYuNCwgcGFnZSAxOCwgc3RlcCAyLiAm cXVvdDtTdG9yZSB0aGUgTUFDIG9mIGVhY2ggZnJhZ21lbnQmcXVvdDsgLS0mZ3Q7ICZxdW90O1N0 b3JlIHRoZSBNQUMgb2YgZWFjaCBsYXN0LXNlbnQgZnJhZ21lbnQmcXVvdDsuPGJyPg0KPGJyPg0K MTEpIFNlY3Rpb24gNi41LCBwYWdlIDE5LCBzdGVwIDIuICZxdW90O1N0b3JlIHRoZSBNQUMgb2Yg ZWFjaCBmcmFnbWVudCZxdW90OyAtLSZndDsgJnF1b3Q7U3RvcmUgdGhlIE1BQyBvZiBlYWNoIGxh c3QtcmVjZWl2ZWQgZnJhZ21lbnQmcXVvdDsuPGJyPg0KPGJyPg0KMTIpIFNlY3Rpb24gNi41LCBw YWdlIDIwLCBmaXJzdCBwYXJhZ3JhcGguIEFmdGVyIHRoZSBsYXN0IHNlbnRlbmNlICZxdW90O0RU TFMgYW5kIE9TQ09BUCBjYW4gYmUgY29tYmluZWQmcXVvdDssIEkgd291bGQgcmVzdGF0ZSB3aGF0 IHNhaWQgaW4gU2VjdGlvbiAxIChwYWdlIDQpLCB0aGF0IGlzICZxdW90O3RoZXJlYnkgZW5hYmxp bmcgZW5kLXRvLWVuZCAuLi4mcXVvdDs8YnI+DQo8YnI+DQoxMykgU2VjdGlvbiA2LjUsIHBhZ2Ug MjAsIHRoaXJkIHBhcmFncmFwaC4gJnF1b3Q7VGhlIHVzZSBvZiBDT1NFIHRvIHByb3RlY3RlZCBD b0FQIG1lc3NhZ2VzJnF1b3Q7IC0tJmd0OyAmcXVvdDtUaGUgdXNlIG9mIENPU0UgdG8gcHJvdGVj dCBDb0FQIG1lc3NhZ2VzJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGcmksIEp1bCA4LCAyMDE2IGF0IDk6MDMgQU0sIEZyYW5jZXNjYSBQYWxv bWJpbmkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RGVhciBDb1JFLCBDT1NFIGFuZCBBQ0UgbWVtYmVycyw8YnI+DQo8YnI+DQpXZSBoYXZlIHN1 Ym1pdHRlZCBhbiB1cGRhdGUgdG8gdGhlIE9TQ09BUCBkcmFmdDo8YnI+DQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0 eS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z ZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1PC9hPjxicj4NCjxicj4NCkZvciB0aG9zZSB3 aG8gZG9u4oCZdCBrbm93LCBPU0NPQVAgaXMgYW4gYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJpdHkg cHJvdG9jb2wgZm9yIENvQVAsIGJhc2VkIG9uIHdyYXBwaW5nIHJlcXVlc3QgYW5kIHJlc3BvbnNl IG1lc3NhZ2VzIGluIENPU0Ugb2JqZWN0cyB3aGljaCBhcmUgc2VudCBpbiBhIENvQVAgbWVzc2Fn ZSBleGNoYW5nZS48YnI+DQo8YnI+DQpXaXRoIHRoaXMgdmVyc2lvbiwgd2UgYWltZWQgZm9yIGlt cHJvdmVkIHJlYWRhYmlsaXR5IGFuZCB3ZSBhZGRlZCB0aGUgYmxvY2t3aXNlIGZ1bmN0aW9uYWxp dHksIGFzIGRpc2N1c3NlZCBkdXJpbmcgbGFzdCBmMmYgbWVldGluZy48YnI+DQo8YnI+DQpXZSBh cmUgbm93IGxvb2tpbmcgZm9yIHJldmlld3MuIEFueSBjb21tZW50IG9yIGZlZWRiYWNrIHdvdWxk IGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQhPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCkZy YW5jZXNjYTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KU2VudDogZGVuIDcganVs aSAyMDE2IDE4OjM3PGJyPg0KVG86IEfDtnJhbiBTZWxhbmRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbSI+Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29t PC9hPiZndDs7IEx1ZHdpZyBTZWl0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1ZHdpZ0BzaWNzLnNl Ij5sdWR3aWdAc2ljcy5zZTwvYT4mZ3Q7OyBKb2huIE1hdHRzc29uICZsdDs8YSBocmVmPSJtYWls dG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20iPmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29t PC9hPiZndDs7DQogR8O2cmFuIFNlbGFuZGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z29yYW4uc2Vs YW5kZXJAZXJpY3Nzb24uY29tIj5nb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+Jmd0Ozsg RnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJp bmlAZXJpY3Nzb24uY29tIj5mcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 PGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zZWxhbmRl ci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1LnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1LnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2NhIFBhbG9tYmluaSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmpl Y3Qtc2VjdXJpdHk8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswNTxi cj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT2JqZWN0IFNlY3Vy aXR5IG9mIENvQVAgKE9TQ09BUCk8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE2LTA3LTA3 PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFs IFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDM2PGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zZWxhbmRl ci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2Vj dXJpdHktMDUudHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2Vs YW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5Lzwv YT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0 eS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z ZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1PC9hPjxicj4NCkRpZmY6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zZWxh bmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1PC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiZuYnNwOyAmbmJzcDtUaGlzIG1lbW8gZGVmaW5lcyBPYmplY3QgU2VjdXJpdHkgb2YgQ29BUCAo T1NDT0FQKSwgYSBtZXRob2QgZm9yPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGxheWVy IHByb3RlY3Rpb24gb2YgbWVzc2FnZSBleGNoYW5nZXMgd2l0aCB0aGU8YnI+DQombmJzcDsgJm5i c3A7Q29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLCB1c2luZyB0aGUgQ0JP UiBPYmplY3Q8YnI+DQombmJzcDsgJm5ic3A7U2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkg Zm9ybWF0LiZuYnNwOyBPU0NPQVAgcHJvdmlkZXMgZW5kLXRvLWVuZDxicj4NCiZuYnNwOyAmbmJz cDtlbmNyeXB0aW9uLCBpbnRlZ3JpdHkgYW5kIHJlcGxheSBwcm90ZWN0aW9uIHRvIENvQVAgcGF5 bG9hZCwgb3B0aW9ucyw8YnI+DQombmJzcDsgJm5ic3A7YW5kIGhlYWRlciBmaWVsZHMsIGFzIHdl bGwgYXMgYSBzZWN1cmUgYmluZGluZyBiZXR3ZWVuIENvQVAgcmVxdWVzdDxicj4NCiZuYnNwOyAm bmJzcDthbmQgcmVzcG9uc2UgbWVzc2FnZXMuJm5ic3A7IFRoZSB1c2Ugb2YgT1NDT0FQIGlzIHNp Z25hbGVkIHdpdGggdGhlIENvQVA8YnI+DQombmJzcDsgJm5ic3A7b3B0aW9uIE9iamVjdC1TZWN1 cml0eSwgYWxzbyBkZWZpbmVkIGluIHRoaXMgbWVtby48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KQWNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpBY2VA aWV0Zi5vcmciPkFjZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AMXPR07MB070FAF73F930DEF19972C8698300AMXPR07MB070eurprd_-- From nobody Tue Jul 12 02:26:16 2016 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 C04E812D767 for ; Tue, 12 Jul 2016 02:26:14 -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=sics-se.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 P__2_soSRUtY for ; Tue, 12 Jul 2016 02:26:12 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 152FB12B010 for ; Tue, 12 Jul 2016 02:26:12 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id f7so13444441vkb.3 for ; Tue, 12 Jul 2016 02:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s8WjU17rkbgWcbhWF/iqD45FCSmJZBXiggvKjh8MN0k=; b=hK2W7QBS/frfFTwzRQiDFYFwl7u5zkb4FgghBn+CVACpnpnTcXBMXSlSBNxRImSASG FdEBn9Y8eLG2biFzJqgK1x3xbyHGap3asdVYu9oWFfylVGZwlceR7EvnGzPqECHcARBV zNCZXqmMAZMdBp/N//oc3qxsB+ecgBwDTVhWiQdN69faEwnS5z0qJ+lWbnMafkv/0HPC nH3tCn1blMmkaklTuqEaey3Q7u+Eub4/1Z4QaKENzH+zPw0zAK6UKS57lePTNxEAWiFr 52JPZMHpC41UOjbufVGDJgwFHgJmLX9pbVo9S2pswWO8DYmDI0Ga6ZeQHAccEQcW8lA2 iBNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s8WjU17rkbgWcbhWF/iqD45FCSmJZBXiggvKjh8MN0k=; b=XosXD0HcGFfCg/Q4SDs6/LDeWGp4gk/qIRxRVMmlNTFQkn0fkovOlf6P/spmCXolmH lTg7MdOKRJOXbDDnA72MZA9YazhksDFd3WAwkDu4fx+P9opsHhK9VMmUrpIY1nZXsxDg 6FT3xJjZQwhOCeoTX2evYZf9gxig7b5PrGOHC/z2BWlwYavom3i28ZjjDGvAM5vFtmBv dnGLckbPo8eDq0jNRPxSB1qHfpVUtdSDuI7XBb4SFtv72qQSdUrfbwNhIN2pA1r9aKIu A3LbDFsqANajFoGHyOCXjxP9bScZvHkip2r7mD7QOWedBSCmCsOlRNtmkRScAGzmV8ja 4vng== X-Gm-Message-State: ALyK8tLvioXpKbl97CrK1SRFuvtsMtGlJLLu8h335oteSNpg/6YLNxdRoUEpHBq7Q5ZLURcuwv8eCarrBsDPqOBw X-Received: by 10.31.129.203 with SMTP id c194mr486513vkd.26.1468315571136; Tue, 12 Jul 2016 02:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.87.74 with HTTP; Tue, 12 Jul 2016 02:26:10 -0700 (PDT) In-Reply-To: References: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> From: Marco Tiloca Date: Tue, 12 Jul 2016 11:26:10 +0200 Message-ID: To: Francesca Palombini Content-Type: multipart/alternative; boundary=001a1145037e09495805376cdc89 Archived-At: Cc: "Ace@ietf.org" , "core@ietf.org" , "cose@ietf.org" Subject: Re: [core] [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 09:26:15 -0000 --001a1145037e09495805376cdc89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Francesca, On Tue, Jul 12, 2016 at 10:14 AM, Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Hi Marco, > > > > Thank you so much for an extended review! I agree with all your comments > and I think they will improve the readability of the draft. > > I just have a question for 1): > > > > We introduce the use of COSE objects already in Section 1. Introduction, > in the last paragraph of page 3 (=E2=80=9COSCOAP builds on CBOR Object Si= gning and > Encryption (COSE) =E2=80=A6=E2=80=9D). Was there a reason why you wanted = it mentioned in > the Object Security option section, specifically? > I suggested that just for the sake of readability. The COSE object is introduced in Section 1, but then I thought about a reader starting directly from the actual specification in Section 2, where the COSE object "suddenly reappears" at the end of page 5, and is of course detailed only later in Section 5. This is why I believe it would be good to quickly mention again the usage of COSE objects at the beginning of Section 2, just from a high-level perspective as in the Introduction and also pointing to Section 5 for further details, so better preparing the reader for the 2-element bullet list at the end of page 5. Best regards, Marco > > > Best, > > Francesca > > > > > > *From:* Marco Tiloca [mailto:marco@sics.se] > *Sent:* den 11 juli 2016 16:11 > *To:* Francesca Palombini > *Cc:* core@ietf.org; cose@ietf.org; Ace@ietf.org > *Subject:* Re: [Ace] FW: New Version Notification for > draft-selander-ace-object-security-05.txt > > > > Hello Francesca and all, > > I have reviewed this last version and I believe it is in a very good shap= e! > > Please, find below some suggestions for minor changes/updates. > > Best regards, > /Marco > > ---------------------------- > > 1) In Section 2, I would refer the usage of a COSE object as soon as > possible, rather than at the end of page 5 where you describe how to > prepare the protected CoAP message. For instance, the very first sentence > in Section 2 can be followed by something like: "This is achieved by mean= s > of a COSE object included in the protected CoAP message, as detailed belo= w". > > 2) In Section 2 (page 5), I would move the sentence "An endpoint receivin= g > [...] treat it as malformed and reject it." at the end of the first eleme= nt > of the bullet list below, since it concerns CoAP messages with payload. > > 3) Following the same reasoning of point 2), I would extend the second > element in the dotted list at the end of page 5 with: "An endpoint > receiving a CoAP message without payload, that also contains an empty > Object-Security option SHALL treat it as malformed and reject it". > > 4) Section 3.1, page 6, "The endpoint verifies the message received" --> > "The endpoint verifies the messages received". > > 5) Section 5, page 13, add "(see Section 5.1)" after "is computed from th= e > Plaintext", and "(see Section 5.2)" after "and the Additional Authenticat= ed > Data (AAD)". > > 6) Section 6.2, page 16, step 1. In the last sentences about renewing the > security context on the client, it would be good to mention also that thi= s > involves informing the server, so that it can update its own Receiver-* > parameters on its own context. > > 7) Section 6.2, page 16, step 2. "Store the MAC of each fragment" --> > "Store the MAC of each last-sent fragment". > > 8) Section 6.3, page 17, step 2. "Store the MAC of each fragment" --> > "Store the MAC of each last-received fragment". > > 9) Section 6.4, page 18, step 1. In the last sentences about renewing the > security context on the server, it would be good to mention also that thi= s > involves informing the client, so that it can update its own Receiver-* > parameters on its own context. > > 10) Section 6.4, page 18, step 2. "Store the MAC of each fragment" --> > "Store the MAC of each last-sent fragment". > > 11) Section 6.5, page 19, step 2. "Store the MAC of each fragment" --> > "Store the MAC of each last-received fragment". > > 12) Section 6.5, page 20, first paragraph. After the last sentence "DTLS > and OSCOAP can be combined", I would restate what said in Section 1 (page > 4), that is "thereby enabling end-to-end ..." > > 13) Section 6.5, page 20, third paragraph. "The use of COSE to protected > CoAP messages" --> "The use of COSE to protect CoAP messages" > > > > On Fri, Jul 8, 2016 at 9:03 AM, Francesca Palombini < > francesca.palombini@ericsson.com> wrote: > > Dear CoRE, COSE and ACE members, > > We have submitted an update to the OSCOAP draft: > https://tools.ietf.org/html/draft-selander-ace-object-security-05 > > For those who don=E2=80=99t know, OSCOAP is an application layer security= protocol > for CoAP, based on wrapping request and response messages in COSE objects > which are sent in a CoAP message exchange. > > With this version, we aimed for improved readability and we added the > blockwise functionality, as discussed during last f2f meeting. > > We are now looking for reviews. Any comment or feedback would be greatly > appreciated! > > Best regards, > Francesca > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: den 7 juli 2016 18:37 > To: G=C3=B6ran Selander ; Ludwig Seitz < > ludwig@sics.se>; John Mattsson ; G=C3=B6ran > Selander ; Francesca Palombini < > francesca.palombini@ericsson.com> > Subject: New Version Notification for > draft-selander-ace-object-security-05.txt > > > A new version of I-D, draft-selander-ace-object-security-05.txt > has been successfully submitted by Francesca Palombini and posted to the > IETF repository. > > Name: draft-selander-ace-object-security > Revision: 05 > Title: Object Security of CoAP (OSCOAP) > Document date: 2016-07-07 > Group: Individual Submission > Pages: 36 > URL: > https://www.ietf.org/internet-drafts/draft-selander-ace-object-security-0= 5.txt > Status: > https://datatracker.ietf.org/doc/draft-selander-ace-object-security/ > Htmlized: > https://tools.ietf.org/html/draft-selander-ace-object-security-05 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-selander-ace-object-security-05 > > Abstract: > This memo defines Object Security of CoAP (OSCOAP), a method for > application layer protection of message exchanges with the > Constrained Application Protocol (CoAP), using the CBOR Object > Signing and Encryption (COSE) format. OSCOAP provides end-to-end > encryption, integrity and replay protection to CoAP payload, options, > and header fields, as well as a secure binding between CoAP request > and response messages. The use of OSCOAP is signaled with the CoAP > option Object-Security, also defined in this memo. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > --001a1145037e09495805376cdc89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Francesca,

On Tue, Jul 12, 2016 at 10:14 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:

Hi Marco,

=C2=A0

Thank you so much for an extended review! I agree wit= h all your comments and I think they will improve the readability of the dr= aft.

I just have a question for 1):

=C2=A0

We introduce the use of COSE objects already in Secti= on 1. Introduction, in the last paragraph of page 3 (=E2=80=9COSCOAP builds= on CBOR Object Signing and Encryption (COSE) =E2=80=A6=E2=80=9D). Was there a reason why you wanted it mentioned in the Object Security option s= ection, specifically?


I suggested that just for the sake of readability. The COSE object is int= roduced in Section 1, but then I thought about a reader starting directly f= rom the actual specification in Section 2, where the COSE object "sudd= enly reappears" at the end of page 5, and is of course detailed only l= ater in Section 5.

This is why I believe it would be good to quickly= mention again the usage of COSE objects at the beginning of Section 2, jus= t from a high-level perspective as in the Introduction and also pointing to= Section 5 for further details, so better preparing the reader for the 2-el= ement bullet list at the end of page 5.

Best regards,
=
Marco
=C2=A0
<= p class=3D"MsoNormal">

=C2=A0

Best,

Francesca

=C2=A0

=C2=A0

From: Marco Tiloca [mailto:marco@sics.se]
Sent: den 11 juli 2016 16:11
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: core@ietf.org= ; cose@ietf.org;= Ace@ietf.org
Subject: Re: [Ace] FW: New Version Notification for draft-selander-a= ce-object-security-05.txt

=C2=A0

Hello Francesca and all,

I have reviewed this last version and I believe it is in a very good shape!=

Please, find below some suggestions for minor changes/updates.

Best regards,
/Marco

----------------------------

1) In Section 2, I would refer the usage of a COSE object as soon as possib= le, rather than at the end of page 5 where you describe how to prepare the = protected CoAP message. For instance, the very first sentence in Section 2 = can be followed by something like: "This is achieved by means of a COSE object included in the protected= CoAP message, as detailed below".

2) In Section 2 (page 5), I would move the sentence "An endpoint recei= ving [...] treat it as malformed and reject it." at the end of the fir= st element of the bullet list below, since it concerns CoAP messages with p= ayload.

3) Following the same reasoning of point 2), I would extend the second elem= ent in the dotted list at the end of page 5 with: "An endpoint receivi= ng a CoAP message without payload, that also contains an empty Object-Secur= ity option SHALL treat it as malformed and reject it".

4) Section 3.1, page 6, "The endpoint verifies the message received&qu= ot; --> "The endpoint verifies the messages received".

5) Section 5, page 13, add "(see Section 5.1)" after "is com= puted from the Plaintext", and "(see Section 5.2)" after &qu= ot;and the Additional Authenticated Data (AAD)".

6) Section 6.2, page 16, step 1. In the last sentences about renewing the s= ecurity context on the client, it would be good to mention also that this i= nvolves informing the server, so that it can update its own Receiver-* para= meters on its own context.

7) Section 6.2, page 16, step 2. "Store the MAC of each fragment"= --> "Store the MAC of each last-sent fragment".

8) Section 6.3, page 17, step 2. "Store the MAC of each fragment"= --> "Store the MAC of each last-received fragment".

9) Section 6.4, page 18, step 1. In the last sentences about renewing the s= ecurity context on the server, it would be good to mention also that this i= nvolves informing the client, so that it can update its own Receiver-* para= meters on its own context.

10) Section 6.4, page 18, step 2. "Store the MAC of each fragment"= ; --> "Store the MAC of each last-sent fragment".

11) Section 6.5, page 19, step 2. "Store the MAC of each fragment"= ; --> "Store the MAC of each last-received fragment".

12) Section 6.5, page 20, first paragraph. After the last sentence "DT= LS and OSCOAP can be combined", I would restate what said in Section 1= (page 4), that is "thereby enabling end-to-end ..."

13) Section 6.5, page 20, third paragraph. "The use of COSE to protect= ed CoAP messages" --> "The use of COSE to protect CoAP message= s"

=C2=A0

On Fri, Jul 8, 2016 at 9:03 AM, Francesca Palombini = <f= rancesca.palombini@ericsson.com> wrote:

Dear CoRE, COSE and ACE members,

We have submitted an update to the OSCOAP draft:
https://tools.ietf.org/html/draft-selander-ace-object-= security-05

For those who don=E2=80=99t know, OSCOAP is an application layer security p= rotocol for CoAP, based on wrapping request and response messages in COSE o= bjects which are sent in a CoAP message exchange.

With this version, we aimed for improved readability and we added the block= wise functionality, as discussed during last f2f meeting.

We are now looking for reviews. Any comment or feedback would be greatly ap= preciated!

Best regards,
Francesca

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: den 7 juli 2016 18:37
To: G=C3=B6ran Selander <goran.selander@ericsson.com>; Ludwig Seitz <ludwig@sics.se>; Jo= hn Mattsson <john.mattsson@ericsson.com>; G=C3=B6ran Selander <goran.selander@ericsson.com>; Francesca Palombini <= ;fran= cesca.palombini@ericsson.com>
Subject: New Version Notification for draft-selander-ace-object-security-05= .txt


A new version of I-D, draft-selander-ace-object-security-05.txt
has been successfully submitted by Francesca Palombini and posted to the IE= TF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-selander-ace-object-sec= urity
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Object Security of CoAP (OSCOAP) Document date:=C2=A0 2016-07-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 36
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-selander-ace-object-security-05.= txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://da= tatracker.ietf.org/doc/draft-selander-ace-object-security/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf= .org/html/draft-selander-ace-object-security-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/rfcdiff?url2=3Ddraft-selander-ace-object-security-05

Abstract:
=C2=A0 =C2=A0This memo defines Object Security of CoAP (OSCOAP), a method f= or
=C2=A0 =C2=A0application layer protection of message exchanges with the
=C2=A0 =C2=A0Constrained Application Protocol (CoAP), using the CBOR Object=
=C2=A0 =C2=A0Signing and Encryption (COSE) format.=C2=A0 OSCOAP provides en= d-to-end
=C2=A0 =C2=A0encryption, integrity and replay protection to CoAP payload, o= ptions,
=C2=A0 =C2=A0and header fields, as well as a secure binding between CoAP re= quest
=C2=A0 =C2=A0and response messages.=C2=A0 The use of OSCOAP is signaled wit= h the CoAP
=C2=A0 =C2=A0option Object-Security, also defined in this memo.




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

The IETF Secretariat

_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace

=C2=A0


--001a1145037e09495805376cdc89-- From nobody Tue Jul 12 02:29:48 2016 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 792E012B026 for ; Tue, 12 Jul 2016 02:29:46 -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 sYprGjqnykyj for ; Tue, 12 Jul 2016 02:29:45 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424CD12D779 for ; Tue, 12 Jul 2016 02:29:44 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-d3-5784b886bdc6 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.32.12926.688B4875; Tue, 12 Jul 2016 11:29:42 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.78]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Tue, 12 Jul 2016 11:29:42 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1l?= =?utf-8?Q?tch-01?= Thread-Index: AQHR0JnRoHfXWox5pU+oHjfIDFovzp//khgAgABd24CAAQn1gIAAdIqAgAADVgCAEwtRAA== Date: Tue, 12 Jul 2016 09:29:41 +0000 Message-ID: <0EDF6F20-8586-4114-BA0C-1C8BAC19E3E7@ericsson.com> References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <4de1fa0ba3892f78d38443c602d7501d@xs4all.nl> <2d763e20-676a-33df-196d-d879ada8b57d@nteczone.com> <5774BC01.7090606@tzi.org> <1c6c7058-63e7-a0ff-6bd4-ceb644c6802d@nteczone.com> In-Reply-To: <1c6c7058-63e7-a0ff-6bd4-ceb644c6802d@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_0EDF6F2085864114BA0C1C8BAC19E3E7ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7mW7bjpZwg5Y1WhZHptxltfjyvpHF Yt/b9cwWTf3HGR1YPJYs+cnkseL8TBaPaYsyPU59/cwewBLFZZOSmpNZllqkb5fAldGyfiJr wUO+iikTd7E3MM7i62Lk5JAQMJG4cm0XG4QtJnHh3nogm4tDSOAIo8SRl19YIZzFjBIfO/ex gFSxCThLfHrWyA5iiwioSbROegXWwSzQyCixZOVRZpCEsECWxKUd31ggirIlDk5ZD9UQJrHu +QywOIuAqsTePZeAbA4OXgF7iedLEiGWrWWSOPp8ORNIDaeAg8TGncvA6hmBzvt+ag1YnFlA XOLWk/lMEGcLSCzZc54ZwhaVePn4HyuErSTxY8MlFoj6ZImdXffB6nkFBCVOznzCMoFRdBaS UbOQlM1CUjYL6DxmAU2J9bv0IUoUJaZ0P2SHsDUkWufMhbKtJY6dOc2CrGYBI8cqRtHi1OKk 3HQjY73Uoszk4uL8PL281JJNjMB4Pbjlt+oOxstvHA8xCnAwKvHwLrjXHC7EmlhWXJl7iFGC g1lJhHfN+pZwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxS DYxigic/1jdf+d12+57Xx3mrT+/uSH2xO9bzWvypbKa3Ihk26WtSBZlrNf6mLj1q926F69RK k7vFMsm3fBZIr7F4zaD+M+rdLP1zVQZSu5iEbVnm+hS97Aq98CQ9gMOR3yL25OYLHRyqz4MW 5C/JPLT88emIfacWHL+8Jjv86elLdppdc/pD/15QYinOSDTUYi4qTgQA25SIm9MCAAA= Archived-At: Cc: "stokcons@xs4all.nl" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 09:29:46 -0000 --_000_0EDF6F2085864114BA0C1C8BAC19E3E7ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpmcm9tIHRoZSBlbWFpbCBkaXNjdXNzaW9uIGl0IHNlZW1zIHRvIG1lIHRoYXQg dGhlIGN1cnJlbnQgZWRpdG9yIGRyYWZ0IGh0dHBzOi8vY29yZS13Zy5naXRodWIuaW8vZXRjaC8g Y29udGFpbnMgYWxsIHRoZSByZXF1aXJlZCBtb2RpZmljYXRpb25zLg0KV2Ugd2lsbCBhbHNvIGhh dmUgYSBzbG90IGZvciBkaXNjdXNzaW5nIGR1cmluZyB0aGUgVHVlc2RheSBzZXNzaW9uLiBUaGUg YXV0aG9ycyBzaG91bGQgdGhlbiBzdWJtaXQgdGhlIG5ldyB2ZXJzaW9uIGFmdGVyIElFVEYuDQoN CkNpYW8sDQotIC0gSmFpbWUgSmltZW5leg0K --_000_0EDF6F2085864114BA0C1C8BAC19E3E7ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0F58B8F026C12542BFF00B24565CC176@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZnJvbSB0aGUgZW1haWwgZGlz Y3Vzc2lvbiBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBjdXJyZW50IGVkaXRvciBkcmFmdCZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vY29yZS13Zy5naXRodWIuaW8vZXRjaC8iIGNsYXNzPSIiPmh0dHBz Oi8vY29yZS13Zy5naXRodWIuaW8vZXRjaC88L2E+Jm5ic3A7Y29udGFpbnMgYWxsIHRoZSByZXF1 aXJlZCBtb2RpZmljYXRpb25zLiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSB3 aWxsIGFsc28gaGF2ZSBhIHNsb3QgZm9yIGRpc2N1c3NpbmcgZHVyaW5nIHRoZSBUdWVzZGF5IHNl c3Npb24uIFRoZSBhdXRob3JzIHNob3VsZCB0aGVuIHN1Ym1pdCB0aGUgbmV3IHZlcnNpb24gYWZ0 ZXIgSUVURi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkNpYW8sPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tIC0gSmFp bWUgSmltZW5lejwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0EDF6F2085864114BA0C1C8BAC19E3E7ericssoncom_-- From nobody Tue Jul 12 02:42:35 2016 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 F084712D784; Tue, 12 Jul 2016 02:42:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 3y0zzMXQmTvy; Tue, 12 Jul 2016 02:42:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B352F12D783; Tue, 12 Jul 2016 02:42:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-4d-5784bb83fd92 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.59.18043.38BB4875; Tue, 12 Jul 2016 11:42:27 +0200 (CEST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 12 Jul 2016 11:42:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GbPkw+vRyzxr7l6LVHj3MT71xI6lqxCfDtvXNFwWHiI=; b=UoenGxNof3riV0NOSn8KSrOOv7iGT1gr0XwWxycj3bxP6HOvQyEAmWzYFJNYEoPO2KvY3IRiCx0FU3sspWADnqOlnH7Xse6mTUD5oPKp9XRMS3MwGE3+OF+wXXnbJVW9cBWgpTBYg1O31+kgSckTuQPRSuMAuea9E1w/1BIwp/A= Received: from AMXPR07MB070.eurprd07.prod.outlook.com (10.242.70.148) by AMXPR07MB069.eurprd07.prod.outlook.com (10.242.70.147) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 12 Jul 2016 09:42:25 +0000 Received: from AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) by AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) with mapi id 15.01.0528.026; Tue, 12 Jul 2016 09:42:26 +0000 From: Francesca Palombini To: Marco Tiloca Thread-Topic: [COSE] [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt Thread-Index: AQHR2G3dJR4k7DwmmE2nHZmL8yaTPqAOF8bQgAUzcwCAAS6UIIAAFDEAgAAD21A= Date: Tue, 12 Jul 2016 09:42:25 +0000 Message-ID: References: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [80.216.62.213] x-ms-office365-filtering-correlation-id: f9a375e9-d489-4371-d1ab-08d3aa38d528 x-microsoft-exchange-diagnostics: 1; AMXPR07MB069; 6:udC+tssMHPABxBpzhg1RQ4VC6ib0CuEIJsVEJRHCV1WPLItssApoZG11UqFQdYtDiNiV5sWfwBtFMNcSHg0bu+PYXtsG/B4aA+z34Nuou8E3yvo1rXYyzS3wvM6bt8AfceXlxjqZGjUDVeMrN0mjAbZ/f6K7NOtBo7YJCPXy9d7RqDSyhg081wGweRqXoXSgkxPNdhy8EtgL2l0CUqyX63U8BiRJsGEx+MyTOEDz9T8A5Smmpggl3OQEBFDsjOFwXfIaLFkDzUxw0p9n6cYoBENHQZa0jNGUNtrUEJcu58w=; 5:rTXPBmRecpTn5C00HbgsjauKDm3r0ogKh5oSpvSWvDyGOYmSDr6zP4XSCQDcv5iM9b3COAnPgRRliJR/B52+DACbv/Ebk3ije07JX/9fgDs8nLgWA7Z/AYqstRGRcuXLq0mEd3muxFi0N7dgIK+SEQ==; 24:sW3sHKCej4SJNCrqz77d8C49bmFdA3HByOKYfrhbJm4ks0xuMI6s0rmSopOSUssENN8ymQAHyntSxagtA5CLXxb+RZADmUU0rRcPvvWUUME=; 7:VD13/v2M52RJUEt0k7npmYk/CNE38IhLHgVDcA5ll75oC02KBGZEbUy/XTbgvEqtXHTHBWPCt4iHonG4EUqvd//NaifGYm1rMuba3bVXCSFumQGVYMDCWIz5i3RR/zWrpt5CyoBq/BzB530WTD6CtPDrJVIH4gTN69rYbHtXU51FIHvq2D6SqFYpMXD1ft2XtlRusdPPXyffOi64zI9dOw+ib0Ws+iE4HqMjmzROz0/H+RgUeSGAGYgqKpDdxdJU x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB069; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(120809045254105)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMXPR07MB069; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB069; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(13464003)(189002)(377454003)(199003)(377424004)(24454002)(101416001)(2906002)(106356001)(54356999)(93886004)(50986999)(19617315012)(105586002)(106116001)(76176999)(16601075003)(19580395003)(7696003)(3660700001)(7736002)(5003600100003)(2420400007)(19580405001)(68736007)(19609705001)(7846002)(9326002)(81166006)(230783001)(7906003)(3280700002)(81156014)(19625215002)(74316002)(8936002)(15650500001)(19300405004)(8676002)(33656002)(92566002)(110136002)(14971765001)(122556002)(4326007)(86362001)(189998001)(87936001)(6116002)(790700001)(16236675004)(10400500002)(102836003)(3846002)(97736004)(10710500007)(7110500001)(76576001)(2900100001)(2950100001)(15975445007)(66066001)(9686002)(586003)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB069; H:AMXPR07MB070.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMXPR07MB070E936BD38CE40EC1E4D9798300AMXPR07MB070eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 09:42:25.8354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB069 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUyM2K7sW7z7pZwg1OzjSy+f+thttj3dj2z xbStU1kt5qzdy+bA4rFkyU8mj95jv9kCmKK4bFJSczLLUov07RK4Ms5+f8lasKiHqWLHxgcs DYxzWpm6GDk5JARMJGafXMkOYYtJXLi3nq2LkYtDSOAIo0T7mldQzglGiRm9v5lBHBaBXmaJ Sb97oTJXGCVebNnDCOEcY5TourQbbDCbgI3EhYfvWUFsEQEFiY0zO5hBbGaBVInZNzqB4hwc wgJpEv39URAl6RK98+ewQNh+EvOOnwW7iUVAVaJhynYwm1cgSuLsxnfsELs+Mkkc3zuRESTB KRAo8XffKbAiRqAnvp9awwSxS1zi1pP5UI8KSCzZc54ZwhaVePn4HytEfbLEldt90ABQlPja uJcNwvaVeNjfCfayhMBbNom2bzOgml0lpjbcgBqaKXF//RJWCLtW4mXrJDaIhrXAkFi0F2qq jMS2N5eZIBJN7BIP5/8A6xYCBsXyta2MExi1ZiG5FsLOl/j59i7zLLC3BSVOznzCMgsYYswC mhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZg ajq45bfVDsaDzx0PMQpwMCrx8C641xwuxJpYVlyZe4hRgoNZSYRXcGdLuBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQbGMBO3Tx++3pZP/Vf69Lz/PLk3 K698eWT9J0BN6aIg9+KYZAGmWomQvJ0NGQc2W2+PvNKZwFfkqiKWwveea8GTud7v51k+ifF5 Wx+r5XTWvqP7m/UazxTG6zf4XH/yX1JQDPH7k+c053fu9zz9o70Vmy5U//lateCnxtLrNXqn JtfzJ6aKF7krsRRnJBpqMRcVJwIAd5PNAUkDAAA= Archived-At: Cc: "cose@ietf.org" , "core@ietf.org" , "Ace@ietf.org" Subject: Re: [core] [COSE] [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 09:42:33 -0000 --_000_AMXPR07MB070E936BD38CE40EC1E4D9798300AMXPR07MB070eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyY28sDQoNCk9rLCBpdOKAmXMgbm90ZWQuIFdlIHdpbGwgaW5jbHVkZSB5b3VyIGNvbW1l bnRzIHZlcnkgc29vbi4NCg0KVGhhbmsgeW91IGFnYWluIQ0KRnJhbmNlc2NhDQoNCkZyb206IENP U0UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJjbyBUaWxv Y2ENClNlbnQ6IGRlbiAxMiBqdWxpIDIwMTYgMTE6MjYNClRvOiBGcmFuY2VzY2EgUGFsb21iaW5p IDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NCkNjOiBBY2VAaWV0Zi5vcmc7IGNv cmVAaWV0Zi5vcmc7IGNvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ09TRV0gW0FjZV0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1z ZWN1cml0eS0wNS50eHQNCg0KSGkgRnJhbmNlc2NhLA0KDQpPbiBUdWUsIEp1bCAxMiwgMjAxNiBh dCAxMDoxNCBBTSwgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmlj c3Nvbi5jb208bWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQpIaSBNYXJjbywNCg0KVGhhbmsgeW91IHNvIG11Y2ggZm9yIGFuIGV4dGVuZGVkIHJldmlldyEg SSBhZ3JlZSB3aXRoIGFsbCB5b3VyIGNvbW1lbnRzIGFuZCBJIHRoaW5rIHRoZXkgd2lsbCBpbXBy b3ZlIHRoZSByZWFkYWJpbGl0eSBvZiB0aGUgZHJhZnQuDQpJIGp1c3QgaGF2ZSBhIHF1ZXN0aW9u IGZvciAxKToNCg0KV2UgaW50cm9kdWNlIHRoZSB1c2Ugb2YgQ09TRSBvYmplY3RzIGFscmVhZHkg aW4gU2VjdGlvbiAxLiBJbnRyb2R1Y3Rpb24sIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBwYWdl IDMgKOKAnE9TQ09BUCBidWlsZHMgb24gQ0JPUiBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlwdGlv biAoQ09TRSkg4oCm4oCdKS4gV2FzIHRoZXJlIGEgcmVhc29uIHdoeSB5b3Ugd2FudGVkIGl0IG1l bnRpb25lZCBpbiB0aGUgT2JqZWN0IFNlY3VyaXR5IG9wdGlvbiBzZWN0aW9uLCBzcGVjaWZpY2Fs bHk/DQoNCkkgc3VnZ2VzdGVkIHRoYXQganVzdCBmb3IgdGhlIHNha2Ugb2YgcmVhZGFiaWxpdHku IFRoZSBDT1NFIG9iamVjdCBpcyBpbnRyb2R1Y2VkIGluIFNlY3Rpb24gMSwgYnV0IHRoZW4gSSB0 aG91Z2h0IGFib3V0IGEgcmVhZGVyIHN0YXJ0aW5nIGRpcmVjdGx5IGZyb20gdGhlIGFjdHVhbCBz cGVjaWZpY2F0aW9uIGluIFNlY3Rpb24gMiwgd2hlcmUgdGhlIENPU0Ugb2JqZWN0ICJzdWRkZW5s eSByZWFwcGVhcnMiIGF0IHRoZSBlbmQgb2YgcGFnZSA1LCBhbmQgaXMgb2YgY291cnNlIGRldGFp bGVkIG9ubHkgbGF0ZXIgaW4gU2VjdGlvbiA1Lg0KDQpUaGlzIGlzIHdoeSBJIGJlbGlldmUgaXQg d291bGQgYmUgZ29vZCB0byBxdWlja2x5IG1lbnRpb24gYWdhaW4gdGhlIHVzYWdlIG9mIENPU0Ug b2JqZWN0cyBhdCB0aGUgYmVnaW5uaW5nIG9mIFNlY3Rpb24gMiwganVzdCBmcm9tIGEgaGlnaC1s ZXZlbCBwZXJzcGVjdGl2ZSBhcyBpbiB0aGUgSW50cm9kdWN0aW9uIGFuZCBhbHNvIHBvaW50aW5n IHRvIFNlY3Rpb24gNSBmb3IgZnVydGhlciBkZXRhaWxzLCBzbyBiZXR0ZXIgcHJlcGFyaW5nIHRo ZSByZWFkZXIgZm9yIHRoZSAyLWVsZW1lbnQgYnVsbGV0IGxpc3QgYXQgdGhlIGVuZCBvZiBwYWdl IDUuDQpCZXN0IHJlZ2FyZHMsDQpNYXJjbw0KDQoNCkJlc3QsDQpGcmFuY2VzY2ENCg0KDQpGcm9t OiBNYXJjbyBUaWxvY2EgW21haWx0bzptYXJjb0BzaWNzLnNlPG1haWx0bzptYXJjb0BzaWNzLnNl Pl0NClNlbnQ6IGRlbiAxMSBqdWxpIDIwMTYgMTY6MTENClRvOiBGcmFuY2VzY2EgUGFsb21iaW5p IDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbTxtYWlsdG86ZnJhbmNlc2NhLnBhbG9t YmluaUBlcmljc3Nvbi5jb20+Pg0KQ2M6IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5v cmc+OyBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPjsgQWNlQGlldGYub3JnPG1h aWx0bzpBY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjZV0gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50eHQN Cg0KSGVsbG8gRnJhbmNlc2NhIGFuZCBhbGwsDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGxhc3Qg dmVyc2lvbiBhbmQgSSBiZWxpZXZlIGl0IGlzIGluIGEgdmVyeSBnb29kIHNoYXBlIQ0KDQpQbGVh c2UsIGZpbmQgYmVsb3cgc29tZSBzdWdnZXN0aW9ucyBmb3IgbWlub3IgY2hhbmdlcy91cGRhdGVz Lg0KDQpCZXN0IHJlZ2FyZHMsDQovTWFyY28NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoxKSBJbiBTZWN0aW9uIDIsIEkgd291bGQgcmVmZXIgdGhlIHVzYWdlIG9mIGEgQ09TRSBv YmplY3QgYXMgc29vbiBhcyBwb3NzaWJsZSwgcmF0aGVyIHRoYW4gYXQgdGhlIGVuZCBvZiBwYWdl IDUgd2hlcmUgeW91IGRlc2NyaWJlIGhvdyB0byBwcmVwYXJlIHRoZSBwcm90ZWN0ZWQgQ29BUCBt ZXNzYWdlLiBGb3IgaW5zdGFuY2UsIHRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlIGluIFNlY3Rpb24g MiBjYW4gYmUgZm9sbG93ZWQgYnkgc29tZXRoaW5nIGxpa2U6ICJUaGlzIGlzIGFjaGlldmVkIGJ5 IG1lYW5zIG9mIGEgQ09TRSBvYmplY3QgaW5jbHVkZWQgaW4gdGhlIHByb3RlY3RlZCBDb0FQIG1l c3NhZ2UsIGFzIGRldGFpbGVkIGJlbG93Ii4NCg0KMikgSW4gU2VjdGlvbiAyIChwYWdlIDUpLCBJ IHdvdWxkIG1vdmUgdGhlIHNlbnRlbmNlICJBbiBlbmRwb2ludCByZWNlaXZpbmcgWy4uLl0gdHJl YXQgaXQgYXMgbWFsZm9ybWVkIGFuZCByZWplY3QgaXQuIiBhdCB0aGUgZW5kIG9mIHRoZSBmaXJz dCBlbGVtZW50IG9mIHRoZSBidWxsZXQgbGlzdCBiZWxvdywgc2luY2UgaXQgY29uY2VybnMgQ29B UCBtZXNzYWdlcyB3aXRoIHBheWxvYWQuDQoNCjMpIEZvbGxvd2luZyB0aGUgc2FtZSByZWFzb25p bmcgb2YgcG9pbnQgMiksIEkgd291bGQgZXh0ZW5kIHRoZSBzZWNvbmQgZWxlbWVudCBpbiB0aGUg ZG90dGVkIGxpc3QgYXQgdGhlIGVuZCBvZiBwYWdlIDUgd2l0aDogIkFuIGVuZHBvaW50IHJlY2Vp dmluZyBhIENvQVAgbWVzc2FnZSB3aXRob3V0IHBheWxvYWQsIHRoYXQgYWxzbyBjb250YWlucyBh biBlbXB0eSBPYmplY3QtU2VjdXJpdHkgb3B0aW9uIFNIQUxMIHRyZWF0IGl0IGFzIG1hbGZvcm1l ZCBhbmQgcmVqZWN0IGl0Ii4NCg0KNCkgU2VjdGlvbiAzLjEsIHBhZ2UgNiwgIlRoZSBlbmRwb2lu dCB2ZXJpZmllcyB0aGUgbWVzc2FnZSByZWNlaXZlZCIgLS0+ICJUaGUgZW5kcG9pbnQgdmVyaWZp ZXMgdGhlIG1lc3NhZ2VzIHJlY2VpdmVkIi4NCg0KNSkgU2VjdGlvbiA1LCBwYWdlIDEzLCBhZGQg IihzZWUgU2VjdGlvbiA1LjEpIiBhZnRlciAiaXMgY29tcHV0ZWQgZnJvbSB0aGUgUGxhaW50ZXh0 IiwgYW5kICIoc2VlIFNlY3Rpb24gNS4yKSIgYWZ0ZXIgImFuZCB0aGUgQWRkaXRpb25hbCBBdXRo ZW50aWNhdGVkIERhdGEgKEFBRCkiLg0KDQo2KSBTZWN0aW9uIDYuMiwgcGFnZSAxNiwgc3RlcCAx LiBJbiB0aGUgbGFzdCBzZW50ZW5jZXMgYWJvdXQgcmVuZXdpbmcgdGhlIHNlY3VyaXR5IGNvbnRl eHQgb24gdGhlIGNsaWVudCwgaXQgd291bGQgYmUgZ29vZCB0byBtZW50aW9uIGFsc28gdGhhdCB0 aGlzIGludm9sdmVzIGluZm9ybWluZyB0aGUgc2VydmVyLCBzbyB0aGF0IGl0IGNhbiB1cGRhdGUg aXRzIG93biBSZWNlaXZlci0qIHBhcmFtZXRlcnMgb24gaXRzIG93biBjb250ZXh0Lg0KDQo3KSBT ZWN0aW9uIDYuMiwgcGFnZSAxNiwgc3RlcCAyLiAiU3RvcmUgdGhlIE1BQyBvZiBlYWNoIGZyYWdt ZW50IiAtLT4gIlN0b3JlIHRoZSBNQUMgb2YgZWFjaCBsYXN0LXNlbnQgZnJhZ21lbnQiLg0KDQo4 KSBTZWN0aW9uIDYuMywgcGFnZSAxNywgc3RlcCAyLiAiU3RvcmUgdGhlIE1BQyBvZiBlYWNoIGZy YWdtZW50IiAtLT4gIlN0b3JlIHRoZSBNQUMgb2YgZWFjaCBsYXN0LXJlY2VpdmVkIGZyYWdtZW50 Ii4NCg0KOSkgU2VjdGlvbiA2LjQsIHBhZ2UgMTgsIHN0ZXAgMS4gSW4gdGhlIGxhc3Qgc2VudGVu Y2VzIGFib3V0IHJlbmV3aW5nIHRoZSBzZWN1cml0eSBjb250ZXh0IG9uIHRoZSBzZXJ2ZXIsIGl0 IHdvdWxkIGJlIGdvb2QgdG8gbWVudGlvbiBhbHNvIHRoYXQgdGhpcyBpbnZvbHZlcyBpbmZvcm1p bmcgdGhlIGNsaWVudCwgc28gdGhhdCBpdCBjYW4gdXBkYXRlIGl0cyBvd24gUmVjZWl2ZXItKiBw YXJhbWV0ZXJzIG9uIGl0cyBvd24gY29udGV4dC4NCg0KMTApIFNlY3Rpb24gNi40LCBwYWdlIDE4 LCBzdGVwIDIuICJTdG9yZSB0aGUgTUFDIG9mIGVhY2ggZnJhZ21lbnQiIC0tPiAiU3RvcmUgdGhl IE1BQyBvZiBlYWNoIGxhc3Qtc2VudCBmcmFnbWVudCIuDQoNCjExKSBTZWN0aW9uIDYuNSwgcGFn ZSAxOSwgc3RlcCAyLiAiU3RvcmUgdGhlIE1BQyBvZiBlYWNoIGZyYWdtZW50IiAtLT4gIlN0b3Jl IHRoZSBNQUMgb2YgZWFjaCBsYXN0LXJlY2VpdmVkIGZyYWdtZW50Ii4NCg0KMTIpIFNlY3Rpb24g Ni41LCBwYWdlIDIwLCBmaXJzdCBwYXJhZ3JhcGguIEFmdGVyIHRoZSBsYXN0IHNlbnRlbmNlICJE VExTIGFuZCBPU0NPQVAgY2FuIGJlIGNvbWJpbmVkIiwgSSB3b3VsZCByZXN0YXRlIHdoYXQgc2Fp ZCBpbiBTZWN0aW9uIDEgKHBhZ2UgNCksIHRoYXQgaXMgInRoZXJlYnkgZW5hYmxpbmcgZW5kLXRv LWVuZCAuLi4iDQoNCjEzKSBTZWN0aW9uIDYuNSwgcGFnZSAyMCwgdGhpcmQgcGFyYWdyYXBoLiAi VGhlIHVzZSBvZiBDT1NFIHRvIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2VzIiAtLT4gIlRoZSB1c2Ug b2YgQ09TRSB0byBwcm90ZWN0IENvQVAgbWVzc2FnZXMiDQoNCk9uIEZyaSwgSnVsIDgsIDIwMTYg YXQgOTowMyBBTSwgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmlj c3Nvbi5jb208bWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQpEZWFyIENvUkUsIENPU0UgYW5kIEFDRSBtZW1iZXJzLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBh biB1cGRhdGUgdG8gdGhlIE9TQ09BUCBkcmFmdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1DQoNCkZvciB0aG9zZSB3aG8g ZG9u4oCZdCBrbm93LCBPU0NPQVAgaXMgYW4gYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJpdHkgcHJv dG9jb2wgZm9yIENvQVAsIGJhc2VkIG9uIHdyYXBwaW5nIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1l c3NhZ2VzIGluIENPU0Ugb2JqZWN0cyB3aGljaCBhcmUgc2VudCBpbiBhIENvQVAgbWVzc2FnZSBl eGNoYW5nZS4NCg0KV2l0aCB0aGlzIHZlcnNpb24sIHdlIGFpbWVkIGZvciBpbXByb3ZlZCByZWFk YWJpbGl0eSBhbmQgd2UgYWRkZWQgdGhlIGJsb2Nrd2lzZSBmdW5jdGlvbmFsaXR5LCBhcyBkaXNj dXNzZWQgZHVyaW5nIGxhc3QgZjJmIG1lZXRpbmcuDQoNCldlIGFyZSBub3cgbG9va2luZyBmb3Ig cmV2aWV3cy4gQW55IGNvbW1lbnQgb3IgZmVlZGJhY2sgd291bGQgYmUgZ3JlYXRseSBhcHByZWNp YXRlZCENCg0KQmVzdCByZWdhcmRzLA0KRnJhbmNlc2NhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpTZW50OiBkZW4gNyBqdWxpIDIwMTYgMTg6MzcNClRv OiBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTxtYWlsdG86Z29y YW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj47IEx1ZHdpZyBTZWl0eiA8bHVkd2lnQHNpY3Muc2U8 bWFpbHRvOmx1ZHdpZ0BzaWNzLnNlPj47IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJp Y3Nzb24uY29tPG1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4+OyBHw7ZyYW4gU2Vs YW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPj47IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlA ZXJpY3Nzb24uY29tPG1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4+DQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNlbGFuZGVyLWFjZS1v YmplY3Qtc2VjdXJpdHktMDUudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNl bGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEZyYW5jZXNjYSBQYWxvbWJpbmkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1z ZWN1cml0eQ0KUmV2aXNpb246ICAgICAgIDA1DQpUaXRsZTogICAgICAgICAgT2JqZWN0IFNlY3Vy aXR5IG9mIENvQVAgKE9TQ09BUCkNCkRvY3VtZW50IGRhdGU6ICAyMDE2LTA3LTA3DQpHcm91cDog ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMzYNClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Vs YW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3Vy aXR5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z ZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJp dHktMDUNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVmaW5lcyBPYmplY3QgU2VjdXJpdHkg b2YgQ29BUCAoT1NDT0FQKSwgYSBtZXRob2QgZm9yDQogICBhcHBsaWNhdGlvbiBsYXllciBwcm90 ZWN0aW9uIG9mIG1lc3NhZ2UgZXhjaGFuZ2VzIHdpdGggdGhlDQogICBDb25zdHJhaW5lZCBBcHBs aWNhdGlvbiBQcm90b2NvbCAoQ29BUCksIHVzaW5nIHRoZSBDQk9SIE9iamVjdA0KICAgU2lnbmlu ZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkgZm9ybWF0LiAgT1NDT0FQIHByb3ZpZGVzIGVuZC10by1l bmQNCiAgIGVuY3J5cHRpb24sIGludGVncml0eSBhbmQgcmVwbGF5IHByb3RlY3Rpb24gdG8gQ29B UCBwYXlsb2FkLCBvcHRpb25zLA0KICAgYW5kIGhlYWRlciBmaWVsZHMsIGFzIHdlbGwgYXMgYSBz ZWN1cmUgYmluZGluZyBiZXR3ZWVuIENvQVAgcmVxdWVzdA0KICAgYW5kIHJlc3BvbnNlIG1lc3Nh Z2VzLiAgVGhlIHVzZSBvZiBPU0NPQVAgaXMgc2lnbmFsZWQgd2l0aCB0aGUgQ29BUA0KICAgb3B0 aW9uIE9iamVjdC1TZWN1cml0eSwgYWxzbyBkZWZpbmVkIGluIHRoaXMgbWVtby4NCg0KDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFj ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoN Cg0K --_000_AMXPR07MB070E936BD38CE40EC1E4D9798300AMXPR07MB070eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIE1hcmNvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PaywgaXTi gJlzIG5vdGVkLiBXZSB3aWxsIGluY2x1ZGUgeW91ciBjb21tZW50cyB2ZXJ5IHNvb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlRoYW5rIHlvdSBhZ2FpbiE8YnI+DQpGcmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENPU0UgW21haWx0bzpjb3NlLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmNvIFRpbG9jYTxicj4NCjxi PlNlbnQ6PC9iPiBkZW4gMTIganVsaSAyMDE2IDExOjI2PGJyPg0KPGI+VG86PC9iPiBGcmFuY2Vz Y2EgUGFsb21iaW5pICZsdDtmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IEFjZUBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZzsgY29zZUBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NPU0VdIFtBY2VdIEZXOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRnJhbmNlc2NhLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDEyLCAyMDE2IGF0IDEw OjE0IEFNLCBGcmFuY2VzY2EgUGFsb21iaW5pICZsdDs8YSBocmVmPSJtYWlsdG86ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5mcmFuY2VzY2EucGFsb21i aW5pQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkhpIE1hcmNvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91IHNvIG11Y2ggZm9yIGFuIGV4 dGVuZGVkIHJldmlldyEgSSBhZ3JlZSB3aXRoIGFsbCB5b3VyIGNvbW1lbnRzIGFuZCBJIHRoaW5r IHRoZXkgd2lsbCBpbXByb3ZlIHRoZSByZWFkYWJpbGl0eQ0KIG9mIHRoZSBkcmFmdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SSBqdXN0IGhhdmUgYSBxdWVzdGlvbiBmb3IgMSk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBpbnRy b2R1Y2UgdGhlIHVzZSBvZiBDT1NFIG9iamVjdHMgYWxyZWFkeSBpbiBTZWN0aW9uIDEuIEludHJv ZHVjdGlvbiwgaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHBhZ2UgMyAo4oCcT1NDT0FQDQogYnVp bGRzIG9uIENCT1IgT2JqZWN0IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24gKENPU0UpIOKApuKAnSku IFdhcyB0aGVyZSBhIHJlYXNvbiB3aHkgeW91IHdhbnRlZCBpdCBtZW50aW9uZWQgaW4gdGhlIE9i amVjdCBTZWN1cml0eSBvcHRpb24gc2VjdGlvbiwgc3BlY2lmaWNhbGx5Pzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgc3VnZ2VzdGVkIHRo YXQganVzdCBmb3IgdGhlIHNha2Ugb2YgcmVhZGFiaWxpdHkuIFRoZSBDT1NFIG9iamVjdCBpcyBp bnRyb2R1Y2VkIGluIFNlY3Rpb24gMSwgYnV0IHRoZW4gSSB0aG91Z2h0IGFib3V0IGEgcmVhZGVy IHN0YXJ0aW5nIGRpcmVjdGx5IGZyb20gdGhlIGFjdHVhbCBzcGVjaWZpY2F0aW9uIGluIFNlY3Rp b24gMiwgd2hlcmUgdGhlIENPU0Ugb2JqZWN0DQogJnF1b3Q7c3VkZGVubHkgcmVhcHBlYXJzJnF1 b3Q7IGF0IHRoZSBlbmQgb2YgcGFnZSA1LCBhbmQgaXMgb2YgY291cnNlIGRldGFpbGVkIG9ubHkg bGF0ZXIgaW4gU2VjdGlvbiA1Ljxicj4NCjxicj4NClRoaXMgaXMgd2h5IEkgYmVsaWV2ZSBpdCB3 b3VsZCBiZSBnb29kIHRvIHF1aWNrbHkgbWVudGlvbiBhZ2FpbiB0aGUgdXNhZ2Ugb2YgQ09TRSBv YmplY3RzIGF0IHRoZSBiZWdpbm5pbmcgb2YgU2VjdGlvbiAyLCBqdXN0IGZyb20gYSBoaWdoLWxl dmVsIHBlcnNwZWN0aXZlIGFzIGluIHRoZSBJbnRyb2R1Y3Rpb24gYW5kIGFsc28gcG9pbnRpbmcg dG8gU2VjdGlvbiA1IGZvciBmdXJ0aGVyIGRldGFpbHMsIHNvIGJldHRlciBwcmVwYXJpbmcgdGhl IHJlYWRlcg0KIGZvciB0aGUgMi1lbGVtZW50IGJ1bGxldCBsaXN0IGF0IHRoZSBlbmQgb2YgcGFn ZSA1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TWFyY288bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyYW5jZXNjYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IE1hcmNvIFRpbG9jYSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJjb0BzaWNzLnNlIiB0 YXJnZXQ9Il9ibGFuayI+bWFyY29Ac2ljcy5zZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVu IDExIGp1bGkgMjAxNiAxNjoxMTxicj4NCjxiPlRvOjwvYj4gRnJhbmNlc2NhIFBhbG9tYmluaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4N CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5jb3JlQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCmNvc2VAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86QWNlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0FjZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2VsYW5k ZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZWxsbyBGcmFuY2VzY2EgYW5kIGFsbCw8YnI+ DQo8YnI+DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBsYXN0IHZlcnNpb24gYW5kIEkgYmVsaWV2ZSBp dCBpcyBpbiBhIHZlcnkgZ29vZCBzaGFwZSE8YnI+DQo8YnI+DQpQbGVhc2UsIGZpbmQgYmVsb3cg c29tZSBzdWdnZXN0aW9ucyBmb3IgbWlub3IgY2hhbmdlcy91cGRhdGVzLjxicj4NCjxicj4NCkJl c3QgcmVnYXJkcyw8YnI+DQovTWFyY288YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KPGJyPg0KMSkgSW4gU2VjdGlvbiAyLCBJIHdvdWxkIHJlZmVyIHRoZSB1c2Fn ZSBvZiBhIENPU0Ugb2JqZWN0IGFzIHNvb24gYXMgcG9zc2libGUsIHJhdGhlciB0aGFuIGF0IHRo ZSBlbmQgb2YgcGFnZSA1IHdoZXJlIHlvdSBkZXNjcmliZSBob3cgdG8gcHJlcGFyZSB0aGUgcHJv dGVjdGVkIENvQVAgbWVzc2FnZS4gRm9yIGluc3RhbmNlLCB0aGUgdmVyeSBmaXJzdCBzZW50ZW5j ZSBpbiBTZWN0aW9uIDIgY2FuIGJlIGZvbGxvd2VkIGJ5IHNvbWV0aGluZyBsaWtlOg0KICZxdW90 O1RoaXMgaXMgYWNoaWV2ZWQgYnkgbWVhbnMgb2YgYSBDT1NFIG9iamVjdCBpbmNsdWRlZCBpbiB0 aGUgcHJvdGVjdGVkIENvQVAgbWVzc2FnZSwgYXMgZGV0YWlsZWQgYmVsb3cmcXVvdDsuPGJyPg0K PGJyPg0KMikgSW4gU2VjdGlvbiAyIChwYWdlIDUpLCBJIHdvdWxkIG1vdmUgdGhlIHNlbnRlbmNl ICZxdW90O0FuIGVuZHBvaW50IHJlY2VpdmluZyBbLi4uXSB0cmVhdCBpdCBhcyBtYWxmb3JtZWQg YW5kIHJlamVjdCBpdC4mcXVvdDsgYXQgdGhlIGVuZCBvZiB0aGUgZmlyc3QgZWxlbWVudCBvZiB0 aGUgYnVsbGV0IGxpc3QgYmVsb3csIHNpbmNlIGl0IGNvbmNlcm5zIENvQVAgbWVzc2FnZXMgd2l0 aCBwYXlsb2FkLjxicj4NCjxicj4NCjMpIEZvbGxvd2luZyB0aGUgc2FtZSByZWFzb25pbmcgb2Yg cG9pbnQgMiksIEkgd291bGQgZXh0ZW5kIHRoZSBzZWNvbmQgZWxlbWVudCBpbiB0aGUgZG90dGVk IGxpc3QgYXQgdGhlIGVuZCBvZiBwYWdlIDUgd2l0aDogJnF1b3Q7QW4gZW5kcG9pbnQgcmVjZWl2 aW5nIGEgQ29BUCBtZXNzYWdlIHdpdGhvdXQgcGF5bG9hZCwgdGhhdCBhbHNvIGNvbnRhaW5zIGFu IGVtcHR5IE9iamVjdC1TZWN1cml0eSBvcHRpb24gU0hBTEwgdHJlYXQgaXQgYXMgbWFsZm9ybWVk DQogYW5kIHJlamVjdCBpdCZxdW90Oy48YnI+DQo8YnI+DQo0KSBTZWN0aW9uIDMuMSwgcGFnZSA2 LCAmcXVvdDtUaGUgZW5kcG9pbnQgdmVyaWZpZXMgdGhlIG1lc3NhZ2UgcmVjZWl2ZWQmcXVvdDsg LS0mZ3Q7ICZxdW90O1RoZSBlbmRwb2ludCB2ZXJpZmllcyB0aGUgbWVzc2FnZXMgcmVjZWl2ZWQm cXVvdDsuPGJyPg0KPGJyPg0KNSkgU2VjdGlvbiA1LCBwYWdlIDEzLCBhZGQgJnF1b3Q7KHNlZSBT ZWN0aW9uIDUuMSkmcXVvdDsgYWZ0ZXIgJnF1b3Q7aXMgY29tcHV0ZWQgZnJvbSB0aGUgUGxhaW50 ZXh0JnF1b3Q7LCBhbmQgJnF1b3Q7KHNlZSBTZWN0aW9uIDUuMikmcXVvdDsgYWZ0ZXIgJnF1b3Q7 YW5kIHRoZSBBZGRpdGlvbmFsIEF1dGhlbnRpY2F0ZWQgRGF0YSAoQUFEKSZxdW90Oy48YnI+DQo8 YnI+DQo2KSBTZWN0aW9uIDYuMiwgcGFnZSAxNiwgc3RlcCAxLiBJbiB0aGUgbGFzdCBzZW50ZW5j ZXMgYWJvdXQgcmVuZXdpbmcgdGhlIHNlY3VyaXR5IGNvbnRleHQgb24gdGhlIGNsaWVudCwgaXQg d291bGQgYmUgZ29vZCB0byBtZW50aW9uIGFsc28gdGhhdCB0aGlzIGludm9sdmVzIGluZm9ybWlu ZyB0aGUgc2VydmVyLCBzbyB0aGF0IGl0IGNhbiB1cGRhdGUgaXRzIG93biBSZWNlaXZlci0qIHBh cmFtZXRlcnMgb24gaXRzIG93biBjb250ZXh0Ljxicj4NCjxicj4NCjcpIFNlY3Rpb24gNi4yLCBw YWdlIDE2LCBzdGVwIDIuICZxdW90O1N0b3JlIHRoZSBNQUMgb2YgZWFjaCBmcmFnbWVudCZxdW90 OyAtLSZndDsgJnF1b3Q7U3RvcmUgdGhlIE1BQyBvZiBlYWNoIGxhc3Qtc2VudCBmcmFnbWVudCZx dW90Oy48YnI+DQo8YnI+DQo4KSBTZWN0aW9uIDYuMywgcGFnZSAxNywgc3RlcCAyLiAmcXVvdDtT dG9yZSB0aGUgTUFDIG9mIGVhY2ggZnJhZ21lbnQmcXVvdDsgLS0mZ3Q7ICZxdW90O1N0b3JlIHRo ZSBNQUMgb2YgZWFjaCBsYXN0LXJlY2VpdmVkIGZyYWdtZW50JnF1b3Q7Ljxicj4NCjxicj4NCjkp IFNlY3Rpb24gNi40LCBwYWdlIDE4LCBzdGVwIDEuIEluIHRoZSBsYXN0IHNlbnRlbmNlcyBhYm91 dCByZW5ld2luZyB0aGUgc2VjdXJpdHkgY29udGV4dCBvbiB0aGUgc2VydmVyLCBpdCB3b3VsZCBi ZSBnb29kIHRvIG1lbnRpb24gYWxzbyB0aGF0IHRoaXMgaW52b2x2ZXMgaW5mb3JtaW5nIHRoZSBj bGllbnQsIHNvIHRoYXQgaXQgY2FuIHVwZGF0ZSBpdHMgb3duIFJlY2VpdmVyLSogcGFyYW1ldGVy cyBvbiBpdHMgb3duIGNvbnRleHQuPGJyPg0KPGJyPg0KMTApIFNlY3Rpb24gNi40LCBwYWdlIDE4 LCBzdGVwIDIuICZxdW90O1N0b3JlIHRoZSBNQUMgb2YgZWFjaCBmcmFnbWVudCZxdW90OyAtLSZn dDsgJnF1b3Q7U3RvcmUgdGhlIE1BQyBvZiBlYWNoIGxhc3Qtc2VudCBmcmFnbWVudCZxdW90Oy48 YnI+DQo8YnI+DQoxMSkgU2VjdGlvbiA2LjUsIHBhZ2UgMTksIHN0ZXAgMi4gJnF1b3Q7U3RvcmUg dGhlIE1BQyBvZiBlYWNoIGZyYWdtZW50JnF1b3Q7IC0tJmd0OyAmcXVvdDtTdG9yZSB0aGUgTUFD IG9mIGVhY2ggbGFzdC1yZWNlaXZlZCBmcmFnbWVudCZxdW90Oy48YnI+DQo8YnI+DQoxMikgU2Vj dGlvbiA2LjUsIHBhZ2UgMjAsIGZpcnN0IHBhcmFncmFwaC4gQWZ0ZXIgdGhlIGxhc3Qgc2VudGVu Y2UgJnF1b3Q7RFRMUyBhbmQgT1NDT0FQIGNhbiBiZSBjb21iaW5lZCZxdW90OywgSSB3b3VsZCBy ZXN0YXRlIHdoYXQgc2FpZCBpbiBTZWN0aW9uIDEgKHBhZ2UgNCksIHRoYXQgaXMgJnF1b3Q7dGhl cmVieSBlbmFibGluZyBlbmQtdG8tZW5kIC4uLiZxdW90Ozxicj4NCjxicj4NCjEzKSBTZWN0aW9u IDYuNSwgcGFnZSAyMCwgdGhpcmQgcGFyYWdyYXBoLiAmcXVvdDtUaGUgdXNlIG9mIENPU0UgdG8g cHJvdGVjdGVkIENvQVAgbWVzc2FnZXMmcXVvdDsgLS0mZ3Q7ICZxdW90O1RoZSB1c2Ugb2YgQ09T RSB0byBwcm90ZWN0IENvQVAgbWVzc2FnZXMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEp1bCA4LCAyMDE2IGF0IDk6MDMgQU0s IEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2VzY2EucGFsb21i aW5pQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJp Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjotbW96LXVzZS10 ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciByZ2IoMjA0 LDIwNCwyMDQpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGVhciBDb1JFLCBDT1NFIGFuZCBB Q0UgbWVtYmVycyw8YnI+DQo8YnI+DQpXZSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGUgdG8gdGhl IE9TQ09BUCBkcmFmdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3Vy aXR5LTA1PC9hPjxicj4NCjxicj4NCkZvciB0aG9zZSB3aG8gZG9u4oCZdCBrbm93LCBPU0NPQVAg aXMgYW4gYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJpdHkgcHJvdG9jb2wgZm9yIENvQVAsIGJhc2Vk IG9uIHdyYXBwaW5nIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIGluIENPU0Ugb2JqZWN0 cyB3aGljaCBhcmUgc2VudCBpbiBhIENvQVAgbWVzc2FnZSBleGNoYW5nZS48YnI+DQo8YnI+DQpX aXRoIHRoaXMgdmVyc2lvbiwgd2UgYWltZWQgZm9yIGltcHJvdmVkIHJlYWRhYmlsaXR5IGFuZCB3 ZSBhZGRlZCB0aGUgYmxvY2t3aXNlIGZ1bmN0aW9uYWxpdHksIGFzIGRpc2N1c3NlZCBkdXJpbmcg bGFzdCBmMmYgbWVldGluZy48YnI+DQo8YnI+DQpXZSBhcmUgbm93IGxvb2tpbmcgZm9yIHJldmll d3MuIEFueSBjb21tZW50IG9yIGZlZWRiYWNrIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQh PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCkZyYW5jZXNjYTxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl08YnI+DQpTZW50OiBk ZW4gNyBqdWxpIDIwMTYgMTg6Mzc8YnI+DQpUbzogR8O2cmFuIFNlbGFuZGVyICZsdDs8YSBocmVm PSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z29y YW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPC9hPiZndDs7IEx1ZHdpZyBTZWl0eiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmx1ZHdpZ0BzaWNzLnNlIiB0YXJnZXQ9Il9ibGFuayI+bHVkd2lnQHNpY3Muc2U8 L2E+Jmd0OzsgSm9obiBNYXR0c3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25A ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208 L2E+Jmd0OzsNCiBHw7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxh bmRlckBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5nb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb208L2E+Jmd0OzsgRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZy YW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50 eHQ8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2VsYW5kZXIt YWNlLW9iamVjdC1zZWN1cml0eS0wNS50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEZyYW5jZXNjYSBQYWxvbWJpbmkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5PGJyPg0KUmV2aXNpb246 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDU8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IE9iamVjdCBTZWN1cml0eSBvZiBDb0FQIChPU0NPQVApPGJyPg0K RG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNi0wNy0wNzxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAzNjxicj4NClVSTDombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNS50 eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA1LnR4dDwvYT48YnI+DQpTdGF0 dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt c2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0 eS0wNTwvYT48YnI+DQpEaWZmOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNlbGFu ZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0w NTwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBtZW1vIGRl ZmluZXMgT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAgKE9TQ09BUCksIGEgbWV0aG9kIGZvcjxicj4N CiZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbiBsYXllciBwcm90ZWN0aW9uIG9mIG1lc3NhZ2UgZXhj aGFuZ2VzIHdpdGggdGhlPGJyPg0KJm5ic3A7ICZuYnNwO0NvbnN0cmFpbmVkIEFwcGxpY2F0aW9u IFByb3RvY29sIChDb0FQKSwgdXNpbmcgdGhlIENCT1IgT2JqZWN0PGJyPg0KJm5ic3A7ICZuYnNw O1NpZ25pbmcgYW5kIEVuY3J5cHRpb24gKENPU0UpIGZvcm1hdC4mbmJzcDsgT1NDT0FQIHByb3Zp ZGVzIGVuZC10by1lbmQ8YnI+DQombmJzcDsgJm5ic3A7ZW5jcnlwdGlvbiwgaW50ZWdyaXR5IGFu ZCByZXBsYXkgcHJvdGVjdGlvbiB0byBDb0FQIHBheWxvYWQsIG9wdGlvbnMsPGJyPg0KJm5ic3A7 ICZuYnNwO2FuZCBoZWFkZXIgZmllbGRzLCBhcyB3ZWxsIGFzIGEgc2VjdXJlIGJpbmRpbmcgYmV0 d2VlbiBDb0FQIHJlcXVlc3Q8YnI+DQombmJzcDsgJm5ic3A7YW5kIHJlc3BvbnNlIG1lc3NhZ2Vz LiZuYnNwOyBUaGUgdXNlIG9mIE9TQ09BUCBpcyBzaWduYWxlZCB3aXRoIHRoZSBDb0FQPGJyPg0K Jm5ic3A7ICZuYnNwO29wdGlvbiBPYmplY3QtU2VjdXJpdHksIGFsc28gZGVmaW5lZCBpbiB0aGlz IG1lbW8uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9y ZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AMXPR07MB070E936BD38CE40EC1E4D9798300AMXPR07MB070eurprd_-- From nobody Tue Jul 12 02:58:24 2016 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 C985812D77B for ; Tue, 12 Jul 2016 02:58:22 -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 3mzjwGbNmOqb for ; Tue, 12 Jul 2016 02:58:20 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7265E12B026 for ; Tue, 12 Jul 2016 02:58:20 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id HlyE1t00F4K0fSy01lyERx; Tue, 12 Jul 2016 11:58:18 +0200 Received: from 2001:983:a264:1:dbf:8e04:7626:a035 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 11:58:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Jul 2016 11:58:14 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (Ceicv1xq3LqnUXJHyyIJvaxlHGmkXTsi) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 09:58:23 -0000 Hi Michel, I separated my answer into three parts to simplify the discussion. > Section 5.3; > In the example, where do I find in the CBOR encoding that the fraction > is 2 digits? > > [MV] The number of digits is not encoded. This information is > considered an unnecessary metadata > [MV] similar to "units", text of an enumeration, name of a flag within > bits. This was the consensus > [MV] of the group which is aligned with the statement in section 3 (In > order to minimize the size of > [MV] the encoded data, the proposed mapping avoid any unnecessary > meta-information beyond > [MV] those natively supported by CBOR.) > [MV] It might be worth it to raise this topic within a larger audience. > The following example shows the encoding of leaf 'my-decimal' set to 2.57. Definition example from [RFC7317]: leaf my-decimal { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } } CBOR diagnostic notation: 257 Should it not be pointed out more strongly that the yang to cbor conversion fails in this case? I don't see how a change from 2.57 or 257 represents loosing unnecessary meta information. Unless I completely miss the point of the example. From nobody Tue Jul 12 03:04:14 2016 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 7888A12D783 for ; Tue, 12 Jul 2016 03:04:12 -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 xSHS6cjhPKxH for ; Tue, 12 Jul 2016 03:04:09 -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 92AF912D773 for ; Tue, 12 Jul 2016 03:04:09 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1] (unknown [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A0984A80D9; Tue, 12 Jul 2016 12:04:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Tue, 12 Jul 2016 12:04:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 10:04:12 -0000 Dear Peter, In this case you can infer the decimal point position from the YANG = definition, e.g. the statement "fraction-digits 2;" Which indicates that 257 represents the number 2.57. 2 represents 0.02, = 50 represents 0.50, 1000 represents 10.00 I think that you are right that we should provide more examples to be = clear on this point. Best, Alexander > Le 12 juil. 2016 =C3=A0 11:58, peter van der Stok = a =C3=A9crit : >=20 > Hi Michel, >=20 > I separated my answer into three parts to simplify the discussion. >=20 >> Section 5.3; >> In the example, where do I find in the CBOR encoding that the = fraction >> is 2 digits? >> [MV] The number of digits is not encoded. This information is >> considered an unnecessary metadata >> [MV] similar to "units", text of an enumeration, name of a flag = within >> bits. This was the consensus >> [MV] of the group which is aligned with the statement in section 3 = (In >> order to minimize the size of >> [MV] the encoded data, the proposed mapping avoid any unnecessary >> meta-information beyond >> [MV] those natively supported by CBOR.) >> [MV] It might be worth it to raise this topic within a larger = audience. >=20 > The following example shows the encoding of leaf 'my-decimal' set to > 2.57. >=20 > Definition example from [RFC7317]: >=20 > leaf my-decimal { > type decimal64 { > fraction-digits 2; > range "1 .. 3.14 | 10 | 20..max"; > } > } >=20 > CBOR diagnostic notation: 257 >=20 > > Should it not be pointed out more strongly that the yang to cbor = conversion fails in this case? > I don't see how a change from 2.57 or 257 represents loosing = unnecessary meta information. > Unless I completely miss the point of the example. > >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 12 03:07:46 2016 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 81D4D12D0CE for ; Tue, 12 Jul 2016 03:07:45 -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 KliXAtM_bPPu for ; Tue, 12 Jul 2016 03:07:44 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065A912B017 for ; Tue, 12 Jul 2016 03:07:43 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id Hm7i1t0074K0fSy01m7ifm; Tue, 12 Jul 2016 12:07:42 +0200 Received: from 2001:983:a264:1:dbf:8e04:7626:a035 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 12:07:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Jul 2016 12:07:42 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (pDm24dwfg/n4XQr7sdC5gmmbpdueUkGb) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 10:07:45 -0000 Hi Michel, > > However, I am missing how to transport a given list instance with its > key values in the CBOR encoding. Section 4.4 describes the encoding of > a complete list not a subset of its instances. > > [MV] A list instance is a collection which is described in section 4.2. > _____________________________________________________________________________________________ With the current text I don't see how you distinguish instances with the same key from instances with different keys. Example: list server { key name; leaf name { type string; } leaf iburst { type boolean; default false; } How to distinguish that in the list below that two instances are identical (should not occur) [ { 1755 : "NRC TIC server", # name (SID 1755) 1754 : false, # iburst (SID 1754) }, { 1755 : "NRC TIC server", # name (SID 1755) 1754 : true, # iburst (SID 1754) } ] And the following two instances are different (valid array) [ { 1755 : "NRC TAC server", # name (SID 1755) 1754 : true, # iburst (SID 1754) }, { 1755 : "NRC TIC server", # name (SID 1755) 1754 : true, # iburst (SID 1754) } ] From nobody Tue Jul 12 03:18:31 2016 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 0BD7C12D791 for ; Tue, 12 Jul 2016 03:18:30 -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 vwRxgQa7oMag for ; Tue, 12 Jul 2016 03:18:28 -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 5266012D78F for ; Tue, 12 Jul 2016 03:18:28 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id HmJS1t00E4K0fSy01mJS9Y; Tue, 12 Jul 2016 12:18:26 +0200 Received: from 2001:983:a264:1:dbf:8e04:7626:a035 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 12:18:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 12 Jul 2016 12:18:26 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> Message-ID: <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> X-Sender: stokcons@xs4all.nl (LwgAYANbM4p6i6xfXMiVDDDCreLEIF3K) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR , identification of objects X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 10:18:30 -0000 Hi Michel, Here we have a point where my vision on this document differs from yours. > > Section 3: “the specification supports three types of keys.” > I would suggest only 2: character strings and numbers. > The use of deltas is either application (CoOL) specific or YANG to > CBOR mapping specific. > If it is YANG to CBOR specific, I would encourage the use of another > CBOR type that specifies a delta. As specified here its use is > ambiguous; and forces each application to specify explicitly what is > meant. > In the case that the delta is CoOL specific, I recommend to remove it > completely from this draft, and explain the use of Deltas in the > appropriate CoOL draft. > In the latter case: What remains are two key types: number and > character string. > > [MV] The use of delta to encode integer based keys (SIDs) is an > integral part of the YANG to CBOR mapping. > [MV] This optimization is part of the encoding and independent of the > application. > [MV] The document is updated to keep only 2 type of keys > I am preparing a third document that describes a local numbering scheme for YANG identifiers based on discovery. The numbers will be quite small and I like to encode them as unsigned integers. However, with the present YANG to CBOR document some numbers must be encoded as Deltas, and that is not what I want. Therefore I recommend that all hash conversion to CBOR goes to the yang-hash document and the SID conversion to CBOR goes to an appropriate CoOL document. and the coming numbering conversion to CBOR also treats it in an appropriate document This document can then specify that identifiers can be strings and numbers, where for example numbers are encoded as unsigned integers. Greetings, Peter From nobody Tue Jul 12 03:23:34 2016 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 798DB12D794 for ; Tue, 12 Jul 2016 03:23: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 HWyEqCQV80oo for ; Tue, 12 Jul 2016 03:23:32 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7357912D0AA for ; Tue, 12 Jul 2016 03:23:30 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id HmPV1t0064K0fSy01mPV9r; Tue, 12 Jul 2016 12:23:29 +0200 Received: from 2001:983:a264:1:dbf:8e04:7626:a035 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 12:23:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Jul 2016 12:23:29 +0200 From: peter van der Stok To: Michel Veillette , draft-ietf-core-yang-cbor@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> Message-ID: <6ce5c06ff1c64d834ce1ccdda7b61ea4@xs4all.nl> X-Sender: stokcons@xs4all.nl (LTJhAaBunWJIyhOuwVpeiWH5y2aUMv8c) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 10:23:33 -0000 I forgot to add the following in an earlier e_mail, Bit stupid to annoy all wg members with this trivial remark > > I think that a large number of the CBOR encoding examples in section > 4.2 can be left out. > They can be generated any time by an interested implementer; and now > confuse the issues. > > [MV] I received many questions about the final encoding and the number > of bytes required. > [MV] If I remove these examples, I'm concern that I will receive even > more of these questions. > [MV] I agree that these examples are useless for peoples with a good > knowledge of CBOR > [MV] but seem very welcome from newcomers. > What about putting them in an appendix? Peter From nobody Tue Jul 12 04:00:04 2016 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 976E3127077 for ; Tue, 12 Jul 2016 04:00: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, HTML_MESSAGE=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 uQOZXGceIFo3 for ; Tue, 12 Jul 2016 04:00: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 5C8A4127071 for ; Tue, 12 Jul 2016 04:00: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 u6CAxrup006616; Tue, 12 Jul 2016 12:59:53 +0200 (CEST) Received: from roku (ip-109-45-2-164.web.vodafone.de [109.45.2.164]) (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 3rpf9v3bhqzDgwy; Tue, 12 Jul 2016 12:59:46 +0200 (CEST) Date: Tue, 12 Jul 2016 12:59:32 +0200 From: Carsten Bormann To: Alexander Pelov Message-ID: <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5784cd94_327b23c6_4256" Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 11:00:02 -0000 --5784cd94_327b23c6_4256 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alexander, This is right. However, I thought that in the discussion of unions we had= arrived at encoding decimals as CBOR decimal fraction tags. But maybe I'= m misremembering. =20 Gr=C3=BC=C3=9Fe, Carsten =20 --5784cd94_327b23c6_4256 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Alexander,

This is right. However, I thought that in= the discussion of unions we had arrived at encoding decimals as CBOR dec= imal fraction tags. But maybe I'm misremembering.

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

On 12 Jul 2016 12:04, Alexander Pelov wrote:

=09

Dear Peter,&=2313;
&=2313;
In this case you can infe= r the decimal point position from the YANG definition, e.g. the statement= =22fraction-digits 2;=22&=2313;
&=2313;
Which indicates that 257= represents the number 2.57. 2 represents 0.02, 50 represents 0.50, 1000 = represents 10.00&=2313;
&=2313;
I think that you are right that w= e should provide more examples to be clear on this point.&=2313;
&=23= 13;
Best,&=2313;
Alexander&=2313;
&=2313;
&=2313;

Le 12 juil. 2016 =C3=A0 11:58, peter van d= er Stok <stokcons=40xs4all.nl> a =C3=A9crit :&=2313;
&=2313;Hi Michel,&=2313;
&=2313;
I separated my answer into three part= s to simplify the discussion.&=2313;
&=2313;
Section 5.3;&=2313;
In the example, where do I find in the CB= OR encoding that the fraction&=2313;
is 2 digits=3F&=2313;
=5BMV=5D= The number of digits is not encoded. This information is&=2313;
cons= idered an unnecessary metadata&=2313;
=5BMV=5D similar to =22units=22= , text of an enumeration, name of a flag within&=2313;
bits. This was= the consensus&=2313;
=5BMV=5D of the group which is aligned with the= statement in section 3 (In&=2313;
order to minimize the size of&=231= 3;
=5BMV=5D the encoded data, the proposed mapping avoid any unnecess= ary&=2313;
meta-information beyond&=2313;
=5BMV=5D those natively= supported by CBOR.)&=2313;
=5BMV=5D It might be worth it to raise th= is topic within a larger audience.&=2313;
&=2313;
Th= e following example shows the encoding of leaf 'my-decimal' set to&=2313;=
2.57.&=2313;
&=2313;
Definition example from =5BR=46C7317=5D= :&=2313;
&=2313;
leaf my-decimal =7B&=2313;
type decimal64 =7B= &=2313;
fraction-digits 2;&=2313;
range =221 .. 3.14 =7C 10 =7C 2= 0..max=22;&=2313;
=7D&=2313;
=7D&=2313;
&=2313;
CBOR diag= nostic notation: 257&=2313;
&=2313;
<pvds>&=2313;
Shoul= d it not be pointed out more strongly that the yang to cbor conversion fa= ils in this case=3F&=2313;
I don't see how a change from 2.57 or 257 = represents loosing unnecessary meta information.&=2313;
Unless I comp= letely miss the point of the example.&=2313;
</pvds>&=2313;
&=2313;
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F&=2313;
core mailing list&=2313;
core=40ietf.org&=2313;
https://www.ietf.org/mailman/listinfo/core&=2313;
&=231= 3;
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= &=2313;
core mailing list&=2313;
core=40ietf.org&=2313;
https= ://www.ietf.org/mailman/listinfo/core&=2313;
&=2313;
&=2313;
=
--5784cd94_327b23c6_4256-- From nobody Tue Jul 12 07:22:43 2016 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 18C5E12D903 for ; Tue, 12 Jul 2016 07:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 R-ajGMruVtWX for ; Tue, 12 Jul 2016 07:22:36 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0099.outbound.protection.outlook.com [104.47.41.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 5741E12DE17 for ; Tue, 12 Jul 2016 06:33:23 -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=8PmsEt7B0Utld9yhZObc+Ps83+4RINfqfgti6GIqWWg=; b=AmCfg3Y1/gdIgXSVwaAlopVYC/4jgtnD21JYJg2H0GoRhLGIaut1hXXMlj+wu+wjYaYeWN0F+r5nxL4ZWvgz+L57icTGbTqkf4RUELjW5pZvGkLBQdNIVazmzXIIeagad1VZGSDi6cnZUjEiIJqqe0hkuBqodPAfU8RIrixcDpU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 13:33:21 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 13:33:21 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYAFQCAAC0uoA== Date: Tue, 12 Jul 2016 13:33:20 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: f9795d29-4e2e-4fbe-60c3-08d3aa5917b1 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:ROlGuFBqXMHvKFmS2K7Cv+KzFmU2DNb+RQsEnRrcBtR/BdIfi+NxYNbcnNQiLd+FumiGiVe8g4G5cZod3YD9ytjLzPFIJGJmm8iisCz72fLuSTBSejgIB3r971gWAGSPyUEmk8R6eZhQ9D1teH56d1LssfRrAaWQ5pHNykUH9WE7S1GubVwZxcW4QeThHWJJOZxUU4yKMpJrWWqmwv6TyP/SbynXq+FBq+7xrXFwz4ja/KBERHm9PLoige/HaGUS0k8bD4qQpEC8MZAep5xlH3ktYn9AzL/rMXN/QcJe9VI=; 5:skp7BPgV1urz4NUk8HxGVOLDZ0gAMfVzv6BFRXwUvi1dWUPbBzKCEjk6U2MG/kuw8N6S56br8RL+aw7A/2cJ/bwlkCrhhP6suzL27LHGZfgZW9RBueINg7dOEPaQX6XmPZ6xkiN1oGKWfQog8ILLGQ==; 24:P7PXAkwIYG2Ko00FNb0Y88yafeN6ckREEk2+S4DugKbu+nRSmqPiNmK1jNNbAQxTp8opjfvta9M2sR8QlviSJi4HczFYpi/fRE7ClG7AuaM=; 7:XMAG1keKd/OpY0/Pz5Blx7VM5nUZCl6bJVx3DChJifmifHwtjOAo4THEzGsxdoCHhEBuFWL3X1WPBzIROgnv/b6t5j0HzJH1ceEJrOG4ZDjgCnEX6TDEHn9dcUYpr1BjciiSIVlJjbFsGGUMXHqdksFGGo1SPBaFIgyo8lZ2wTVQmC5ejpgAEdGIFS9okpD3EhQbAUhrOtTi7a8kkjXer4J8iW63ShW5L4kxYhcayekYGekUm4tF+/Srl+QsRvA3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(13464003)(8936002)(81156014)(81166006)(6116002)(3846002)(102836003)(10400500002)(110136002)(87936001)(86362001)(189998001)(50986999)(15975445007)(77096005)(76176999)(5002640100001)(3660700001)(54356999)(586003)(2900100001)(122556002)(97736004)(2950100001)(66066001)(2351001)(68736007)(92566002)(106356001)(106116001)(2906002)(33656002)(101416001)(11100500001)(4326007)(9686002)(7736002)(7696003)(5003600100003)(2501003)(8676002)(1730700003)(19580405001)(5640700001)(105586002)(99286002)(7846002)(74316002)(3280700002)(19580395003)(305945005)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 13:33:20.9628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 14:22:41 -0000 Hi Peter Multiple aspects of YANG assume that the entities which serialize and de-se= rialize are schema aware. This knowledge is used for example to apply default values where needed (se= e rfc6020bis section 7.6.1) This knowledge is also used to perform all kings of validations (range, pattern, length, min-elements, max-elements, must, when, if-feature= ) The proposed mapping, as stated by https://tools.ietf.org/html/draft-ietf-c= ore-yang-cbor-02#section-3 use this awareness to minimize the information transferred. In the example leaf temperature { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; units "=B0C"; } } This information is used to serialize 2.57 =B0C into a CBOR unsigned intege= r 257 (3bytes). The same information is used to de-serialize to the CBOR unsigned integer 2= 57 back to 2.57 =B0C This encoding is less friendly to schema unaware debugging tools (e.g. wire= shark). If the group believe we need to be more friendly to such tools, we can adop= t the CBOR tag 4 (Decimal fraction) as defined in RFC7049 section 2.4.3. However, this encoding will require 6 bytes in the case of "2.57" which is = more than the textual form. This significant overhead is the main reason why peoples have agreed to ado= pt the current encoding. Can you propose some texts to clarify this topic? Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Tuesday, July 12, 2016 5:58 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 Hi Michel, I separated my answer into three parts to simplify the discussion. > Section 5.3; > In the example, where do I find in the CBOR encoding that the fraction=20 > is 2 digits? >=20 > [MV] The number of digits is not encoded. This information is=20 > considered an unnecessary metadata [MV] similar to "units", text of an=20 > enumeration, name of a flag within bits. This was the consensus [MV]=20 > of the group which is aligned with the statement in section 3 (In=20 > order to minimize the size of [MV] the encoded data, the proposed=20 > mapping avoid any unnecessary meta-information beyond [MV] those=20 > natively supported by CBOR.) [MV] It might be worth it to raise this=20 > topic within a larger audience. >=20 The following example shows the encoding of leaf 'my-decimal' set to 2.57. Definition example from [RFC7317]: leaf my-decimal { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } } CBOR diagnostic notation: 257 Should it not be pointed out more strongly that the yang to cbor conversion= fails in this case? I don't see how a change from 2.57 or 257 represents loosing unnecessary me= ta information. Unless I completely miss the point of the example. From nobody Tue Jul 12 07:39:50 2016 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 3270612D7B9 for ; Tue, 12 Jul 2016 07:39:49 -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 6tS6p90hEp04 for ; Tue, 12 Jul 2016 07:39:46 -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 B749612DEC0 for ; Tue, 12 Jul 2016 06:50:13 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1] (unknown [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id D6A1CA8133; Tue, 12 Jul 2016 15:50:11 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_334A9642-3045-47F0-9E57-FA0B1599DD7A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> Date: Tue, 12 Jul 2016 15:50:05 +0200 Message-Id: <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 14:39:49 -0000 --Apple-Mail=_334A9642-3045-47F0-9E57-FA0B1599DD7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Carsten, Yes, you are right. I thought that we could keep this representation = outside of unions. But of course, we need to balance the complexity of = doing this.=20 There could be a confusion if the server and the client have different = versions of the same module (rare, but must be taken care of). Which is = of course, the thing we=E2=80=99ve always tried to avoid.. So yeah, for = the moment we could keep the CBOR decimal tag.=20 Best, Alexander > Le 12 juil. 2016 =C3=A0 12:59, Carsten Bormann a =C3=A9cr= it : >=20 > Hi Alexander, >=20 > This is right. However, I thought that in the discussion of unions we = had arrived at encoding decimals as CBOR decimal fraction tags. But = maybe I'm misremembering.=20 >=20 > Gr=C3=BC=C3=9Fe, Carsten=20 >=20 > On 12 Jul 2016 12:04, Alexander Pelov wrote:=20 >=20 >> Dear Peter,=0D >>=20 >> In this case you can infer the decimal point position from the YANG = definition, e.g. the statement "fraction-digits 2;"=0D >>=20 >> Which indicates that 257 represents the number 2.57. 2 represents = 0.02, 50 represents 0.50, 1000 represents 10.00=0D >>=20 >> I think that you are right that we should provide more examples to be = clear on this point.=0D >>=20 >> Best,=0D >> Alexander=0D >>=20 >>=20 >>=20 >>> Le 12 juil. 2016 =C3=A0 11:58, peter van der Stok = a =C3=A9crit :=0D >>>=20 >>> Hi Michel,=0D >>>=20 >>> I separated my answer into three parts to simplify the discussion.=0D= >>>=20 >>>> Section 5.3;=0D >>>> In the example, where do I find in the CBOR encoding that the = fraction=0D >>>> is 2 digits?=0D >>>> [MV] The number of digits is not encoded. This information is=0D >>>> considered an unnecessary metadata=0D >>>> [MV] similar to "units", text of an enumeration, name of a flag = within=0D >>>> bits. This was the consensus=0D >>>> [MV] of the group which is aligned with the statement in section 3 = (In=0D >>>> order to minimize the size of=0D >>>> [MV] the encoded data, the proposed mapping avoid any unnecessary=0D= >>>> meta-information beyond=0D >>>> [MV] those natively supported by CBOR.)=0D >>>> [MV] It might be worth it to raise this topic within a larger = audience.=0D >>>=20 >>> The following example shows the encoding of leaf 'my-decimal' set to=0D= >>> 2.57.=0D >>>=20 >>> Definition example from [RFC7317]:=0D >>>=20 >>> leaf my-decimal {=0D >>> type decimal64 {=0D >>> fraction-digits 2;=0D >>> range "1 .. 3.14 | 10 | 20..max";=0D >>> }=0D >>> }=0D >>>=20 >>> CBOR diagnostic notation: 257=0D >>>=20 >>> =0D >>> Should it not be pointed out more strongly that the yang to cbor = conversion fails in this case?=0D >>> I don't see how a change from 2.57 or 257 represents loosing = unnecessary meta information.=0D >>> Unless I completely miss the point of the example.=0D >>> =0D >>>=20 >>> _______________________________________________=0D >>> core mailing list=0D >>> core@ietf.org=0D >>> https://www.ietf.org/mailman/listinfo/core=0D >>=20 >> _______________________________________________=0D >> core mailing list=0D >> core@ietf.org=0D >> https://www.ietf.org/mailman/listinfo/core=0D >>=20 >>=20 --Apple-Mail=_334A9642-3045-47F0-9E57-FA0B1599DD7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Carsten,

Yes, you are right. I thought that we could keep this = representation outside of unions. But of course, we need to balance the = complexity of doing this. 

There could be a confusion if the = server and the client have different versions of the same module (rare, = but must be taken care of). Which is of course, the thing we=E2=80=99ve = always tried to avoid.. So yeah, for the moment we could keep the CBOR = decimal tag. 

Best,
Alexander

Le = 12 juil. 2016 =C3=A0 12:59, Carsten Bormann <cabo@tzi.org> a =C3=A9crit = :

=09 =09
Hi Alexander,

This is right. However, I thought that in the discussion of = unions we had arrived at encoding decimals as CBOR decimal fraction = tags. But maybe I'm misremembering.

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

On 12 Jul 2016 12:04, Alexander Pelov wrote:

=09

Dear = Peter,=0D
=0D
In this case you can infer the = decimal point position from the YANG definition, e.g. the statement = "fraction-digits 2;"=0D
=0D
Which indicates = that 257 represents the number 2.57. 2 represents 0.02, 50 represents = 0.50, 1000 represents 10.00=0D
=0D
I think = that you are right that we should provide more examples to be clear on = this point.=0D
=0D
Best,=0D
Alexander=0D
=0D
=0D

Le 12 juil. 2016 =C3=A0= 11:58, peter van der Stok <stokcons@xs4all.nl> a =C3=A9crit :=0D
=0D=
Hi Michel,=0D
=0D
I separated = my answer into three parts to simplify the discussion.=0D
=0D=
Section 5.3;=0D
In the example, where do I find in the CBOR encoding that the = fraction=0D
is 2 digits?=0D
[MV] The number = of digits is not encoded. This information is=0D
considered = an unnecessary metadata=0D
[MV] similar to "units", text = of an enumeration, name of a flag within=0D
bits. This was = the consensus=0D
[MV] of the group which is aligned with = the statement in section 3 (In=0D
order to minimize the = size of=0D
[MV] the encoded data, the proposed mapping = avoid any unnecessary=0D
meta-information beyond=0D
[MV] those natively supported by CBOR.)=0D
[MV] = It might be worth it to raise this topic within a larger audience.=0D
=0D
The following example shows = the encoding of leaf 'my-decimal' set to=0D
2.57.=0D
=0D
Definition example from [RFC7317]:=0D
=0D
leaf my-decimal {=0D
type = decimal64 {=0D
fraction-digits 2;=0D
range = "1 .. 3.14 | 10 | 20..max";=0D
}=0D
}=0D
=0D
CBOR diagnostic notation: 257=0D
=0D
<pvds>=0D
Should it not = be pointed out more strongly that the yang to cbor conversion fails in = this case?=0D
I don't see how a change from 2.57 or 257 = represents loosing unnecessary meta information.=0D
Unless = I completely miss the point of the example.=0D
</pvds>= =0D
=0D
_______________________________________________=0D
core mailing list=0D
core@ietf.org=0D
https://www.ietf.org/mailman/listinfo/core=0D
=0D
_______________________________________________=0D
core mailing list=0D
core@ietf.org=0D
https://www.ietf.org/mailman/listinfo/core=0D
=0D
=0D

= --Apple-Mail=_334A9642-3045-47F0-9E57-FA0B1599DD7A-- From nobody Tue Jul 12 07:53:46 2016 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 6F85812D878 for ; Tue, 12 Jul 2016 07:53:45 -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 YrCbB5KxTxlY for ; Tue, 12 Jul 2016 07:53:42 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0099.outbound.protection.outlook.com [104.47.36.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 82B2412D879 for ; Tue, 12 Jul 2016 07:14:22 -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=9VDMSe/3cYC2eho9KP5SKhUllpjM1U04xbJ5q/+NAms=; b=LuYfYmTsHaY5qq8CL8HOJpIbaiXQuoTIiUUwzDVCvi25q2/i5oFzEj17lKTik8otHIm4FuYsrzhzq3rbekb7bkI5k++zMBbDozoqv132yeySJ3GbWAZXW0m1rS+gQ7dFViYSeTp3rbZcCSToK0b4mlbkW35DnKCJLbJiQWad1OA= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 14:14:20 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 14:14:20 +0000 From: Michel Veillette To: Carsten Bormann , Alexander Pelov , "peter van der Stok" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYAFQCAAAGjAIAAD30AgAAx9YA= Date: Tue, 12 Jul 2016 14:14:20 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> In-Reply-To: <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: a631d584-4e1f-4e8c-51c1-08d3aa5ed178 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:jijpZdPKswU3vNzaHyBVQpck+M8OcP4xYgV2mM2hNH4IWnKr1vUQrf5nu1aXEZU15kbVuDJPKXP1cI4DitUzfws6+otG9xC7mmx4IAcICypbh1/Ucv6W9zBElxGtMCivfrmbX2Ws6RfDkxxmxpvGmBdXDDfh3niSUtxH6/1jSdwdldkK3JLdk+tYk8kzwwfzSU+lpez4dQOmaFa2HLTRiXNoSPph6jf+sXey5681XzU28JZYjARxzPJnvdohwVixULhwnGDltgnERb7TDpjzm4w9cB5rJ93um+77InaFL+s=; 5:9IEklv7VB/PqbY/sHYS1IoLndNrvyvNCEWx95jJl9PWca3UYl2+fckF7HLkdAPXL/rrEbWgLnISJH2dNdcf4qHQvIwAZCFZsvBdozpgHOD4rLWqIJxneU9SzT9Z0f4/RYgbI7NPpM57VwtYf/Os/OQ==; 24:7zx+zq54zxkDb4FbF+TTQPPzfDm2VOtALE+sBhlbqcEFMJRgpnV+FqI6LauVspvauRftVqsY0sq5gSo+pAqhTYhT5DjzawqSanVKjH/YyPE=; 7:5ojSY2kIaZfR4Rkomqa5XZ/EbvS3YTbPvVZFPlVECAORfHXRm+sg9o2RIE469Wi/sEbQCB6Iqo8LDDNDM0k8YGtHJES68P6JnipPWqDwgi1g4P1Jv9jsCE3KmbDIEhFDPTDAnz8JuDfbrBbqVQ0LAH4jd4cVhhxekNz5pc8JrNYMO7/DLWJTxFMMhVWtz3tj2usTsRdBrpIMHWa5N4bss7u1rk9jEhTAGdLQTVlmw/1l5+LaNqtD4hC31/Esm0/6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(51444003)(24454002)(377454003)(189002)(19617315012)(4326007)(9686002)(19625215002)(93886004)(33656002)(11100500001)(101416001)(19300405004)(7906003)(74316002)(7846002)(3280700002)(76576001)(19580395003)(8676002)(19580405001)(7696003)(5003600100003)(7736002)(99286002)(105586002)(87936001)(86362001)(54356999)(586003)(15975445007)(189998001)(50986999)(77096005)(5002640100001)(3660700001)(76176999)(8936002)(16236675004)(10400500002)(81156014)(790700001)(102836003)(3846002)(81166006)(6116002)(2906002)(106356001)(106116001)(2950100001)(97736004)(2900100001)(5001770100001)(122556002)(92566002)(68736007)(66066001)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.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_BLUPR06MB1763FC956DF032F49366A22EFE300BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 14:14:20.5701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 14:53:45 -0000 --_000_BLUPR06MB1763FC956DF032F49366A22EFE300BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2Fyc3Rlbg0KDQpUaGUgY3VycmVudCBzb2x1dGlvbiBpcyBiYXNlZCBvbiB0aGUgZm9sbG93 aW5nIGxpbmUgaW4gdGhlIGZpbGUgIjIwMTYwNTI1IOKAkyBtaW51dGVzLmRvY3giLg0KIkRFQ0lN QUwg4oCTIHVzZSBDQk9S4oCZcyBERUNJTUFMIFRhZyAod2UgbG9zZSBvbmUgYnl0ZSwgYnV0IHRo ZXJlIGFyZSBvbmx5IDUgdmFsdWVzIG9mIHRoaXMgdHlwZSkNCg0KU2luY2UgdGFnIDQgKERlY2lt YWwgZnJhY3Rpb24pIHJlcXVpcmUgYXQgbGVhc3QgMyBieXRlcyBvZiBvdmVyaGVhZCwgSSBhc3N1 bWVkIHRoZSBpbnRyb2R1Y3Rpb24gb2YgYSBuZXcgdGFnIHVzZWQgc29yZWx5IGluIHRoZSBjb250 ZXh0IG9mIHRoZSB1bmlvbiBkYXRhdHlwZS4NCihTaW1pbGFyIGFwcHJvYWNoIGFzIHRoZSBvdGhl ciA0IHRhZ3MgdXNlZCBpbiB1bmlvbnMpDQoNClRoZSB1c2Ugb2YgdGFnIDQgKGRlY2ltYWwgZnJh Y3Rpb24pIGZvciBkZWNpbWFsNjQgdmFsdWVzIGluc2lkZSBvciBvdXRzaWRlIHRoZSBjb250ZXh0 IG9mIGFuIHVuaW9uIGlzIGFub3RoZXIgdmlhYmxlIHNvbHV0aW9uIEkgd2lsbCBzdXBwb3J0Lg0K DQpBbnkgc3Ryb25nIG9waW5pb24/DQoNCk1pY2hlbA0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiBU dWVzZGF5LCBKdWx5IDEyLCAyMDE2IDc6MDAgQU0NClRvOiBBbGV4YW5kZXIgUGVsb3YgPGFAYWNr bC5pbz4NCkNjOiBDb3JlIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBZQU5H IHRvIENCT1IgbWFwcGluZyB2ZXJzaW9uIDENCg0KSGkgQWxleGFuZGVyLA0KDQpUaGlzIGlzIHJp Z2h0LiBIb3dldmVyLCBJIHRob3VnaHQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiBvZiB1bmlvbnMg d2UgaGFkIGFycml2ZWQgYXQgZW5jb2RpbmcgZGVjaW1hbHMgYXMgQ0JPUiBkZWNpbWFsIGZyYWN0 aW9uIHRhZ3MuIEJ1dCBtYXliZSBJJ20gbWlzcmVtZW1iZXJpbmcuDQoNCkdyw7zDn2UsIENhcnN0 ZW4NCg0KT24gMTIgSnVsIDIwMTYgMTI6MDQsIEFsZXhhbmRlciBQZWxvdiB3cm90ZToNCg0KRGVh ciBQZXRlciwNCg0KSW4gdGhpcyBjYXNlIHlvdSBjYW4gaW5mZXIgdGhlIGRlY2ltYWwgcG9pbnQg cG9zaXRpb24gZnJvbSB0aGUgWUFORyBkZWZpbml0aW9uLCBlLmcuIHRoZSBzdGF0ZW1lbnQgImZy YWN0aW9uLWRpZ2l0cyAyOyINCg0KV2hpY2ggaW5kaWNhdGVzIHRoYXQgMjU3IHJlcHJlc2VudHMg dGhlIG51bWJlciAyLjU3LiAyIHJlcHJlc2VudHMgMC4wMiwgNTAgcmVwcmVzZW50cyAwLjUwLCAx MDAwIHJlcHJlc2VudHMgMTAuMDANCg0KSSB0aGluayB0aGF0IHlvdSBhcmUgcmlnaHQgdGhhdCB3 ZSBzaG91bGQgcHJvdmlkZSBtb3JlIGV4YW1wbGVzIHRvIGJlIGNsZWFyIG9uIHRoaXMgcG9pbnQu DQoNCkJlc3QsDQpBbGV4YW5kZXINCg0KTGUgMTIganVpbC4gMjAxNiDDoCAxMTo1OCwgcGV0ZXIg dmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw8bWFpbHRvOnN0b2tjb25zQHhzNGFsbC5u bD4+IGEgw6ljcml0IDoNCg0KSGkgTWljaGVsLA0KDQpJIHNlcGFyYXRlZCBteSBhbnN3ZXIgaW50 byB0aHJlZSBwYXJ0cyB0byBzaW1wbGlmeSB0aGUgZGlzY3Vzc2lvbi4NCg0KDQpTZWN0aW9uIDUu MzsNCkluIHRoZSBleGFtcGxlLCB3aGVyZSBkbyBJIGZpbmQgaW4gdGhlIENCT1IgZW5jb2Rpbmcg dGhhdCB0aGUgZnJhY3Rpb24NCmlzIDIgZGlnaXRzPw0KW01WXSBUaGUgbnVtYmVyIG9mIGRpZ2l0 cyBpcyBub3QgZW5jb2RlZC4gVGhpcyBpbmZvcm1hdGlvbiBpcw0KY29uc2lkZXJlZCBhbiB1bm5l Y2Vzc2FyeSBtZXRhZGF0YQ0KW01WXSBzaW1pbGFyIHRvICJ1bml0cyIsIHRleHQgb2YgYW4gZW51 bWVyYXRpb24sIG5hbWUgb2YgYSBmbGFnIHdpdGhpbg0KYml0cy4gVGhpcyB3YXMgdGhlIGNvbnNl bnN1cw0KW01WXSBvZiB0aGUgZ3JvdXAgd2hpY2ggaXMgYWxpZ25lZCB3aXRoIHRoZSBzdGF0ZW1l bnQgaW4gc2VjdGlvbiAzIChJbg0Kb3JkZXIgdG8gbWluaW1pemUgdGhlIHNpemUgb2YNCltNVl0g dGhlIGVuY29kZWQgZGF0YSwgdGhlIHByb3Bvc2VkIG1hcHBpbmcgYXZvaWQgYW55IHVubmVjZXNz YXJ5DQptZXRhLWluZm9ybWF0aW9uIGJleW9uZA0KW01WXSB0aG9zZSBuYXRpdmVseSBzdXBwb3J0 ZWQgYnkgQ0JPUi4pDQpbTVZdIEl0IG1pZ2h0IGJlIHdvcnRoIGl0IHRvIHJhaXNlIHRoaXMgdG9w aWMgd2l0aGluIGEgbGFyZ2VyIGF1ZGllbmNlLg0KDQpUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hv d3MgdGhlIGVuY29kaW5nIG9mIGxlYWYgJ215LWRlY2ltYWwnIHNldCB0bw0KMi41Ny4NCg0KRGVm aW5pdGlvbiBleGFtcGxlIGZyb20gW1JGQzczMTddOg0KDQpsZWFmIG15LWRlY2ltYWwgew0KdHlw ZSBkZWNpbWFsNjQgew0KZnJhY3Rpb24tZGlnaXRzIDI7DQpyYW5nZSAiMSAuLiAzLjE0IHwgMTAg fCAyMC4ubWF4IjsNCn0NCn0NCg0KQ0JPUiBkaWFnbm9zdGljIG5vdGF0aW9uOiAyNTcNCg0KPHB2 ZHM+DQpTaG91bGQgaXQgbm90IGJlIHBvaW50ZWQgb3V0IG1vcmUgc3Ryb25nbHkgdGhhdCB0aGUg eWFuZyB0byBjYm9yIGNvbnZlcnNpb24gZmFpbHMgaW4gdGhpcyBjYXNlPw0KSSBkb24ndCBzZWUg aG93IGEgY2hhbmdlIGZyb20gMi41NyBvciAyNTcgcmVwcmVzZW50cyBsb29zaW5nIHVubmVjZXNz YXJ5IG1ldGEgaW5mb3JtYXRpb24uDQpVbmxlc3MgSSBjb21wbGV0ZWx5IG1pc3MgdGhlIHBvaW50 IG9mIHRoZSBleGFtcGxlLg0KPC9wdmRzPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFp bHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== --_000_BLUPR06MB1763FC956DF032F49366A22EFE300BLUPR06MB1763namp_ 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 LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIENhcnN0ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY3VycmVudCBzb2x1dGlvbiBpcyBiYXNlZCBvbiB0aGUg Zm9sbG93aW5nIGxpbmUgaW4gdGhlIGZpbGUgJnF1b3Q7MjAxNjA1MjUg4oCTIG1pbnV0ZXMuZG9j eCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZxdW90O0RFQ0lNQUwg4oCTIHVzZSBDQk9S4oCZcyBERUNJTUFMIFRhZyAo d2UgbG9zZSBvbmUgYnl0ZSwgYnV0IHRoZXJlIGFyZSBvbmx5IDUgdmFsdWVzIG9mIHRoaXMgdHlw ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+U2luY2UgdGFnIDQgKERlY2ltYWwgZnJhY3Rpb24pIHJlcXVpcmUg YXQgbGVhc3QgMyBieXRlcyBvZiBvdmVyaGVhZCwgSSBhc3N1bWVkIHRoZSBpbnRyb2R1Y3Rpb24g b2YgYSBuZXcgdGFnIHVzZWQgc29yZWx5IGluIHRoZSBjb250ZXh0IG9mIHRoZSB1bmlvbiBkYXRh dHlwZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPihTaW1pbGFyIGFwcHJvYWNoIGFzIHRoZSBvdGhlciA0IHRhZ3MgdXNlZCBpbiB1 bmlvbnMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB1c2Ugb2YgdGFnIDQgKGRlY2ltYWwgZnJhY3Rpb24p IGZvciBkZWNpbWFsNjQgdmFsdWVzIGluc2lkZSBvciBvdXRzaWRlIHRoZSBjb250ZXh0IG9mIGFu IHVuaW9uIGlzIGFub3RoZXIgdmlhYmxlIHNvbHV0aW9uIEkgd2lsbCBzdXBwb3J0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Bbnkgc3Ryb25nIG9waW5pb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hlbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBjb3JlIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DYXJzdGVuIEJvcm1hbm48YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxMiwgMjAxNiA3OjAwIEFNPGJyPg0KPGI+VG86PC9i PiBBbGV4YW5kZXIgUGVsb3YgJmx0O2FAYWNrbC5pbyZndDs8YnI+DQo8Yj5DYzo8L2I+IENvcmUg Jmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gWUFO RyB0byBDQk9SIG1hcHBpbmcgdmVyc2lvbiAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsZXhhbmRlciw8YnI+DQo8YnI+DQpUaGlzIGlz IHJpZ2h0LiBIb3dldmVyLCBJIHRob3VnaHQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiBvZiB1bmlv bnMgd2UgaGFkIGFycml2ZWQgYXQgZW5jb2RpbmcgZGVjaW1hbHMgYXMgQ0JPUiBkZWNpbWFsIGZy YWN0aW9uIHRhZ3MuIEJ1dCBtYXliZSBJJ20gbWlzcmVtZW1iZXJpbmcuDQo8YnI+DQo8YnI+DQpH csO8w59lLCBDYXJzdGVuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxMiBKdWwg MjAxNiAxMjowNCwgQWxleGFuZGVyIFBlbG92IHdyb3RlOiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5EZWFyIFBldGVyLCA8 YnI+DQo8YnI+DQpJbiB0aGlzIGNhc2UgeW91IGNhbiBpbmZlciB0aGUgZGVjaW1hbCBwb2ludCBw b3NpdGlvbiBmcm9tIHRoZSBZQU5HIGRlZmluaXRpb24sIGUuZy4gdGhlIHN0YXRlbWVudCAmcXVv dDtmcmFjdGlvbi1kaWdpdHMgMjsmcXVvdDsNCjxicj4NCjxicj4NCldoaWNoIGluZGljYXRlcyB0 aGF0IDI1NyByZXByZXNlbnRzIHRoZSBudW1iZXIgMi41Ny4gMiByZXByZXNlbnRzIDAuMDIsIDUw IHJlcHJlc2VudHMgMC41MCwgMTAwMCByZXByZXNlbnRzIDEwLjAwDQo8YnI+DQo8YnI+DQpJIHRo aW5rIHRoYXQgeW91IGFyZSByaWdodCB0aGF0IHdlIHNob3VsZCBwcm92aWRlIG1vcmUgZXhhbXBs ZXMgdG8gYmUgY2xlYXIgb24gdGhpcyBwb2ludC4NCjxicj4NCjxicj4NCkJlc3QsIDxicj4NCkFs ZXhhbmRlciA8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TGUgMTIganVpbC4gMjAxNiDDoCAxMTo1OCwgcGV0ZXIgdmFuIGRlciBTdG9rICZsdDs8YSBo cmVmPSJtYWlsdG86c3Rva2NvbnNAeHM0YWxsLm5sIj5zdG9rY29uc0B4czRhbGwubmw8L2E+Jmd0 OyBhIMOpY3JpdCA6DQo8YnI+DQo8YnI+DQpIaSBNaWNoZWwsIDxicj4NCjxicj4NCkkgc2VwYXJh dGVkIG15IGFuc3dlciBpbnRvIHRocmVlIHBhcnRzIHRvIHNpbXBsaWZ5IHRoZSBkaXNjdXNzaW9u LiA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VjdGlvbiA1LjM7IDxicj4NCkluIHRoZSBleGFtcGxlLCB3aGVyZSBkbyBJIGZpbmQgaW4g dGhlIENCT1IgZW5jb2RpbmcgdGhhdCB0aGUgZnJhY3Rpb24gPGJyPg0KaXMgMiBkaWdpdHM/IDxi cj4NCltNVl0gVGhlIG51bWJlciBvZiBkaWdpdHMgaXMgbm90IGVuY29kZWQuIFRoaXMgaW5mb3Jt YXRpb24gaXMgPGJyPg0KY29uc2lkZXJlZCBhbiB1bm5lY2Vzc2FyeSBtZXRhZGF0YSA8YnI+DQpb TVZdIHNpbWlsYXIgdG8gJnF1b3Q7dW5pdHMmcXVvdDssIHRleHQgb2YgYW4gZW51bWVyYXRpb24s IG5hbWUgb2YgYSBmbGFnIHdpdGhpbiA8YnI+DQpiaXRzLiBUaGlzIHdhcyB0aGUgY29uc2Vuc3Vz IDxicj4NCltNVl0gb2YgdGhlIGdyb3VwIHdoaWNoIGlzIGFsaWduZWQgd2l0aCB0aGUgc3RhdGVt ZW50IGluIHNlY3Rpb24gMyAoSW4gPGJyPg0Kb3JkZXIgdG8gbWluaW1pemUgdGhlIHNpemUgb2Yg PGJyPg0KW01WXSB0aGUgZW5jb2RlZCBkYXRhLCB0aGUgcHJvcG9zZWQgbWFwcGluZyBhdm9pZCBh bnkgdW5uZWNlc3NhcnkgPGJyPg0KbWV0YS1pbmZvcm1hdGlvbiBiZXlvbmQgPGJyPg0KW01WXSB0 aG9zZSBuYXRpdmVseSBzdXBwb3J0ZWQgYnkgQ0JPUi4pIDxicj4NCltNVl0gSXQgbWlnaHQgYmUg d29ydGggaXQgdG8gcmFpc2UgdGhpcyB0b3BpYyB3aXRoaW4gYSBsYXJnZXIgYXVkaWVuY2UuIDxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K VGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHRoZSBlbmNvZGluZyBvZiBsZWFmICdteS1kZWNp bWFsJyBzZXQgdG8gPGJyPg0KMi41Ny4gPGJyPg0KPGJyPg0KRGVmaW5pdGlvbiBleGFtcGxlIGZy b20gW1JGQzczMTddOiA8YnI+DQo8YnI+DQpsZWFmIG15LWRlY2ltYWwgeyA8YnI+DQp0eXBlIGRl Y2ltYWw2NCB7IDxicj4NCmZyYWN0aW9uLWRpZ2l0cyAyOyA8YnI+DQpyYW5nZSAmcXVvdDsxIC4u IDMuMTQgfCAxMCB8IDIwLi5tYXgmcXVvdDs7IDxicj4NCn0gPGJyPg0KfSA8YnI+DQo8YnI+DQpD Qk9SIGRpYWdub3N0aWMgbm90YXRpb246IDI1NyA8YnI+DQo8YnI+DQombHQ7cHZkcyZndDsgPGJy Pg0KU2hvdWxkIGl0IG5vdCBiZSBwb2ludGVkIG91dCBtb3JlIHN0cm9uZ2x5IHRoYXQgdGhlIHlh bmcgdG8gY2JvciBjb252ZXJzaW9uIGZhaWxzIGluIHRoaXMgY2FzZT8NCjxicj4NCkkgZG9uJ3Qg c2VlIGhvdyBhIGNoYW5nZSBmcm9tIDIuNTcgb3IgMjU3IHJlcHJlc2VudHMgbG9vc2luZyB1bm5l Y2Vzc2FyeSBtZXRhIGluZm9ybWF0aW9uLg0KPGJyPg0KVW5sZXNzIEkgY29tcGxldGVseSBtaXNz IHRoZSBwb2ludCBvZiB0aGUgZXhhbXBsZS4gPGJyPg0KJmx0Oy9wdmRzJmd0OyA8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+DQpj b3JlIG1haWxpbmcgbGlzdCA8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29y ZUBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmU8L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPGJyPg0KY29yZSBtYWlsaW5nIGxpc3QgPGJy Pg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+IDxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BLUPR06MB1763FC956DF032F49366A22EFE300BLUPR06MB1763namp_-- From nobody Tue Jul 12 08:15:31 2016 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 3BA5612DA01; Tue, 12 Jul 2016 08:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 0fL2vWD9BbaZ; Tue, 12 Jul 2016 08:15:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D2812DCD6; Tue, 12 Jul 2016 07:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1046; q=dns/txt; s=iport; t=1468334821; x=1469544421; h=reply-to:subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=UqpkMgkeVmPl8kdwHl0mvHtjm4KXaM7dPKGkmp1ygSg=; b=exyyPDpOm9yxdoXDXtjwFtJc9KAAIxQ557ovdYeRmPD3eT+AuVvbRkeL 7V5N0Emka+j4hZqg8rJ/UCdL+a8tMNr8gfUOoIqiDDfTv/rj3/ajfK8Q9 cMD7Twnb9UsaQsOFXmdrT+s3PsLo7y3YTq0GDDPeiAXHT2jPHndvo7wRG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRCQBMAoVX/4ENJK1cgz5WKlK5CYF5I?= =?us-ascii?q?oV2AoE0OBQBAQEBAQEBZSeEXQEFAQE2NgsQCxguJzAGAQwGAgEBiCwOtxKINgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBGAWGKoF4glWKHAEEk12FPo5UiU6FYJAUHjaCB?= =?us-ascii?q?h+BaCAyiSUBAQE?= X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="122937931" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 14:47:00 +0000 Received: from [10.86.253.127] ([10.86.253.127]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6CEl0t7027025; Tue, 12 Jul 2016 14:47:00 GMT References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <6ce5c06ff1c64d834ce1ccdda7b61ea4@xs4all.nl> To: consultancy@vanderstok.org, Michel Veillette , draft-ietf-core-yang-cbor@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: Date: Tue, 12 Jul 2016 10:46:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6ce5c06ff1c64d834ce1ccdda7b61ea4@xs4all.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:15:30 -0000 IMO the examples are useful. Move them to an appendix if you must, but I would leave them in the draft. Cheers On 7/12/2016 6:23 AM, peter van der Stok wrote: > I forgot to add the following in an earlier e_mail, > Bit stupid to annoy all wg members with this trivial remark > >> >> I think that a large number of the CBOR encoding examples in section >> 4.2 can be left out. >> They can be generated any time by an interested implementer; and now >> confuse the issues. >> >> [MV] I received many questions about the final encoding and the number >> of bytes required. >> [MV] If I remove these examples, I'm concern that I will receive even >> more of these questions. >> [MV] I agree that these examples are useless for peoples with a good >> knowledge of CBOR >> [MV] but seem very welcome from newcomers. >> > > What about putting them in an appendix? > > Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > . > From nobody Tue Jul 12 08:23:37 2016 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 497A212D18C for ; Tue, 12 Jul 2016 08:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_H2=-0.001, 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 3_mi6CBabNtI for ; Tue, 12 Jul 2016 08:23:33 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0128.outbound.protection.outlook.com [104.47.42.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 BC29112DDCF for ; Tue, 12 Jul 2016 07:57: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=B6bX2n2tTqotZKJPHHLmyDIxdr1Lr2zOtY6xtOd4D1w=; b=iGbEqO+5S1zE2aeSrZvbslwKTZnYi1+J87mxeYeAm7IePpJbOluFDIjY+kyTqHpins0XYv8tJRBX//0H2+MVb/6C2fc/dbTwHO1WBcAv+dVOXStCPzydyYiC7qSc0u1cMCgi6YycUcIKzm6QSzTYLJM6y+mkyqRRCRWNdHVtbYU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 14:57:03 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 14:57:03 +0000 From: Michel Veillette To: Alexander Pelov , Carsten Bormann Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYAFQCAAAGjAIAAD30AgAAvp4CAABES0A== Date: Tue, 12 Jul 2016 14:57:03 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> In-Reply-To: <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: dcf1ff01-d883-46e2-0e02-08d3aa64c8e8 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:XYHDGL2z3L3ID95VzDjWzAkk3+TZkyNg+Q7rCNASfq48Xd7r34pD/d9b196G2U1UObEXH1y7vtEB/UoQ56sJ5eT7o5522FI1lKi9Y6FH7JUJSaDvId5cSNB32bh7MXa1xyXaoL/6HU1cWUuFYlcwkqFvPx24fOJxeTjaDZVSlSO5k/9gqiuYL9v6jBDfzc16ns1gTKPW2aY2GO7vrLSeWi5rRTzCZWB+iY9x5axPlUUAyw07afaoeNpVqpe91ZNKJaCnjIk05XoyKoOC8arPimL4PmSPq7ZL82udA+qVqHc=; 5:rD8xzJquLixgLKJVdTFqcgnIWvHmu4fF5DVeIO/aPCf/SmTdcuJ2J6QglYEgbUWMRl4Ox1kUgBn8EpinqMrEPlr+ufz7QtKIejpNIrQ89kvkzbsgoXq21DLj7wMLbnID6egIvGUzs2vTXCON4sBy9g==; 24:PNrQC4zWV1P/rpSU3i+dR+5DQK1hr9ZLtTrq/MniViFkWhpKLJrR8uYE7f0hsc7Z92t5sQ8vEJuOeH5rtCMbym667gyRMPuEN0fHHIfzQM4=; 7:NBrgqL2ztiE0LMzTZDCSEfvCQQj0kXxnHoh4KScMHcNh4P5Scg5nT1nhYSJ47BATkAoiETbJQVIcQtCljwiXiwQrzl7lL+nLKvgaG3NyJ9jO+dr4CafJ8j3Va9M+fcv6cl9K/swCQt8MB3jNVPTR3YbrljWvyZwSlkwBShW4/x53RgWc//g1O4LSOppdN47RyhQz6doUKIKUeh2OZC+k+IQse4RCj7JKNr/n+t/C/LTyEoIiEVreF2FXbIg873+P x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(51444003)(24454002)(199003)(33656002)(10400500002)(8676002)(16236675004)(86362001)(8936002)(105586002)(11100500001)(87936001)(66066001)(81156014)(81166006)(97736004)(189998001)(5003600100003)(5001770100001)(7846002)(19609705001)(790700001)(7696003)(7736002)(50986999)(76176999)(74316002)(68736007)(19580405001)(6116002)(7906003)(76576001)(54356999)(99286002)(101416001)(3846002)(19625215002)(9686002)(15975445007)(102836003)(5002640100001)(2950100001)(2900100001)(586003)(19580395003)(77096005)(19617315012)(93886004)(3660700001)(92566002)(106116001)(106356001)(3280700002)(2906002)(4326007)(19300405004)(122556002)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.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: multipart/alternative; boundary="_000_BLUPR06MB1763BF04E17F6CC4232F2EF5FE300BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 14:57:03.1923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 15:23:35 -0000 --_000_BLUPR06MB1763BF04E17F6CC4232F2EF5FE300BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleGFuZGVyDQoNCkkgd2FudCB0byBiZSBzdXJlIG9mIHlvdXIgYW5zd2VyLg0KVGhlIENC T1IgdGFnIDQgKERlY2ltYWwgZnJhY3Rpb24pIHJlcXVpcmUgMyBieXRlcyBvZiBvdmVyaGVhZCwg c2VlIGV4YW1wbGUgZm9yIFJGQyA4MDQ5IHNlY3Rpb24gMi40LjMgYmVsbG93Lg0KVGhpcyBpcyB0 aGUgdGFnIHlvdSBhcmUgcHJvcG9zaW5nPw0KVGhpcyB0YWcgd2lsbCBiZSB1c2VkIGFsbCB0aGUg dGltZSAod2l0aGluIHRoZSBjb250ZXh0IG9mIGEgdW5pb24gYW5kIHdpdGhvdXQpPw0KDQpDNCAg ICAgICAgICAgICAjIFRhZyA0DQogIDgyICAgICAgICAgICAjIEFycmF5IG9mIGxlbmd0aCAyDQog ICAgMjEgICAgICAgICAjIC0yDQogICAgMTkgMDEwMSAgICAjIHVuc2lnbmVkKDI1NykNCg0KUmVn YXJkcywNCk1pY2hlbA0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFBlbG92DQpTZW50OiBUdWVzZGF5LCBKdWx5IDEyLCAy MDE2IDk6NTAgQU0NClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCkNjOiBDb3Jl IDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBZQU5HIHRvIENCT1IgbWFwcGlu ZyB2ZXJzaW9uIDENCg0KSGkgQ2Fyc3RlbiwNCg0KWWVzLCB5b3UgYXJlIHJpZ2h0LiBJIHRob3Vn aHQgdGhhdCB3ZSBjb3VsZCBrZWVwIHRoaXMgcmVwcmVzZW50YXRpb24gb3V0c2lkZSBvZiB1bmlv bnMuIEJ1dCBvZiBjb3Vyc2UsIHdlIG5lZWQgdG8gYmFsYW5jZSB0aGUgY29tcGxleGl0eSBvZiBk b2luZyB0aGlzLg0KDQpUaGVyZSBjb3VsZCBiZSBhIGNvbmZ1c2lvbiBpZiB0aGUgc2VydmVyIGFu ZCB0aGUgY2xpZW50IGhhdmUgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZSBzYW1lIG1vZHVsZSAo cmFyZSwgYnV0IG11c3QgYmUgdGFrZW4gY2FyZSBvZikuIFdoaWNoIGlzIG9mIGNvdXJzZSwgdGhl IHRoaW5nIHdl4oCZdmUgYWx3YXlzIHRyaWVkIHRvIGF2b2lkLi4gU28geWVhaCwgZm9yIHRoZSBt b21lbnQgd2UgY291bGQga2VlcCB0aGUgQ0JPUiBkZWNpbWFsIHRhZy4NCg0KQmVzdCwNCkFsZXhh bmRlcg0KDQpMZSAxMiBqdWlsLiAyMDE2IMOgIDEyOjU5LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gYSDDqWNyaXQgOg0KDQpIaSBBbGV4YW5kZXIs DQoNClRoaXMgaXMgcmlnaHQuIEhvd2V2ZXIsIEkgdGhvdWdodCB0aGF0IGluIHRoZSBkaXNjdXNz aW9uIG9mIHVuaW9ucyB3ZSBoYWQgYXJyaXZlZCBhdCBlbmNvZGluZyBkZWNpbWFscyBhcyBDQk9S IGRlY2ltYWwgZnJhY3Rpb24gdGFncy4gQnV0IG1heWJlIEknbSBtaXNyZW1lbWJlcmluZy4NCg0K R3LDvMOfZSwgQ2Fyc3Rlbg0KDQpPbiAxMiBKdWwgMjAxNiAxMjowNCwgQWxleGFuZGVyIFBlbG92 IHdyb3RlOg0KRGVhciBQZXRlciwNCg0KSW4gdGhpcyBjYXNlIHlvdSBjYW4gaW5mZXIgdGhlIGRl Y2ltYWwgcG9pbnQgcG9zaXRpb24gZnJvbSB0aGUgWUFORyBkZWZpbml0aW9uLCBlLmcuIHRoZSBz dGF0ZW1lbnQgImZyYWN0aW9uLWRpZ2l0cyAyOyINCg0KV2hpY2ggaW5kaWNhdGVzIHRoYXQgMjU3 IHJlcHJlc2VudHMgdGhlIG51bWJlciAyLjU3LiAyIHJlcHJlc2VudHMgMC4wMiwgNTAgcmVwcmVz ZW50cyAwLjUwLCAxMDAwIHJlcHJlc2VudHMgMTAuMDANCg0KSSB0aGluayB0aGF0IHlvdSBhcmUg cmlnaHQgdGhhdCB3ZSBzaG91bGQgcHJvdmlkZSBtb3JlIGV4YW1wbGVzIHRvIGJlIGNsZWFyIG9u IHRoaXMgcG9pbnQuDQoNCkJlc3QsDQpBbGV4YW5kZXINCg0KTGUgMTIganVpbC4gMjAxNiDDoCAx MTo1OCwgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw8bWFpbHRvOnN0b2tj b25zQHhzNGFsbC5ubD4+IGEgw6ljcml0IDoNCg0KSGkgTWljaGVsLA0KDQpJIHNlcGFyYXRlZCBt eSBhbnN3ZXIgaW50byB0aHJlZSBwYXJ0cyB0byBzaW1wbGlmeSB0aGUgZGlzY3Vzc2lvbi4NCg0K DQpTZWN0aW9uIDUuMzsNCkluIHRoZSBleGFtcGxlLCB3aGVyZSBkbyBJIGZpbmQgaW4gdGhlIENC T1IgZW5jb2RpbmcgdGhhdCB0aGUgZnJhY3Rpb24NCmlzIDIgZGlnaXRzPw0KW01WXSBUaGUgbnVt YmVyIG9mIGRpZ2l0cyBpcyBub3QgZW5jb2RlZC4gVGhpcyBpbmZvcm1hdGlvbiBpcw0KY29uc2lk ZXJlZCBhbiB1bm5lY2Vzc2FyeSBtZXRhZGF0YQ0KW01WXSBzaW1pbGFyIHRvICJ1bml0cyIsIHRl eHQgb2YgYW4gZW51bWVyYXRpb24sIG5hbWUgb2YgYSBmbGFnIHdpdGhpbg0KYml0cy4gVGhpcyB3 YXMgdGhlIGNvbnNlbnN1cw0KW01WXSBvZiB0aGUgZ3JvdXAgd2hpY2ggaXMgYWxpZ25lZCB3aXRo IHRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAzIChJbg0Kb3JkZXIgdG8gbWluaW1pemUgdGhlIHNp emUgb2YNCltNVl0gdGhlIGVuY29kZWQgZGF0YSwgdGhlIHByb3Bvc2VkIG1hcHBpbmcgYXZvaWQg YW55IHVubmVjZXNzYXJ5DQptZXRhLWluZm9ybWF0aW9uIGJleW9uZA0KW01WXSB0aG9zZSBuYXRp dmVseSBzdXBwb3J0ZWQgYnkgQ0JPUi4pDQpbTVZdIEl0IG1pZ2h0IGJlIHdvcnRoIGl0IHRvIHJh aXNlIHRoaXMgdG9waWMgd2l0aGluIGEgbGFyZ2VyIGF1ZGllbmNlLg0KDQpUaGUgZm9sbG93aW5n IGV4YW1wbGUgc2hvd3MgdGhlIGVuY29kaW5nIG9mIGxlYWYgJ215LWRlY2ltYWwnIHNldCB0bw0K Mi41Ny4NCg0KRGVmaW5pdGlvbiBleGFtcGxlIGZyb20gW1JGQzczMTddOg0KDQpsZWFmIG15LWRl Y2ltYWwgew0KdHlwZSBkZWNpbWFsNjQgew0KZnJhY3Rpb24tZGlnaXRzIDI7DQpyYW5nZSAiMSAu LiAzLjE0IHwgMTAgfCAyMC4ubWF4IjsNCn0NCn0NCg0KQ0JPUiBkaWFnbm9zdGljIG5vdGF0aW9u OiAyNTcNCg0KPHB2ZHM+DQpTaG91bGQgaXQgbm90IGJlIHBvaW50ZWQgb3V0IG1vcmUgc3Ryb25n bHkgdGhhdCB0aGUgeWFuZyB0byBjYm9yIGNvbnZlcnNpb24gZmFpbHMgaW4gdGhpcyBjYXNlPw0K SSBkb24ndCBzZWUgaG93IGEgY2hhbmdlIGZyb20gMi41NyBvciAyNTcgcmVwcmVzZW50cyBsb29z aW5nIHVubmVjZXNzYXJ5IG1ldGEgaW5mb3JtYXRpb24uDQpVbmxlc3MgSSBjb21wbGV0ZWx5IG1p c3MgdGhlIHBvaW50IG9mIHRoZSBleGFtcGxlLg0KPC9wdmRzPg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVA aWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3Jl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoN Cg0K --_000_BLUPR06MB1763BF04E17F6CC4232F2EF5FE300BLUPR06MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SGkgQWxleGFuZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SSB3YW50IHRvIGJlIHN1cmUgb2YgeW91ciBhbnN3ZXIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VGhlIENCT1INCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnRhZyA0IChEZWNpbWFsIGZy YWN0aW9uKSByZXF1aXJlIDMgYnl0ZXMgb2Ygb3ZlcmhlYWQsIHNlZSBleGFtcGxlIGZvciBSRkMg ODA0OSBzZWN0aW9uIDIuNC4zIGJlbGxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgdGhlIHRhZyB5b3UgYXJlIHBy b3Bvc2luZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoaXMgdGFnIHdpbGwgYmUgdXNlZCBhbGwgdGhlIHRpbWUgKHdpdGhpbiB0 aGUgY29udGV4dCBvZiBhIHVuaW9uIGFuZCB3aXRob3V0KT88L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkM0ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyMgVGFnIDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7IDgyICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgQXJyYXkgb2YgbGVuZ3Ro IDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q291cmllciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIxICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgLTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsmbmJzcDsgMTkgMDEwMSAmbmJzcDsmbmJzcDsmbmJzcDsj IHVuc2lnbmVkKDI1Nyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5NaWNoZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gY29y ZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxl eGFuZGVyIFBlbG92PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTIsIDIwMTYgOTo1 MCBBTTxicj4NCjxiPlRvOjwvYj4gQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2NvcmVdIFlBTkcgdG8gQ0JPUiBtYXBwaW5nIHZlcnNpb24gMTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENhcnN0ZW4sPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHlvdSBhcmUgcmln aHQuIEkgdGhvdWdodCB0aGF0IHdlIGNvdWxkIGtlZXAgdGhpcyByZXByZXNlbnRhdGlvbiBvdXRz aWRlIG9mIHVuaW9ucy4gQnV0IG9mIGNvdXJzZSwgd2UgbmVlZCB0byBiYWxhbmNlIHRoZSBjb21w bGV4aXR5IG9mIGRvaW5nIHRoaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGNvdWxkIGJlIGEgY29uZnVzaW9uIGlmIHRo ZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgaGF2ZSBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgdGhlIHNh bWUgbW9kdWxlIChyYXJlLCBidXQgbXVzdCBiZSB0YWtlbiBjYXJlIG9mKS4gV2hpY2ggaXMgb2Yg Y291cnNlLCB0aGUgdGhpbmcgd2XigJl2ZSBhbHdheXMgdHJpZWQgdG8gYXZvaWQuLiBTbyB5ZWFo LCBmb3IgdGhlIG1vbWVudCB3ZSBjb3VsZCBrZWVwIHRoZQ0KIENCT1IgZGVjaW1hbCB0YWcuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbGV4YW5kZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkxlIDEyIGp1aWwuIDIwMTYgw6AgMTI6NTksIENhcnN0ZW4gQm9ybWFubiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Y2Fib0B0emkub3JnPC9hPiZndDsgYSDDqWNy aXQgOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEFsZXhhbmRlciw8YnI+DQo8YnI+DQpUaGlzIGlzIHJpZ2h0LiBIb3dldmVyLCBJIHRob3Vn aHQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiBvZiB1bmlvbnMgd2UgaGFkIGFycml2ZWQgYXQgZW5j b2RpbmcgZGVjaW1hbHMgYXMgQ0JPUiBkZWNpbWFsIGZyYWN0aW9uIHRhZ3MuIEJ1dCBtYXliZSBJ J20gbWlzcmVtZW1iZXJpbmcuDQo8YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxMiBKdWwgMjAxNiAxMjowNCwgQWxleGFuZGVyIFBl bG92IHdyb3RlOiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+RGVhciBQZXRlciwNCjxicj4NCjxicj4NCkluIHRoaXMgY2FzZSB5b3UgY2Fu IGluZmVyIHRoZSBkZWNpbWFsIHBvaW50IHBvc2l0aW9uIGZyb20gdGhlIFlBTkcgZGVmaW5pdGlv biwgZS5nLiB0aGUgc3RhdGVtZW50ICZxdW90O2ZyYWN0aW9uLWRpZ2l0cyAyOyZxdW90Ow0KPGJy Pg0KPGJyPg0KV2hpY2ggaW5kaWNhdGVzIHRoYXQgMjU3IHJlcHJlc2VudHMgdGhlIG51bWJlciAy LjU3LiAyIHJlcHJlc2VudHMgMC4wMiwgNTAgcmVwcmVzZW50cyAwLjUwLCAxMDAwIHJlcHJlc2Vu dHMgMTAuMDANCjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB5b3UgYXJlIHJpZ2h0IHRoYXQgd2Ug c2hvdWxkIHByb3ZpZGUgbW9yZSBleGFtcGxlcyB0byBiZSBjbGVhciBvbiB0aGlzIHBvaW50Lg0K PGJyPg0KPGJyPg0KQmVzdCwgPGJyPg0KQWxleGFuZGVyIDxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAxMiBqdWlsLiAyMDE2IMOgIDExOjU4LCBw ZXRlciB2YW4gZGVyIFN0b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9rY29uc0B4czRhbGwubmwi PnN0b2tjb25zQHhzNGFsbC5ubDwvYT4mZ3Q7IGEgw6ljcml0IDoNCjxicj4NCjxicj4NCkhpIE1p Y2hlbCwgPGJyPg0KPGJyPg0KSSBzZXBhcmF0ZWQgbXkgYW5zd2VyIGludG8gdGhyZWUgcGFydHMg dG8gc2ltcGxpZnkgdGhlIGRpc2N1c3Npb24uIDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDUuMzsgPGJyPg0KSW4gdGhlIGV4 YW1wbGUsIHdoZXJlIGRvIEkgZmluZCBpbiB0aGUgQ0JPUiBlbmNvZGluZyB0aGF0IHRoZSBmcmFj dGlvbiA8YnI+DQppcyAyIGRpZ2l0cz8gPGJyPg0KW01WXSBUaGUgbnVtYmVyIG9mIGRpZ2l0cyBp cyBub3QgZW5jb2RlZC4gVGhpcyBpbmZvcm1hdGlvbiBpcyA8YnI+DQpjb25zaWRlcmVkIGFuIHVu bmVjZXNzYXJ5IG1ldGFkYXRhIDxicj4NCltNVl0gc2ltaWxhciB0byAmcXVvdDt1bml0cyZxdW90 OywgdGV4dCBvZiBhbiBlbnVtZXJhdGlvbiwgbmFtZSBvZiBhIGZsYWcgd2l0aGluIDxicj4NCmJp dHMuIFRoaXMgd2FzIHRoZSBjb25zZW5zdXMgPGJyPg0KW01WXSBvZiB0aGUgZ3JvdXAgd2hpY2gg aXMgYWxpZ25lZCB3aXRoIHRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAzIChJbiA8YnI+DQpvcmRl ciB0byBtaW5pbWl6ZSB0aGUgc2l6ZSBvZiA8YnI+DQpbTVZdIHRoZSBlbmNvZGVkIGRhdGEsIHRo ZSBwcm9wb3NlZCBtYXBwaW5nIGF2b2lkIGFueSB1bm5lY2Vzc2FyeSA8YnI+DQptZXRhLWluZm9y bWF0aW9uIGJleW9uZCA8YnI+DQpbTVZdIHRob3NlIG5hdGl2ZWx5IHN1cHBvcnRlZCBieSBDQk9S LikgPGJyPg0KW01WXSBJdCBtaWdodCBiZSB3b3J0aCBpdCB0byByYWlzZSB0aGlzIHRvcGljIHdp dGhpbiBhIGxhcmdlciBhdWRpZW5jZS4gPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhl IGVuY29kaW5nIG9mIGxlYWYgJ215LWRlY2ltYWwnIHNldCB0byA8YnI+DQoyLjU3LiA8YnI+DQo8 YnI+DQpEZWZpbml0aW9uIGV4YW1wbGUgZnJvbSBbUkZDNzMxN106IDxicj4NCjxicj4NCmxlYWYg bXktZGVjaW1hbCB7IDxicj4NCnR5cGUgZGVjaW1hbDY0IHsgPGJyPg0KZnJhY3Rpb24tZGlnaXRz IDI7IDxicj4NCnJhbmdlICZxdW90OzEgLi4gMy4xNCB8IDEwIHwgMjAuLm1heCZxdW90OzsgPGJy Pg0KfSA8YnI+DQp9IDxicj4NCjxicj4NCkNCT1IgZGlhZ25vc3RpYyBub3RhdGlvbjogMjU3IDxi cj4NCjxicj4NCiZsdDtwdmRzJmd0OyA8YnI+DQpTaG91bGQgaXQgbm90IGJlIHBvaW50ZWQgb3V0 IG1vcmUgc3Ryb25nbHkgdGhhdCB0aGUgeWFuZyB0byBjYm9yIGNvbnZlcnNpb24gZmFpbHMgaW4g dGhpcyBjYXNlPw0KPGJyPg0KSSBkb24ndCBzZWUgaG93IGEgY2hhbmdlIGZyb20gMi41NyBvciAy NTcgcmVwcmVzZW50cyBsb29zaW5nIHVubmVjZXNzYXJ5IG1ldGEgaW5mb3JtYXRpb24uDQo8YnI+ DQpVbmxlc3MgSSBjb21wbGV0ZWx5IG1pc3MgdGhlIHBvaW50IG9mIHRoZSBleGFtcGxlLiA8YnI+ DQombHQ7L3B2ZHMmZ3Q7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIDxicj4NCmNvcmUgbWFpbGluZyBsaXN0IDxicj4NCjxhIGhyZWY9 Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiA8YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8 YnI+DQpjb3JlIG1haWxpbmcgbGlzdCA8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmU8L2E+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR06MB1763BF04E17F6CC4232F2EF5FE300BLUPR06MB1763namp_-- From nobody Tue Jul 12 08:30:11 2016 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 459AF12D97D for ; Tue, 12 Jul 2016 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 STKIDchOxu2O for ; Tue, 12 Jul 2016 08:30:04 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0118.outbound.protection.outlook.com [104.47.36.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E99F12DB6E for ; Tue, 12 Jul 2016 08:07:14 -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=YcvT+9tQ7BTq2Tsbza8IR+tdm1ls7F9xjWocoXLQMLM=; b=DctC18K7ItsjDnXzxB4ELn5bfsB93Yx6a3QvP/yRi3dY8gfJz8XwUVg/Ilpv4cgj8WniZeRyufNwFjERLMYxDLB4A2FGBU4209m7T/PTigz1xz4BqCJebfXAg5Toi28iTEttWe+OOaMa613sClT6sBOlR3rGZ/PFHMCXAXYMHnU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 15:07:13 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 15:07:13 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYCugCAAFEisA== Date: Tue, 12 Jul 2016 15:07:12 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: eff7cfdd-ff78-49fe-9760-08d3aa663461 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:S43Niepu97Gx7Gmd1F10Z6VIdiYcVjQqT5R37ZqIVAZalHMIoGz1Ee0y8WrU5yYDD38O5lts9ZYLJBsrN0/DhuDUvMgxb1mVZVqrkFvFXEQoxFQzk0cQ4GmFdrAxKHl/Jk/GczrR+RuJ9TBeyV0qLOClYEogt0tghikINH8P3nrMFb/0jPEhZ401Hmu7Lb3+XC+a1UU8aUsaVfXvsAE0yzf/a1ywb2fk5rUSAYPUNQrJ56rW22aiYMP1szQEf7tjm26tTd92JSuTqa6Qh4qxVnZ+VwF/M931rUSyCqfyNOY=; 5:uco3VGZKFg0s59pyb6DiVU7Uox7VYJZJl/q5HpxSN+pZOZdX9sol7HL5jV+N1RmAeIzvfD/rBwwKLkCVkQgcC0Jt7U50GDyU0B0ryRPYd4bmYM4E9k0WPFFQV/aA2kP0eXceSsV7xPkg7TgT1rRg4w==; 24:5HTSpt/dLe3Tl8J4nNHW9HH863Hyp5H5/l/UOQ/AT8cLAD4Qkbn/hVpzHu6LEc7InvHaNa9EvN2pO8Z4hV9KlWm+fe2AyTI48A2dGG+my60=; 7:pg6fKr6MNMQr58/9x9+XjmCClqnIBB+XIHJGpBSP6Uhi5nbBw0roh4ETjT/AOtTzjmnMaob2+M6lL56ltDq+uH6EX6COwRGfWnqYtmcswjrN0bfoFyW616CqOHNn7ivzvb1r0XNNWq8M0mXUjOkblOlTFJnfwBY87icCH5K2L9SZuqkIiGyTjO7QRGN2phTP0MZJOznPNP7RUfiX7b4XI7Iy4ii8SGmECgqUhzpgr1gYEWqFVKXyQs9Hph9th8cT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(13464003)(199003)(8936002)(81156014)(81166006)(6116002)(3846002)(102836003)(10400500002)(110136002)(87936001)(86362001)(50986999)(77096005)(189998001)(3660700001)(76176999)(5002640100001)(54356999)(586003)(122556002)(2900100001)(97736004)(2950100001)(66066001)(68736007)(2351001)(92566002)(106356001)(106116001)(2906002)(33656002)(11100500001)(101416001)(4326007)(9686002)(7736002)(7696003)(5003600100003)(2501003)(8676002)(1730700003)(19580405001)(105586002)(5640700001)(99286002)(7846002)(74316002)(19580395003)(305945005)(3280700002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.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: 12 Jul 2016 15:07:13.0778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 15:30:10 -0000 Hi Peter The validations performed by the entity which de-serialize the CBOR payload= is based on the YANG schema. This validation is based on all king of YANG statements such as: key, unique, range, pattern, length, min-elements, max-elements, must, when= , if-feature The identification of which data nodes are keys is considered unnecessary m= eta-data since available in the schema. Even more heavy weight representations such as xml and json don't include t= his meta-data in the encode payload. Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Tuesday, July 12, 2016 6:08 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 Hi Michel, >=20 > However, I am missing how to transport a given list instance with its=20 > key values in the CBOR encoding. Section 4.4 describes the encoding of=20 > a complete list not a subset of its instances. >=20 > [MV] A list instance is a collection which is described in section 4.2. > ______________________________________________________________________ > _______________________ With the current text I don't see how you distinguish instances with the sa= me key from instances with different keys. Example: list server { key name; leaf name { type string; } leaf iburst { type boolean; default false; } How to distinguish that in the list below that two instances are identical = (should not occur) [ { 1755 : "NRC TIC server", # name (SID 1755) 1754 : false, # iburst (SID 1754) }, { 1755 : "NRC TIC server", # name (SID 1755) 1754 : true, # iburst (SID 1754) } ] And the following two instances are different (valid array) [ { 1755 : "NRC TAC server", # name (SID 1755) 1754 : true, # iburst (SID 1754) }, { 1755 : "NRC TIC server", # name (SID 1755) 1754 : true, # iburst (SID 1754) } ] From nobody Tue Jul 12 08:40:34 2016 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 6A24712D196 for ; Tue, 12 Jul 2016 08:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 43APKzx31x7w for ; Tue, 12 Jul 2016 08:40:28 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0125.outbound.protection.outlook.com [104.47.40.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530DF12D956 for ; Tue, 12 Jul 2016 08:28:46 -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=Rli6LJlLMdZczTPCq4yA45sgrRdmTwAffm4CLNRVt78=; b=elQ/UFqf5sYeyF8Q+r2CmQ/LOGEN9Xo6fQtBrg3eg51XaUYCWvYVs8a+cHBYhzJguAgXVlg24ypUQILzYnsg+nMn8bf2C/iBtXKkMDuwPz/huELPAQRj0lktpOP79q0DbGTqQa058h9qxTvjCjC/CmOYDueJ0UgBL+VqRTvKFOM= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 15:28:44 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 15:28:44 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Alexander Pelov Thread-Topic: [core] YANG to CBOR , identification of objects Thread-Index: AQHR3Ca9mBIkuJzWoUeQAVKUrHr926AU6aiQ Date: Tue, 12 Jul 2016 15:28:44 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> In-Reply-To: <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: a1e95204-d95f-475a-b6dc-08d3aa693651 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:awd4McXa7ilX6S8i0Rvqpt8J2mjYJ8o39q8mwbnTPZmw+BXk0L9Y/S8JilJ3K5kkRmU5ihpt8pRslsHM8yHR+F4DKxtq4E7p0oScA1m2u0fEa5TKKoFxs+LegMW2wYVuWutSeqA9h648nJa59AWYfJyiOZnwgxtWRl8A0LRqWQe6W/hc4WW7y7rlSTVRsyMZ5xTyJNow40zJQcaaniwoNWHqldSrJR9PWYtp+xj5q68365AenhbZZEQ/2Br9U9cBqiw1uI3ImRpzRlaZViu1naR6nz32icTFqc0g+WS0Wwg=; 5:wJqxQ5i+QpROS7W1lZkepT7b2js6TgZKxThKN5/ywrBj+EKO+BRWL/GYNR7AUT9PshFeaQSMS+DiDfE26rAA/mSPqFsBKXbtx8Gn6YCcyhuUopEQ+rBFAtbCdDU8leRexD9WuL+PRKlvmgHtN1REyg==; 24:HnCIR+ObPppop+r9F/1A5BwgSvMrOZHvZxQaH/lqIKX9leLAaXIy3ZGeDBBqAmYML/qfCV8kJ3k+uwZOZ31L9HtaggMRcOoY9MAUMqXKN0o=; 7:k0nwicQ6nWiTXjUNoV69oGcmuU7Zi5y6HOLKmgHj/fOI+KIXFAqvvJwpSN4eCTUUPS0AblhG/iulF08CzMZ1UUeLDVMyCp80u0peTW2wdGuQ9JJfXLmW1RWau+zhxLX8iSUKhSxNSu0l7kfC5MdCYEjkFI3AWaSSF93GbC+A4oxcouuOz6HOzHv69i8YxdL+BNIjeMR0blxvnqQTuxVcE7cjI9i/XdjD7ivvb7ivRijA54tmOHtMb1eLoGAOGg8o x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(377454003)(4326007)(2900100001)(2906002)(92566002)(2950100001)(99286002)(76576001)(50986999)(2501003)(3280700002)(3660700001)(81166006)(81156014)(3846002)(6116002)(8936002)(74316002)(122556002)(5002640100001)(102836003)(586003)(11100500001)(19580395003)(19580405001)(66066001)(9686002)(305945005)(8676002)(7696003)(68736007)(7736002)(5003600100003)(10400500002)(87936001)(33656002)(106116001)(101416001)(106356001)(86362001)(77096005)(105586002)(5001770100001)(54356999)(189998001)(76176999)(7846002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 15:28:44.6242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR , identification of objects X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 15:40:33 -0000 SGkgUGV0ZXINCg0KVHJhbnNmZXJyaW5nIHRoZSBjb25jZXB0IG9mIHBhcmVudCBkZWx0YXMgZnJv bSAiZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvciIgdG8gImRyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNv b2wiIGlzIHRlY2huaWNhbGx5IHBvc3NpYmxlLg0KVGhpcyBjaGFuZ2UgcmVxdWlyZSBzb21lIGxl dmVsIG9mIGVmZm9ydCBzbyBJIHdpbGwgcHJlZmVyIHRvIGdldCBhIGNvbnNlbnN1cyBmcm9tIGEg bGFyZ2VyIGdyb3VwIGJlZm9yZSBtb3ZpbmcgYWhlYWQuDQpDYXJzdGVuLCBBbGV4YW5kZXIsIEFi aGksIFJhbmR5LCBBbmEsIC4uLiBkbyB5b3UgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGFib3V0IHRo ZSBhcHByb2FjaCBwcm9wb3NlZCBieSBQZXRlcj8NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGV0ZXIgdmFuIGRlciBTdG9rIFttYWlsdG86 c3Rva2NvbnNAeHM0YWxsLm5sXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTIsIDIwMTYgNjoxOCBB TQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNv bT4NCkNjOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzsgQ29yZSA8Y29yZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbY29yZV0gWUFORyB0byBDQk9SICwgaWRlbnRpZmljYXRpb24gb2Ygb2Jq ZWN0cw0KDQpIaSBNaWNoZWwsDQoNCkhlcmUgd2UgaGF2ZSBhIHBvaW50IHdoZXJlIG15IHZpc2lv biBvbiB0aGlzIGRvY3VtZW50IGRpZmZlcnMgZnJvbSB5b3Vycy4NCg0KPiANCj4gU2VjdGlvbiAz OiDigJx0aGUgc3BlY2lmaWNhdGlvbiBzdXBwb3J0cyB0aHJlZSB0eXBlcyBvZiBrZXlzLuKAnQ0K PiBJIHdvdWxkIHN1Z2dlc3Qgb25seSAyOiBjaGFyYWN0ZXIgc3RyaW5ncyBhbmQgbnVtYmVycy4N Cj4gVGhlIHVzZSBvZiBkZWx0YXMgaXMgZWl0aGVyIGFwcGxpY2F0aW9uIChDb09MKSBzcGVjaWZp YyBvciBZQU5HIHRvIA0KPiBDQk9SIG1hcHBpbmcgc3BlY2lmaWMuDQo+IElmIGl0IGlzIFlBTkcg dG8gQ0JPUiBzcGVjaWZpYywgSSB3b3VsZCBlbmNvdXJhZ2UgdGhlIHVzZSBvZiBhbm90aGVyIA0K PiBDQk9SIHR5cGUgdGhhdCBzcGVjaWZpZXMgYSBkZWx0YS4gQXMgc3BlY2lmaWVkIGhlcmUgaXRz IHVzZSBpcyANCj4gYW1iaWd1b3VzOyBhbmQgZm9yY2VzIGVhY2ggYXBwbGljYXRpb24gdG8gc3Bl Y2lmeSBleHBsaWNpdGx5IHdoYXQgaXMgDQo+IG1lYW50Lg0KPiBJbiB0aGUgY2FzZSB0aGF0IHRo ZSBkZWx0YSBpcyBDb09MIHNwZWNpZmljLCBJIHJlY29tbWVuZCB0byByZW1vdmUgaXQgDQo+IGNv bXBsZXRlbHkgZnJvbSB0aGlzIGRyYWZ0LCBhbmQgZXhwbGFpbiB0aGUgdXNlIG9mIERlbHRhcyBp biB0aGUgDQo+IGFwcHJvcHJpYXRlIENvT0wgZHJhZnQuDQo+IEluIHRoZSBsYXR0ZXIgY2FzZTog V2hhdCByZW1haW5zIGFyZSB0d28ga2V5IHR5cGVzOiBudW1iZXIgYW5kIA0KPiBjaGFyYWN0ZXIg c3RyaW5nLg0KPiANCj4gW01WXSBUaGUgdXNlIG9mIGRlbHRhIHRvIGVuY29kZSBpbnRlZ2VyIGJh c2VkIGtleXMgKFNJRHMpIGlzIGFuIA0KPiBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSBZQU5HIHRvIENC T1IgbWFwcGluZy4NCj4gW01WXSBUaGlzIG9wdGltaXphdGlvbiBpcyBwYXJ0IG9mIHRoZSBlbmNv ZGluZyBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIA0KPiBhcHBsaWNhdGlvbi4NCj4gW01WXSBUaGUg ZG9jdW1lbnQgaXMgdXBkYXRlZCB0byBrZWVwIG9ubHkgMiB0eXBlIG9mIGtleXMNCj4gDQoNCkkg YW0gcHJlcGFyaW5nIGEgdGhpcmQgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgYSBsb2NhbCBudW1i ZXJpbmcgc2NoZW1lIGZvciBZQU5HIGlkZW50aWZpZXJzIGJhc2VkIG9uIGRpc2NvdmVyeS4NClRo ZSBudW1iZXJzIHdpbGwgYmUgcXVpdGUgc21hbGwgYW5kIEkgbGlrZSB0byBlbmNvZGUgdGhlbSBh cyB1bnNpZ25lZCBpbnRlZ2Vycy4NCkhvd2V2ZXIsIHdpdGggdGhlIHByZXNlbnQgWUFORyB0byBD Qk9SIGRvY3VtZW50IHNvbWUgbnVtYmVycyBtdXN0IGJlIGVuY29kZWQgYXMgRGVsdGFzLCBhbmQg dGhhdCBpcyBub3Qgd2hhdCBJIHdhbnQuDQoNClRoZXJlZm9yZSBJIHJlY29tbWVuZCB0aGF0IGFs bCBoYXNoIGNvbnZlcnNpb24gdG8gQ0JPUiBnb2VzIHRvIHRoZSB5YW5nLWhhc2ggZG9jdW1lbnQg YW5kIHRoZSBTSUQgY29udmVyc2lvbiB0byBDQk9SIGdvZXMgdG8gYW4gYXBwcm9wcmlhdGUgQ29P TCBkb2N1bWVudC4NCmFuZCB0aGUgY29taW5nIG51bWJlcmluZyBjb252ZXJzaW9uIHRvIENCT1Ig YWxzbyB0cmVhdHMgaXQgaW4gYW4gYXBwcm9wcmlhdGUgZG9jdW1lbnQNCg0KVGhpcyBkb2N1bWVu dCBjYW4gdGhlbiBzcGVjaWZ5IHRoYXQgaWRlbnRpZmllcnMgY2FuIGJlIHN0cmluZ3MgYW5kIG51 bWJlcnMsIHdoZXJlIGZvciBleGFtcGxlIG51bWJlcnMgYXJlIGVuY29kZWQgYXMgdW5zaWduZWQg aW50ZWdlcnMuDQoNCkdyZWV0aW5ncywNCg0KUGV0ZXINCg0K From nobody Tue Jul 12 09:00:22 2016 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 D58E412D17B for ; Tue, 12 Jul 2016 09:00:19 -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 nwO2T5-o0NRl for ; Tue, 12 Jul 2016 09:00:18 -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 8B4A512D1BD for ; Tue, 12 Jul 2016 09:00:15 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1] (unknown [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7F87FA80E5; Tue, 12 Jul 2016 18:00:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Tue, 12 Jul 2016 18:00:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5515F750-2744-4A83-A593-B8C43B72AA54@ackl.io> References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> To: Michel Veillette X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexander Pelov , Core Subject: Re: [core] YANG to CBOR , identification of objects X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:00:20 -0000 Hi Michel, Peter, I would be indeed very interested in seing this new local numbering = scheme.=20 I would suggest that we keep the delta encoding as it is right now and = decide how to proceed when we have the new numbering scheme.=20 Does that sound reasonable?=20 Best, Alexander PS. As a preview, can this new numbering scheme be implemented by using the = experimental/private SID range? > Le 12 juil. 2016 =C3=A0 17:28, Michel Veillette = a =C3=A9crit : >=20 > Hi Peter >=20 > Transferring the concept of parent deltas from = "draft-ietf-core-yang-cbor" to "draft-veillette-core-cool" is = technically possible. > This change require some level of effort so I will prefer to get a = consensus from a larger group before moving ahead. > Carsten, Alexander, Abhi, Randy, Ana, ... do you have a strong opinion = about the approach proposed by Peter? >=20 > Regards, > Michel >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 > Sent: Tuesday, July 12, 2016 6:18 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR , identification of objects >=20 > Hi Michel, >=20 > Here we have a point where my vision on this document differs from = yours. >=20 >>=20 >> Section 3: =E2=80=9Cthe specification supports three types of = keys.=E2=80=9D >> I would suggest only 2: character strings and numbers. >> The use of deltas is either application (CoOL) specific or YANG to=20 >> CBOR mapping specific. >> If it is YANG to CBOR specific, I would encourage the use of another=20= >> CBOR type that specifies a delta. As specified here its use is=20 >> ambiguous; and forces each application to specify explicitly what is=20= >> meant. >> In the case that the delta is CoOL specific, I recommend to remove it=20= >> completely from this draft, and explain the use of Deltas in the=20 >> appropriate CoOL draft. >> In the latter case: What remains are two key types: number and=20 >> character string. >>=20 >> [MV] The use of delta to encode integer based keys (SIDs) is an=20 >> integral part of the YANG to CBOR mapping. >> [MV] This optimization is part of the encoding and independent of the=20= >> application. >> [MV] The document is updated to keep only 2 type of keys >>=20 >=20 > I am preparing a third document that describes a local numbering = scheme for YANG identifiers based on discovery. > The numbers will be quite small and I like to encode them as unsigned = integers. > However, with the present YANG to CBOR document some numbers must be = encoded as Deltas, and that is not what I want. >=20 > Therefore I recommend that all hash conversion to CBOR goes to the = yang-hash document and the SID conversion to CBOR goes to an appropriate = CoOL document. > and the coming numbering conversion to CBOR also treats it in an = appropriate document >=20 > This document can then specify that identifiers can be strings and = numbers, where for example numbers are encoded as unsigned integers. >=20 > Greetings, >=20 > Peter >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 12 09:01:09 2016 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 C4E3912D1AE for ; Tue, 12 Jul 2016 09:01: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 4biG6NI09C6m for ; Tue, 12 Jul 2016 09:01:06 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A9A12D1BD for ; Tue, 12 Jul 2016 09:01:02 -0700 (PDT) Received: from mfilter39-d.gandi.net (mfilter39-d.gandi.net [217.70.178.170]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B87A441C0B8; Tue, 12 Jul 2016 18:01:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter39-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter39-d.gandi.net (mfilter39-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qa-_AsrIhqUW; Tue, 12 Jul 2016 18:00:59 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 7DEBC41C0C0; Tue, 12 Jul 2016 18:00:57 +0200 (CEST) Message-ID: <57851437.2070405@tzi.org> Date: Tue, 12 Jul 2016 18:00:55 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michel Veillette References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Alexander Pelov , Core Subject: Re: [core] YANG to CBOR , identification of objects X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:01:08 -0000 Michel Veillette wrote: > do you have a strong opinion about the approach proposed by Peter? Actually I'm intrigued as to what that approach will be; until we know that, I'd be a bit weary about moving things around. So far, I have been quite happy with the parent delta approach, but I'm not sure we have really succeeded in explaining it succinctly and unambiguously. For instance, what happens if a data structure is buried further into another one that itself doesn't have a SID? I'm not a big fan of specification-by-algorithm, but here it probably *would* help to phrase this as an algorithm (preferably functional). Cf. RFC 7396: The pseudo-code on page 4 really helps understanding the obtuse language around it. Given that the CBOR data model maps right into data structures that can be addressed by pseudo code, specifying the "decoder" (as is usual for compression algorithms) should be lean and precise. Grüße, Carsten From nobody Tue Jul 12 09:07:05 2016 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 F3CEE12D13E; Tue, 12 Jul 2016 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 2lPX1VOXgGQN; Tue, 12 Jul 2016 09:07:02 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0109.outbound.protection.outlook.com [104.47.40.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A5E12B014; Tue, 12 Jul 2016 09:07:01 -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=9nDKYBXBtdykOAqUDKApTIlvw6SuY29qH+0DG125eeY=; b=bnIYJjhz9aGPkKtuUqfJxdiV1z5PONIbARKgq4+5dj2bm/MRlu15+9Z4Cf8diQASS7XLv3tr4UHL9R7bZcWQsuMU+8CUm+sGfDA2roAp7G7gF4EhNWRtBXedB22ecg5TfQ9646Zo+OFvFKKEpBtt/+hY1LQCEOkivkDAHtcYNVU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 16:07:00 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 16:07:00 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , "draft-ietf-core-yang-cbor@ietf.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYHI4CAAF1HgA== Date: Tue, 12 Jul 2016 16:07:00 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <6ce5c06ff1c64d834ce1ccdda7b61ea4@xs4all.nl> In-Reply-To: <6ce5c06ff1c64d834ce1ccdda7b61ea4@xs4all.nl> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 82870a71-8e87-4aa4-09c7-08d3aa6e8ec0 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:B/NeKalQo1RJ0xbdzoy33nwUnmtwnGNxR+z4gA9s2nVZK0ycgsd6cFkrvVseJLJYvJXIsQMugAV8DoCjqJLwX+T/PAB520zQG1lRXNAww7jfC9VKwzYw5NbJI8SsREobH6+J68B2xR4B0Lg059ckyAXp10YBtTS4q+ucKyH4v+e0KdQWZz4UPWoCq/BRpnvBz9FuNWbf7c1m06PuSAgdAu02Wr/cL06ABIRbiQBu/64SyenLYU4nS/MRXUBs2VomrgaSBe3J/xRadu7Gr9l5UDc0I5sn1CBZ8HHNzdeT6b8=; 5:gp0cKj30Aos14BbuvQcSBImHvpy18D1o+H0R1OuDNqM/YhfTSxbZP6LX34KMVrRznUskU7bkWgL3XpP1cRffTkdrGrS/5Xx6wD12gNmJ4qe3fQ4hG/wyAE9x0ej4ziiy9Yd6+kf1l1cqsQSpTGXF+w==; 24:5/3liZB8t+1XHV3ox0wso2moqMofOD1nn9g8xiKa7CDT1MR+bt3XPJRVtFqUqtLSuIU2QEURbd0w8xvIdL4mH4DnhQgCu/6nbMSiiYuGoCY=; 7:J3MsdCPpioa+X3sR0/4c5uqjas0+dOiqJvdoxbokHKS0YlodhartDweIfvK221TNmD2TPCVVvqcUL8JRmdURb53llGKUg7vVsVM+0Ls5H+Kofc5Y9l605JNVEepOAxBk1ofIMrFoLO/64bl7EQVqG1akHxUBdhjM46y6zj92jS5GEQ3MLrZCMpPuyvr3zHuGxggLUgfyLa5gcys3k4GekRYcanuxydj//3twWziOikbAmRqfd6lh8sdRxyyI2MCn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(51444003)(13464003)(199003)(33656002)(10400500002)(8676002)(86362001)(8936002)(105586002)(11100500001)(87936001)(66066001)(81156014)(81166006)(189998001)(97736004)(5003600100003)(5001770100001)(7846002)(7736002)(7696003)(50986999)(76176999)(74316002)(68736007)(19580405001)(6116002)(305945005)(76576001)(54356999)(2501003)(99286002)(101416001)(3846002)(9686002)(15975445007)(102836003)(2950100001)(5002640100001)(586003)(2900100001)(19580395003)(77096005)(3660700001)(92566002)(106116001)(106356001)(3280700002)(2906002)(4326007)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.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: 12 Jul 2016 16:07:00.3923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:07:04 -0000 Hi Peter Are you proposing to move all examples in an appendix or just the larger on= es. Most examples are single liners. Should I move only the following ones: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.1 https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.2 https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.4.1 https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.4.2 Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Tuesday, July 12, 2016 6:23 AM To: Michel Veillette ; draft-ietf-core-y= ang-cbor@ietf.org Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 I forgot to add the following in an earlier e_mail, Bit stupid to annoy all= wg members with this trivial remark >=20 > I think that a large number of the CBOR encoding examples in section > 4.2 can be left out. > They can be generated any time by an interested implementer; and now=20 > confuse the issues. >=20 > [MV] I received many questions about the final encoding and the number=20 > of bytes required. > [MV] If I remove these examples, I'm concern that I will receive even=20 > more of these questions. > [MV] I agree that these examples are useless for peoples with a good=20 > knowledge of CBOR [MV] but seem very welcome from newcomers. >=20 What about putting them in an appendix? Peter From nobody Tue Jul 12 09:10:03 2016 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 0B17112D16D for ; Tue, 12 Jul 2016 09:10:02 -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 Mh4YR9nJADKo for ; Tue, 12 Jul 2016 09:10:00 -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 01C7A12B076 for ; Tue, 12 Jul 2016 09:10:00 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1] (unknown [IPv6:2001:660:7301:3728:c991:5594:6177:ccd1]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A7010A8100; Tue, 12 Jul 2016 18:09:55 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BEA24FC4-BF9B-44BD-8EE4-6D69642C2465" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Tue, 12 Jul 2016 18:09:53 +0200 Message-Id: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> To: Michel Veillette X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:10:02 -0000 --Apple-Mail=_BEA24FC4-BF9B-44BD-8EE4-6D69642C2465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michel, If there is a way to unambiguously differentiate between union and = non-union, then we should use the most efficient representation. = However, I get the impression that you can modify locally a module, = which could change the type of a leaf from decimal to union.. which = could then lead to confusion.=20 One of the main issues we=E2=80=99re having is the possible mismatch = between the module versions on a server and a client. How about this -=20= 1) we define a (lightweight) mechanism for ensuring the matching of the = module versions 2) if matching, then use most efficient representation (e.g. encode 2.57 = as 257) 3) if not matching, then use tags for all representations How does this sound?=20 Alexander =20 > Le 12 juil. 2016 =C3=A0 16:57, Michel Veillette = a =C3=A9crit : >=20 > Hi Alexander > =20 > I want to be sure of your answer. > The CBOR tag 4 (Decimal fraction) require 3 bytes of overhead, see = example for RFC 8049 section 2.4.3 bellow. > This is the tag you are proposing? > This tag will be used all the time (within the context of a union and = without)? > =20 > C4 # Tag 4 > 82 # Array of length 2 > 21 # -2 > 19 0101 # unsigned(257) > =20 > Regards, > Michel > =20 > From: core [mailto:core-bounces@ietf.org = ] On Behalf Of Alexander Pelov > Sent: Tuesday, July 12, 2016 9:50 AM > To: Carsten Bormann > > Cc: Core > > Subject: Re: [core] YANG to CBOR mapping version 1 > =20 > Hi Carsten, > =20 > Yes, you are right. I thought that we could keep this representation = outside of unions. But of course, we need to balance the complexity of = doing this.=20 > =20 > There could be a confusion if the server and the client have different = versions of the same module (rare, but must be taken care of). Which is = of course, the thing we=E2=80=99ve always tried to avoid.. So yeah, for = the moment we could keep the CBOR decimal tag.=20 > =20 > Best, > Alexander > =20 > Le 12 juil. 2016 =C3=A0 12:59, Carsten Bormann > a =C3=A9crit : > =20 > Hi Alexander, >=20 > This is right. However, I thought that in the discussion of unions we = had arrived at encoding decimals as CBOR decimal fraction tags. But = maybe I'm misremembering.=20 >=20 > Gr=C3=BC=C3=9Fe, Carsten=20 >=20 > On 12 Jul 2016 12:04, Alexander Pelov wrote:=20 >=20 > Dear Peter,=20 >=20 > In this case you can infer the decimal point position from the YANG = definition, e.g. the statement "fraction-digits 2;"=20 >=20 > Which indicates that 257 represents the number 2.57. 2 represents = 0.02, 50 represents 0.50, 1000 represents 10.00=20 >=20 > I think that you are right that we should provide more examples to be = clear on this point.=20 >=20 > Best,=20 > Alexander=20 >=20 >=20 > Le 12 juil. 2016 =C3=A0 11:58, peter van der Stok > a =C3=A9crit :=20 >=20 > Hi Michel,=20 >=20 > I separated my answer into three parts to simplify the discussion.=20 >=20 >=20 > Section 5.3;=20 > In the example, where do I find in the CBOR encoding that the fraction=20= > is 2 digits?=20 > [MV] The number of digits is not encoded. This information is=20 > considered an unnecessary metadata=20 > [MV] similar to "units", text of an enumeration, name of a flag within=20= > bits. This was the consensus=20 > [MV] of the group which is aligned with the statement in section 3 (In=20= > order to minimize the size of=20 > [MV] the encoded data, the proposed mapping avoid any unnecessary=20 > meta-information beyond=20 > [MV] those natively supported by CBOR.)=20 > [MV] It might be worth it to raise this topic within a larger = audience.=20 >=20 > The following example shows the encoding of leaf 'my-decimal' set to=20= > 2.57.=20 >=20 > Definition example from [RFC7317]:=20 >=20 > leaf my-decimal {=20 > type decimal64 {=20 > fraction-digits 2;=20 > range "1 .. 3.14 | 10 | 20..max";=20 > }=20 > }=20 >=20 > CBOR diagnostic notation: 257=20 >=20 > =20 > Should it not be pointed out more strongly that the yang to cbor = conversion fails in this case?=20 > I don't see how a change from 2.57 or 257 represents loosing = unnecessary meta information.=20 > Unless I completely miss the point of the example.=20 > =20 >=20 > _______________________________________________=20 > core mailing list=20 > core@ietf.org =20 > https://www.ietf.org/mailman/listinfo/core = >=20 > _______________________________________________=20 > core mailing list=20 > core@ietf.org =20 > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_BEA24FC4-BF9B-44BD-8EE4-6D69642C2465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michel,

If there is a way to unambiguously differentiate between = union and non-union, then we should use the most efficient = representation. However, I get the impression that you can modify = locally a module, which could change the type of a leaf from decimal to = union.. which could then lead to confusion. 
One of the main issues we=E2=80=99re = having is the possible mismatch between the module versions on a server = and a client. How about this - 
1) we define a = (lightweight) mechanism for ensuring the matching of the module = versions
2) if matching, then use most efficient = representation (e.g. encode 2.57 as 257)
3) if not = matching, then use tags for all representations

How does this sound? 

Alexander
 

Le 12 juil. 2016 =C3=A0 16:57, = Michel Veillette <Michel.Veillette@trilliantinc.com> a =C3=A9crit = :

Hi= Alexander
 
I want to be sure of your answer.
The CBOR tag 4 (Decimal fraction) require 3 bytes of overhead, see = example for RFC 8049 section 2.4.3 bellow.
This is the tag you are proposing?
This tag will be used all the time (within the context of a = union and without)?
 
C4 =             # = Tag 4
  82 =           # Array of = length 2
    21 =         # -2
    19 0101    # = unsigned(257)
 
Regards,
Michel
 
From: core [mailto:core-bounces@ietf.org] On Behalf = Of Alexander = Pelov
Sent: Tuesday, July 12, 2016 9:50 = AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Core = <core@ietf.org>
Subject: Re: [core] YANG to CBOR = mapping version 1
 
Hi Carsten,
 
Yes, you are right. I thought that we could keep this = representation outside of unions. But of course, we need to balance the = complexity of doing this. 
 
There could be a confusion if the server and the = client have different versions of the same module (rare, but must be = taken care of). Which is of course, the thing we=E2=80=99ve always tried = to avoid.. So yeah, for the moment we could keep the CBOR decimal = tag. 
 
Best,
Alexander
 
Le 12 juil. 2016 =C3=A0= 12:59, Carsten Bormann <cabo@tzi.org> a =C3=A9crit :
 
Hi Alexander,

This is right. However, I thought that in the = discussion of unions we had arrived at encoding decimals as CBOR decimal = fraction tags. But maybe I'm misremembering. 

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


On 12 Jul 2016 12:04, Alexander Pelov = wrote: 

Dear Peter, 

In this case you can infer the decimal point position from = the YANG definition, e.g. the statement "fraction-digits 2;" 

Which indicates that 257 represents the number 2.57. 2 = represents 0.02, 50 represents 0.50, 1000 represents 10.00 

I think that you are right that we should provide more = examples to be clear on this point. 

Best, 
Alexander 

Le 12 juil. 2016 =C3=A0 11:58, peter van = der Stok <stokcons@xs4all.nl>= a =C3=A9crit : 

Hi Michel, 

I separated my answer into three parts to simplify the = discussion. 


Section 5.3; 
In the = example, where do I find in the CBOR encoding that the fraction 
is 2 = digits? 
[MV] The number of digits is not encoded. This information = is 
considered an unnecessary metadata 
[MV] similar = to "units", text of an enumeration, name of a flag within 
bits. This = was the consensus 
[MV] of the group which is aligned with the statement in = section 3 (In 
order to minimize the size of 
[MV] the = encoded data, the proposed mapping avoid any unnecessary 
meta-information beyond 
[MV] those = natively supported by CBOR.) 
[MV] It = might be worth it to raise this topic within a larger audience. 

The following example shows the encoding of = leaf 'my-decimal' set to 
2.57. 

Definition example from [RFC7317]: 

leaf my-decimal { 
type = decimal64 { 
fraction-digits 2; 
range "1 .. = 3.14 | 10 | 20..max"; 
} 
} 

CBOR diagnostic notation: 257 

<pvds> 
Should it = not be pointed out more strongly that the yang to cbor conversion fails = in this case? 
I don't see how a change from 2.57 or 257 represents loosing = unnecessary meta information. 
Unless I = completely miss the point of the example. 
</pvds> 

_______________________________________________ 
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

<= /blockquote>
=

= --Apple-Mail=_BEA24FC4-BF9B-44BD-8EE4-6D69642C2465-- From nobody Tue Jul 12 09:13:44 2016 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 8870B12D08E for ; Tue, 12 Jul 2016 09:13:43 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13o2H5zKdiWq for ; Tue, 12 Jul 2016 09:13:42 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1FB12D1BD for ; Tue, 12 Jul 2016 09:13:40 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud2.xs4all.net with ESMTP id HsDd1t00C4fjQrE01sDd4L; Tue, 12 Jul 2016 18:13:37 +0200 Received: from 2001:983:a264:1:3cd6:f15d:4351:471 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 18:13:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Jul 2016 18:13:37 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <6ce5c06ff1c64d834ce1ccdda7b61ea4@xs4all.nl> Message-ID: <3d2abcfb8802e1b64b6e15c3be719d17@xs4all.nl> X-Sender: stokcons@xs4all.nl (lmFclmnfZjZ9s9i6GrmYPZFGhGXhSz2w) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-yang-cbor@ietf.org, Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 16:13:43 -0000 Hi Michel, the proposal is to keep one larger JSON examples, accompanied by its CBOR conversion, and all other larger examples to the appendix. The one liners are perfect as they are. It is only a minor suggestion to improve the reading. Peter Michel Veillette schreef op 2016-07-12 18:07: > Hi Peter > > Are you proposing to move all examples in an appendix or just the > larger ones. > Most examples are single liners. > > Should I move only the following ones: > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.1 > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.2 > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.4.1 > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.4.2 > > Regards, > Michel > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday, July 12, 2016 6:23 AM > To: Michel Veillette ; > draft-ietf-core-yang-cbor@ietf.org > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 > > I forgot to add the following in an earlier e_mail, Bit stupid to > annoy all wg members with this trivial remark > >> >> I think that a large number of the CBOR encoding examples in section >> 4.2 can be left out. >> They can be generated any time by an interested implementer; and now >> confuse the issues. >> >> [MV] I received many questions about the final encoding and the number >> of bytes required. >> [MV] If I remove these examples, I'm concern that I will receive even >> more of these questions. >> [MV] I agree that these examples are useless for peoples with a good >> knowledge of CBOR [MV] but seem very welcome from newcomers. >> > > What about putting them in an appendix? > > Peter From nobody Tue Jul 12 09:29:29 2016 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 E5B2612D559 for ; Tue, 12 Jul 2016 09:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 zGsQjwoi3XMQ for ; Tue, 12 Jul 2016 09:29:27 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0118.outbound.protection.outlook.com [104.47.37.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB1412D548 for ; Tue, 12 Jul 2016 09:29:20 -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=2yDhJj41H+cnKWyhah2AVGdN6BCryi+uDaCP/J/8Jak=; b=lkDuLHGbhbcJGg2NkbFifLFqt6wO0Vzjq57bz+4/32mrHZP0gwZ81Jtu9M318mxvYxBXHDS7tyx4tFuAzI5uStzsu3pt/6WE00Zjw1CUQr+YRToaIhzeZkMVDrbVPz51mmU7rqUb1D90wjZpb2LMyoKnhjNjkNG0NJnvupKtDVE= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 16:29:19 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 16:29:19 +0000 From: Michel Veillette To: Carsten Bormann Thread-Topic: [core] YANG to CBOR , identification of objects Thread-Index: AQHR3Ca9mBIkuJzWoUeQAVKUrHr926AU6aiQgAALL4CAAATzQA== Date: Tue, 12 Jul 2016 16:29:19 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> <57851437.2070405@tzi.org> In-Reply-To: <57851437.2070405@tzi.org> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 0d10bc2a-f650-4829-0924-08d3aa71ac99 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:RJwvoMSb62U637AKyofw11xeOeoEY+KNkjudvP+aSksbULze1nqK/VntFvVV5eCL8esqqcDyAU9ZzDYsJ6aRjFyVGtE1QzsjAI8KuACySy7jnBuQg9+LxMA2FdwS9x7m6y2VhANxdJHDpTYMyFoDw+TEZK4sCerMJ8n+DBcPuyxLI5+LEs0Igd7wA8bWdlqP/BcchSfCpR3HeQLUBHxpehTKlN09CU97nMKWzski3V8kWNGTxAzD5BhR52kzdX/GDSe21CGKqjUE0EF24De3MjpdHhP5MEF+J3DRCtvc/9A=; 5:rJuEKQori3l5qeW4eo09tjO5Otb3hXWGE50ooOJDBsRIp0ccV/HI2vtWh2GD8K0A03n9T+HFBMwVO4fY/rD8yC+9TXX1stoG4wUrYowq35T8OkB5meY9DMzP3gaYXYNAPUjfoXsPlrdaLM7g9LLYlQ==; 24:jJY5VySSxXOLWz1q68vPf+gJ9eyi12iI3nsOXWkjkH3y3+xyiHX3iLt/md0qXtlQjbqNNnc1chBkVBXh4kOUWRvJk7/slxU1bkUWAqwXD2Q=; 7:nNH8kuQu/nFSVI1+3OOvz6bGF40nKSPTWKMWiKrM/7lfiASrFQ9aJvyRvreUBWrPjRZydvsEXY8mSYr2bCfQ6LzK1ujkYYJb5oIA7LUhbrWiUApjRo9fOn647rpbtk3C3TZq+fpc3mLsZN+kHvU5Nv7vftzFqLaCUyYKxmz7DOPakLIW/2HkLMkXq73ALWZbNGovFZKY5W9V9ERkPnZ6FnWjMukqPmQHZH+k5j3YYUE+BEPtc3nNi9fl28B4B5jp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(13464003)(199003)(10400500002)(33656002)(8676002)(86362001)(8936002)(105586002)(11100500001)(87936001)(66066001)(81156014)(81166006)(189998001)(110136002)(97736004)(5003600100003)(7846002)(7736002)(7696003)(50986999)(76176999)(74316002)(68736007)(19580405001)(6116002)(305945005)(76576001)(54356999)(99286002)(101416001)(3846002)(9686002)(15975445007)(102836003)(2950100001)(5002640100001)(586003)(2900100001)(19580395003)(77096005)(93886004)(3660700001)(92566002)(106116001)(106356001)(3280700002)(2906002)(4326007)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.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: 12 Jul 2016 16:29:19.0996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Alexander Pelov , Core Subject: Re: [core] YANG to CBOR , identification of objects X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:29:29 -0000 SGkgQ2Fyc3Rlbg0KDQpBYm91dCAiIGlzIGJ1cmllZCBmdXJ0aGVyIGludG8gYW5vdGhlciBvbmUg dGhhdCBpdHNlbGYgZG9lc24ndCBoYXZlIGEgU0lEIi4NCg0KTm8gc3VyZSB3aGF0IGRvIHlvdSBt ZWFucyBieSAiZG9lc24ndCBoYXZlIGEgU0lEIi4NCkRvIHlvdSBtZWFucyB0aGF0IHRoZSBhc3Nv Y2lhdGVkIFNJRCBpcyBlbmNvZGVkIGFzIGEgZGVsdGE/DQoNCkVhY2ggZGF0YSBub2RlIGlzIGFz c29jaWF0ZWQgdG8gYSBTSUQuDQpTSURzIG9mIGRhdGEgbm9kZSBjaGlsZHJlbiBhcmUgZW5jb2Rl ZCB1c2luZyBhIGRlbHRhIGZyb20gdGhlIHBhcmVudCBTSUQgKGluZGVwZW5kZW50bHkgaWYgdGhp cyBwYXJlbnQgU0lEIGluIGFsc28gZW5jb2RlZCBhcyBhIGRlbHRhKS4NClRoZSBleGFtcGxlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLTAyI3Nl Y3Rpb24tNC4yLjEgc2hvdWxkIGJlIGVuaGFuY2VkIHRvIHNob3cgdGhpc2Nhc2UuDQpUaGUgZGVz Y3JpcHRpb24gY2FuIGFsc28gYmUgZW5oYW5jZWQsIEknbGwgY2hlY2sgd2hhdCBJIGNhbiBkbyBm b3IgdGhlIGFsZ29yaXRobS4NCg0KKENhcnN0ZW4pIERvIHlvdSBoYXZlIGFuIGV4YW1wbGUgb2Yg YSBzaW1pbGFyIHR5cGUgb2YgYWxnb3JpdGhtIChzZXJpYWxpemF0aW9uKSB0byBzaGFyZT8NCg0K UmVnYXJkcywNCk1pY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fy c3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkg MTIsIDIwMTYgMTI6MDEgUE0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudGluYy5jb20+DQpDYzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7IEFsZXhh bmRlciBQZWxvdiA8YWxleGFuZGVyLnBlbG92QHRlbGVjb20tYnJldGFnbmUuZXU+OyBDb3JlIDxj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBZQU5HIHRvIENCT1IgLCBpZGVudGlm aWNhdGlvbiBvZiBvYmplY3RzDQoNCk1pY2hlbCBWZWlsbGV0dGUgd3JvdGU6DQo+IGRvIHlvdSBo YXZlIGEgc3Ryb25nIG9waW5pb24gYWJvdXQgdGhlIGFwcHJvYWNoIHByb3Bvc2VkIGJ5IFBldGVy Pw0KDQpBY3R1YWxseSBJJ20gaW50cmlndWVkIGFzIHRvIHdoYXQgdGhhdCBhcHByb2FjaCB3aWxs IGJlOyB1bnRpbCB3ZSBrbm93IHRoYXQsIEknZCBiZSBhIGJpdCB3ZWFyeSBhYm91dCBtb3Zpbmcg dGhpbmdzIGFyb3VuZC4NCg0KU28gZmFyLCBJIGhhdmUgYmVlbiBxdWl0ZSBoYXBweSB3aXRoIHRo ZSBwYXJlbnQgZGVsdGEgYXBwcm9hY2gsIGJ1dCBJJ20gbm90IHN1cmUgd2UgaGF2ZSByZWFsbHkg c3VjY2VlZGVkIGluIGV4cGxhaW5pbmcgaXQgc3VjY2luY3RseSBhbmQgdW5hbWJpZ3VvdXNseS4N CkZvciBpbnN0YW5jZSwgd2hhdCBoYXBwZW5zIGlmIGEgZGF0YSBzdHJ1Y3R1cmUgaXMgYnVyaWVk IGZ1cnRoZXIgaW50byBhbm90aGVyIG9uZSB0aGF0IGl0c2VsZiBkb2Vzbid0IGhhdmUgYSBTSUQ/ DQoNCkknbSBub3QgYSBiaWcgZmFuIG9mIHNwZWNpZmljYXRpb24tYnktYWxnb3JpdGhtLCBidXQg aGVyZSBpdCBwcm9iYWJseQ0KKndvdWxkKiBoZWxwIHRvIHBocmFzZSB0aGlzIGFzIGFuIGFsZ29y aXRobSAocHJlZmVyYWJseSBmdW5jdGlvbmFsKS4NCkNmLiBSRkMgNzM5NjogVGhlIHBzZXVkby1j b2RlIG9uIHBhZ2UgNCByZWFsbHkgaGVscHMgdW5kZXJzdGFuZGluZyB0aGUgb2J0dXNlIGxhbmd1 YWdlIGFyb3VuZCBpdC4NCg0KR2l2ZW4gdGhhdCB0aGUgQ0JPUiBkYXRhIG1vZGVsIG1hcHMgcmln aHQgaW50byBkYXRhIHN0cnVjdHVyZXMgdGhhdCBjYW4gYmUgYWRkcmVzc2VkIGJ5IHBzZXVkbyBj b2RlLCBzcGVjaWZ5aW5nIHRoZSAiZGVjb2RlciIgKGFzIGlzIHVzdWFsIGZvciBjb21wcmVzc2lv biBhbGdvcml0aG1zKSBzaG91bGQgYmUgbGVhbiBhbmQgcHJlY2lzZS4NCg0KR3LDvMOfZSwgQ2Fy c3Rlbg0K From nobody Tue Jul 12 23:31:39 2016 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 1FD3C12B031 for ; Tue, 12 Jul 2016 23:31:38 -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 kOtErOmKUNAH for ; Tue, 12 Jul 2016 23:31:36 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B6012B028 for ; Tue, 12 Jul 2016 23:31:35 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud6.xs4all.net with ESMTP id J6XW1t00L4fjQrE016XWGT; Wed, 13 Jul 2016 08:31:33 +0200 Received: from 2001:983:a264:1:64eb:91b1:57ea:8151 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 08:31:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 08:31:30 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57851437.2070405@tzi.org> References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> <57851437.2070405@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (S7HLKXapYaweLYGemecCooQVZgxX+yGF) User-Agent: XS4ALL Webmail Archived-At: Cc: Alexander Pelov , Core Subject: Re: [core] YANG to CBOR , identification of objects X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 06:31:38 -0000 > Actually I'm intrigued as to what that approach will be; until we know > that, I'd be a bit weary about moving things around. > Thanks for your interest. However, the success of my proposal should not be of influence on the use of delta notation. For the moment every YANG integer identifier MUST be encoded with delta notation. That is too restrictive in my opinion. Secondly, using the delta notation can be interesting outside the YANG context. Peter From nobody Tue Jul 12 23:34:24 2016 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 4CE9612B071 for ; Tue, 12 Jul 2016 23:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 K5kfBEIxy-_y for ; Tue, 12 Jul 2016 23:34:21 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F35712B031 for ; Tue, 12 Jul 2016 23:34:21 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud6.xs4all.net with ESMTP id J6aK1t00K4fjQrE016aKgd; Wed, 13 Jul 2016 08:34:19 +0200 Received: from 2001:983:a264:1:64eb:91b1:57ea:8151 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 08:34:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 08:34:19 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (2o4EKVkKqtwZ3O+PjWIv4MELJ7yvPfNR) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 06:34:23 -0000 Hi Michel, When a specification changes it set of of keys, I don't think the SIDs will change. It is for sure that the hashes are not affected by the attribution of a key. Therefore, what happens when client and server use different keys in otherwise identical list specification? Peter Michel Veillette schreef op 2016-07-12 17:07: > Hi Peter > > The validations performed by the entity which de-serialize the CBOR > payload is based on the YANG schema. > This validation is based on all king of YANG statements such as: > key, unique, range, pattern, length, min-elements, max-elements, must, > when, if-feature > > The identification of which data nodes are keys is considered > unnecessary meta-data since available in the schema. > Even more heavy weight representations such as xml and json don't > include this meta-data in the encode payload. > > Regards, > Michel > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday, July 12, 2016 6:08 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 > > Hi Michel, > >> >> However, I am missing how to transport a given list instance with its >> key values in the CBOR encoding. Section 4.4 describes the encoding of >> a complete list not a subset of its instances. >> >> [MV] A list instance is a collection which is described in section >> 4.2. >> ______________________________________________________________________ >> _______________________ > > With the current text I don't see how you distinguish instances with > the same key from instances with different keys. > > Example: > > list server { > key name; > > leaf name { > type string; > } > leaf iburst { > type boolean; > default false; > } > > How to distinguish that in the list below that two instances are > identical (should not occur) > [ > { > 1755 : "NRC TIC server", # name (SID 1755) > 1754 : false, # iburst (SID 1754) > }, > { > 1755 : "NRC TIC server", # name (SID 1755) > 1754 : true, # iburst (SID 1754) > } > ] > > And the following two instances are different (valid array) > > [ > { > 1755 : "NRC TAC server", # name (SID 1755) > 1754 : true, # iburst (SID 1754) > }, > { > 1755 : "NRC TIC server", # name (SID 1755) > 1754 : true, # iburst (SID 1754) > } > ] From nobody Wed Jul 13 02:43:04 2016 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 D3E5412D6B5 for ; Wed, 13 Jul 2016 02:43:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 u-tAkEJoln9I for ; Wed, 13 Jul 2016 02:42:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7651E12D69F for ; Wed, 13 Jul 2016 02:42:56 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-cd-57860d1d76c2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.D7.12516.D1D06875; Wed, 13 Jul 2016 11:42:53 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 13 Jul 2016 11:42:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=galitvImVLqCTTVVCEzqIMqon2NKu+E0mYPStFfzlsk=; b=FkFZcH4AkiI6vFm69xk54fQOXuSoII4VlGu1SK75WknnfDbjDEUckzPd3fE6Gm43TUCdE5UaePOdUuOo4T2MAbWnS6d3oC6brHdjBRSR1+aRu5CVrn8dBSvXEpLQd7buoX6PxRqSz0+tqGnw5dj63PbqA1KpubfzK894JJDq2kY= Received: from AMXPR07MB070.eurprd07.prod.outlook.com (10.242.70.148) by AMXPR07MB072.eurprd07.prod.outlook.com (10.242.70.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 13 Jul 2016 09:42:48 +0000 Received: from AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) by AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.218]) with mapi id 15.01.0528.026; Wed, 13 Jul 2016 09:42:49 +0000 From: Francesca Palombini To: Carsten Bormann , peter van der Stok Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1l?= =?utf-8?Q?tch-01?= Thread-Index: AQHR0JnQdP6iR0Z21EyknS8RGJOeqZ//FnIAgAA+YICAFtsbIA== Date: Wed, 13 Jul 2016 09:42:48 +0000 Message-ID: References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <5772DCE3.6090104@tzi.org> In-Reply-To: <5772DCE3.6090104@tzi.org> 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=francesca.palombini@ericsson.com; x-originating-ip: [80.216.62.213] x-ms-office365-filtering-correlation-id: 4069a6ca-044c-4ce7-256b-08d3ab020d49 x-microsoft-exchange-diagnostics: 1; AMXPR07MB072; 6:+S9kzhXTnpHIDW0teaeWhljg5QNJX8xAvRHDN/vXWSyEAQ+2h7h/DVa1BTjbp+7afBKzDlYX506YLeSVBeo/xeecT/9Vi0Q5O0EltlnpXXkICHQsjIdYZ8wos06t4tqmfDhK/nJuKa7E/+CS44uYeT3sPDrQ8wbhjdd11j6ytBNpWbdq3rstl41B49hFMTfJKY4JrHbMa8w1KN2RD844fu4K+GC/fPeKMKoB0OTooanjvtNiaZaBF6mJiuxeBY1Q6hYhOtuMAu/yOOz1lLEZLUqcjebl4Qtyowd+UYksTFA=; 5:ja5qWns3C/IEmqZMuUptWK72qg1UWSPDI2YGnPiR40J7QVCfviX1Vj547UB6gPnfo4OLaIxcG85SsE8U9ViLPf41nCb3xa53P5jnNLj6PRxozNDKKM1aZvOktyFjwIj9R4KMheqFAd4DFfDy4KZ+cg==; 24:gt1F/emULm07xtNhuLCGWUXZDAar+EQLCIYjt2tPluCsMvytymWpo/5vtJq+79rXyDleNkChjcnys87rwXx6h3YWr981o181jilc4PxzpX0=; 7:KbbBGdoRPhwd2VuzUNCq8YDFGGOi+IoMkyHqeq3nyWRzLaHqpVBirLiyeELUHugy8yDA8JesUVFSssTpMLNudK6eqHb4lnQ3T0qkrZE3o729uplUDC71XwoP+1HBo6Lr7Mk6hyCHLyUJe2T5zpA6D5Qx02aoFh1rWHogrxDrAPbTdV3gx1cPuG7abmExATfWo6gTRmspziSe2QeGXAslHlXDSQMPqD2+MgmEVOgcysE+xX9rP+8N+5BA2uT0Jl+O x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB072; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMXPR07MB072; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB072; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(13464003)(87936001)(3660700001)(76176999)(54356999)(345774005)(50986999)(189998001)(74316002)(7736002)(586003)(4326007)(122556002)(101416001)(66066001)(81166006)(81156014)(105586002)(229383001)(3280700002)(106116001)(76576001)(2900100001)(15975445007)(7696003)(86362001)(68736007)(97736004)(5001770100001)(8936002)(2906002)(305945005)(19580395003)(5003600100003)(7846002)(10400500002)(5002640100001)(9686002)(2950100001)(33656002)(3846002)(6116002)(106356001)(102836003)(230783001)(19580405001)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB072; H:AMXPR07MB070.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 09:42:48.8543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB072 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42KZGbFdV1eWty3c4Mcia4sjU+6yWux7u57Z oqn/OKMDs8eSJT+ZPKYtyvQ49fUzewBzFJdNSmpOZllqkb5dAlfG6ka3gjkqFQc+/WNsYFyi 3MXIySEhYCKxbeZ/JghbTOLCvfVsXYxcHEICRxgllpw7BeWcYJRoOjGFGcRhEehllmi8sp4R InOFUeLxmmfsEM4xRokvi5ewgwxjE7CRuPDwPSuILSLgLfG4ZTsLiM0soCbxaOk5MFtYIEti +63PLBA12RIHp6xnh7CdJA5+PwnWyyKgKrH14QywGl6BKImdp3ZC3bSYUeLg0mtsIAlOAXWJ Fe/PgjUzAn3x/dQaJohl4hK3nsyH+k5AYsme88wQtqjEy8f/WCHqkyWu3O5jh4grSnxt3MsG YftKTNw5C+xnCYG3bBJP186HKnKVmDhrLyuEnSlxp/U6VNxaYuWrD6wQDWsZJX5fnsoCkZCR WP33ORNE4jKrxO7Nf8C6hQRSJZavbWWcwKg9C8m1sxg5gGxNifW79CHCihJTuh+yzwKHgKDE yZlPWBYwsqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnECEwmB7f81t3BuPq14yFGAQ5GJR5e BYPWcCHWxLLiytxDjBIczEoivF+528KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhP LEnNTk0tSC2CyTJxcEo1MIYLb7RTjxdcZOMlM2fnmZnbMzbKN1zff0zk/sOTa5sLLsRv+NbQ I5Bn0M3xy+RxIO81tsNLb1WGyG6ak+m4xN1yr+zBdwr23nm+lsqfQ9TKWIuznJT2nu28miy4 6Xn5kfWTlumv2VEqJSm117123cW3jSnNfFd+7Qw6myElobJKmG9W7GrZOUosxRmJhlrMRcWJ ACiUoVkiAwAA Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 09:43:03 -0000 SGkgQXV0aG9ycywNCg0KSSBhcG9sb2dpemUgZm9yIHRoZSBsYXRlIGNvbW1lbnQuDQoNCkkgdGhp bmsgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYW5kIEkgdGhpbmsgdGhlIHNl bnRlbmNlIGluIHNlY3Rpb24gMy4gOiAiIFRoZSBpbmRpY2F0aW9uIG9mIGlkZW1wb3RlbmNlIG1h eSBlbmFibGUgdGhlIHNlcnZlciB0byBrZWVwIGxlc3Mgc3RhdGUgYWJvdXQgdGhlIGludGVyYWN0 aW9uOyBzb21lIGNvbnN0cmFpbmVkIHNlcnZlcnMgbWF5IG9ubHkgaW1wbGVtZW50IHRoZSBpUEFU Q0ggdmFyaWFudCBmb3IgdGhpcyByZWFzb24uIiBtb3RpdmF0ZXMgdGhlIGV4aXN0ZW5jZSBvZiBi b3RoIG1ldGhvZHMuDQoNCkkgbWF5IGhhdmUgbWlzc2VkIGl0IGluIHRoZSBkcmFmdCwgYnV0IEkg Y291bGRuJ3Qgc2VlIHdoZXJlIGluIHRoZSBkcmFmdCBpcyBkZWZpbmVkIHRoYXQgZXJyb3IgNC4x MiBQcmVjb25kaXRpb24gRmFpbGVkIGlzIHJldHVybmVkIHdoZW4gaVBBVENIIGlzIHVzZWQgd2l0 aCBhIG5vbi1pZGVtcG90ZW50IG1vZGlmaWNhdGlvbiAoYXMgaXQgaXMgc3BlY2lmaWVkIGluIHRo ZSBlcnJvcikuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgc3BlY2lmaWVkIGluIHNlY3Rpb24gMy40 Lg0KDQpCZXN0LA0KRnJhbmNlc2NhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3Rl biBCb3JtYW5uDQpTZW50OiBkZW4gMjgganVuaSAyMDE2IDIyOjI0DQpUbzogS2xhdXMgSGFydGtl IDxoYXJ0a2VAdHppLm9yZz4NCkNjOiBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdHIExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUt ZXRjaC0wMQ0KDQo+IEknbSBub3QgY29udmluY2VkIHRoYXQgdHdvIFBBVENIIG1ldGhvZHMgYXJl IG5lZWRlZCwgYmVjYXVzZSB0aGUgDQo+IGlkZW1wb3RlbmN5IG9mIHRoZSByZXF1ZXN0IHJlYWxs eSBkZXBlbmRzIG9uIHRoZSBpZGVtcG90ZW5jeSBvZiB0aGUgDQo+IHBhdGNoIGFuZCBub3Qgb24g dGhlIG1ldGhvZDogaWYgdGhlIHJlcGVhdGVkIGFwcGxpY2F0aW9uIG9mIHRoZSBwYXRjaCANCj4g bGVhZHMgdG8gdGhlIHNhbWUgcmVzdWx0LCB0aGVuIHRoZSByZXF1ZXN0IGlzIGlkZW1wb3RlbnQ7 IG90aGVyd2lzZSwgDQo+IGl0J3Mgbm90LiBJIGRvbid0IHNlZSB0aGUgYmVuZWZpdCBvZiByZXBl YXRpbmcgdGhpcyBiaXQgb2YgaW5mb3JtYXRpb24gDQo+IGluIHRoZSByZXF1ZXN0IG1ldGhvZC4N Cg0KVGhlIHJlcXVlc3QgbWV0aG9kIGlzIGFuIGluZGljYXRpb24gb2YgdGhlIGludGVudCBvZiB0 aGUgY2xpZW50Lg0KVGhlIHNlcnZlciBjYW4gbWFrZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGVu Y29kZWQgaW4gdGhpcyBpbnRlbnQuDQoNCklmIHlvdSBvbmx5IGV2ZXIgaW1wbGVtZW50IGxlc3Mt Y29uc3RyYWluZWQgKGFuZCBub3Qtc28taGlnaC1zcGVlZCkgc2VydmVycyBhbmQgcHJveGllcywg dGhhdCBpbmZvcm1hdGlvbiBtYXkgbm90IGJlIHZlcnkgdXNlZnVsLiAgQm90aCBmb3IgY29uc3Ry YWluZWQgYW5kIGhpZ2gtc3BlZWQgaW1wbGVtZW50YXRpb25zLCBpdCBpcyBhbiBhZHZhbnRhZ2Ug dG8ga25vdyB3aGVuIGEgcmVxdWVzdCBpcyBpbnRlbmRlZCB0byBiZSBpZGVtcG90ZW50Lg0KDQo+ IFR3byBtZXRob2RzIGFyZSBhIHByb2JsZW0gd2hlbiBtYXBwaW5nIEhUVFAgUEFUQ0ggdG8gQ29B UA0KPiBQQVRDSC9pUEFUQ0g6IA0KDQpJdCBpcyBub3QgcmVhbGx5IGEgcHJvYmxlbTogQSBIVFRQ LXRvLUNvQVAgY3Jvc3MtcHJveHkgZG9lc24ndCBrbm93IHRoZSBpbnRlbnQsIHNvIGl0IHdpbGwg aGF2ZSB0byB1c2UgUEFUQ0ggKHVubGVzcyB0aGVyZSBpcyBzb21lIG90aGVyIHdheSB0byBkZXJp dmUgdGhhdCBpbnRlbnQpLg0KDQo+IFRoZSBwcm94eSB3b3VsZCBuZWVkIHRvIGFuYWx5emUgdGhl IHBhdGNoIGluIHRoZSBIVFRQIHJlcXVlc3QgdG8gDQo+IGRldGVybWluZSBpZiB0aGUgSFRUUCBQ QVRDSCBjYW4gYmUgbWFwcGVkIHRvIENvQVAgaVBBVENIIG9mIGlmIENvQVAgDQo+IFBBVENIIGhh cyB0byBiZSB1c2VkLiBUaGUgcHJveHkgY2Fubm90IGp1c3QgbWFwIHRvIENvQVAgUEFUQ0ggYWx3 YXlzLCANCj4gYmVjYXVzZSB0aGUgQ29BUCBzZXJ2ZXIgbWlnaHQgb25seSBzdXBwb3J0IGlQQVRD SCBidXQgbm90IFBBVENIIGV2ZW4gDQo+IGlmIHRoZSBwYXRjaCBpdHNlbGYgaXMgYWN0dWFsbHkg aWRlbXBvdGVudC4NCg0KVGhlIHNlcnZlciBtaWdodCBub3QgZXZlbiBzdXBwb3J0IGlQQVRDSCwg ZWl0aGVyLiAgSSBkb24ndCB0aGluayBvbmUgc2hvdWxkIGV4cGVjdCBhIHByb3h5IHRvIGRvIG1l dGhvZCB0cmFuc2xhdGlvbi4gIChXZWxsLCBpdCBtYXkgYmUgYSBuaWNlIGRpZmZlcmVudGlhdGlu ZyBmZWF0dXJlLCB3aGljaCBpcyBlYXN5IHRvIGltcGxlbWVudCBpZiB0aGUgcHJveHkgaGFwcGVu cyB0byBrbm93IHRoYXQgdGhlIG1lZGlhIHR5cGUgdXNlZCBpbiB0aGUgUEFUQ0ggcmVxdWVzdCBv bmx5IHN1cHBvcnRzIGlkZW1wb3RlbnQgb3BlcmF0aW9ucywgZS5nLiBmb3IgUkZDIDczOTYgbWVy Z2UtcGF0Y2guKQ0KDQpBbiBvYnZpb3VzIHdheSB0byAic29sdmUiIHRoaXMgcHJvYmxlbSB3b3Vs ZCBiZSB0byByZXF1aXJlIGEgc2VydmVyIHRoYXQgc3VwcG9ydHMgaVBBVENIIHRvIGFsd2F5cyBz dXBwb3J0IFBBVENIIGFzIHdlbGwuDQoNCkkgdGhpbmsgbXVjaCBvZiB0aGUgY29nbml0aXZlIGRp c3NvbmFuY2UgaGVyZSBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQgdGhlIGJlc3QgcGxhY2UgdG8g Y2FycnkgdGhpcyBiaXQgb2YgaW5mb3JtYXRpb24gaXMgdGhlIG1ldGhvZCBjb2RlLCBhbmQgUkVT VCB0cmFkaXRpb25hbGx5IGhhcyBiZWVuIHVzaW5nIG9ubHkgZm91ciBtZXRob2RzLCBzbyBhZGRp bmcgdGhyZWUgY29kZXMgaW4gb25lIGV4dGVuc2lvbiBtYXkgc2VlbSBhIGxvdC4gIChIVFRQIGFj dHVhbGx5IGhhcyBtZXRob2RzIGxpa2UgSEVBRCwgd2hpY2ggaXMganVzdCBhbiBvcHRpbWl6ZWQg dmFyaWFudCBvZiBHRVQsIHNvIHRoaXMgaXNuJ3QgZXZlbiBuZXcNCnRlcnJpdG9yeS4pDQoNCj4g QXBhcnQgZnJvbSB0aGlzLCBJIHRoaW5rIHRoZSBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRp b24uDQoNClRoYW5rIHlvdSBmb3IgcmV2aWV3aW5nIHRoaXMgZHJhZnQuDQoNCkdyw7zDn2UsIENh cnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Wed Jul 13 03:39:21 2016 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 EA4A212DC88 for ; Wed, 13 Jul 2016 03:39:18 -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 1g9O0iyXQHLx for ; Wed, 13 Jul 2016 03:39:16 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3EC12DC92 for ; Wed, 13 Jul 2016 03:39:11 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud2.xs4all.net with ESMTP id JAf91t00G4K0fSy01Af9tB; Wed, 13 Jul 2016 12:39:09 +0200 Received: from 2001:983:a264:1:5123:947c:8d20:1a86 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 12:39:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 12:39:09 +0200 From: peter van der Stok To: Francesca Palombini Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <5772DCE3.6090104@tzi.org> Message-ID: <954cebf5f2084e23ec4b790d831a88cd@xs4all.nl> X-Sender: stokcons@xs4all.nl (du/isRISE7mAzFECzLwINilYIPy6nnkt) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 10:39:19 -0000 Hi Francesca, Thanks for your late by welcome comment. > > I may have missed it in the draft, but I couldn't see where in the > draft is defined that error 4.12 Precondition Failed is returned when > iPATCH is used with a non-idempotent modification (as it is specified > in the error). I think this should be specified in section 3.4. > You suggest that under the Failed precondition header of section 3.4 the draft mentions that iPATCH should return 4.12 also when the modification in non-idempotent. I think that an excellent suggestion and will add it to the if-* option usage. Peter From nobody Wed Jul 13 04:28:55 2016 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 14F8212DE60 for ; Wed, 13 Jul 2016 04:28:54 -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 md5WZ49a91iq for ; Wed, 13 Jul 2016 04:28:50 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0D012DE2E for ; Wed, 13 Jul 2016 04:28:50 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-4a-578625f08526 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4F.9D.27088.0F526875; Wed, 13 Jul 2016 13:28:48 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.140]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 13:27:58 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "draft-ietf-core-etch@tools.ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1l?= =?utf-8?Q?tch-01?= Thread-Index: AQHR0JnQdP6iR0Z21EyknS8RGJOeqaAWMHsA Date: Wed, 13 Jul 2016 11:27:58 +0000 Message-ID: <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> In-Reply-To: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <3C3AAE2D9CF5B64DBBA34E2415B55049@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7k+4H1bZwg5mndS32vV3PbLF2ibcD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlbFs7WTWghW8FSeXlTQw/uHpYuTkkBAwkVh6 vp0VwhaTuHBvPVsXIxeHkMARRonlj5ZAOUsYJR7/PM8CUsUmYCvxpHUfWIeIQKDEpcUnwWxm AQmJsysPg9nCAlkSl3Z8Y4GoyZY4OGU9O4RtJDFr9Rcgm4ODRUBVYuu+LBCTV8BeYtpODhBT CMhc164CUswp4CCx68k5ZhCbEei076fWMEEsEpe49WQ+E8TJAhJL9pxnhrBFJV4+/gf1ipJE 45InrCAjmQU0Jdbv0odotZZofzqLGcJWlJjS/RDsLl4BQYmTM5+wTGAUn4VkwyyE7llIumch 6Z6FpHsBI+sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMAYO7jlt8EOxpfPHQ8xCnAwKvHw Khi0hguxJpYVV+YeYpTgYFYS4S1SaQsX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9 sSQ1OzW1ILUIJsvEwSnVwMj9UYr5yd43c81vzTx4v/jv6Trnz+839gjsrdLbd+ag/SLbFVbN c3g/HxFra+HueVP1N+ltR0mv2OtHs+bLVSioqe5MUvPbMkWW9fmMxkOel89azc87H8R8q1hf RMrpsVL9hMrcBoafn6YY8Nzyrly0V1S7MlJdKjs0W/fDF4OD8XUXZ4dvXKjEUpyRaKjFXFSc CACw/lyZrQIAAA== Archived-At: Cc: core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 11:28:54 -0000 SGksDQoNCkkgcmVhZCB0aGUgZHJhZnQgYW5kIGhhdmUgY291cGxlIG9mIHF1ZXN0aW9ucy9jb21t ZW50cy4NCg0KV2hhdCBtZWRpYSB0eXBlIGNvdWxkIGJlIHRvZGF5IHVzZWQgd2l0aCBGRVRDSD8g V2hhdCBkbyB0aGUgaW1wbGVtZW50YXRpb25zIHVzZT8gSSdtIHRoaW5raW5nIHRoYXQgc29tZXRo aW5nIGxpa2UgeHBhdGggKC9qc29ucGF0aD8pIG1lZGlhIHR5cGUgd291bGQgYmUgZWFzeSB0byBk ZWZpbmUuDQoNClNlY3Rpb24gMjoNCj4gVGhlIHBheWxvYWQgcmV0dXJuZWQgaW4gcmVzcG9uc2Ug dG8gYSBGRVRDSCBjYW5ub3QgYmUgYXNzdW1lZCB0byBiZSBhIGNvbXBsZXRlIHJlcHJlc2VudGF0 aW9uIG9mIHRoZSByZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZSBlZmZlY3RpdmUgcmVxdWVzdCBV UkkuDQoNCkNhbid0IEkgdXNlIEZFVENIIHRvIHByb2R1Y2Ugc2FtZSByZXN1bHQgYXMgR0VUPyBF dmVuIGlmIEkgdXNlIGl0IHdpdGhvdXQgYW55IGFkZGl0aW9uYWwgcmVxdWVzdCBwYXJhbWV0ZXJz Pw0KDQo+ICAoTm90ZSB0aGF0IHRoaXMgYXNwZWN0IGRpZmZlcnMgbWFya2VkbHkgZnJvbSBbSS1E LnNuZWxsLXNlYXJjaC1tZXRob2RdLikNCg0KSSdtIG5vdCBzdXJlIHRoZXNlIHJlZmVyZW5jZXMg dG8gdGhlIEhUVFAgc2VhcmNoIG1ldGhvZCBkcmFmdCBhcmUgb2YgYW55IHVzZSwgcmF0aGVyIHRo ZXkgYXJlIGEgZGlzdHJhY3Rpb24uIFNpbmNlIHRoYXQgZHJhZnQgaXMgZXhwaXJlZCBhbmQgYXBw YXJlbnRseSBub3QgZ29pbmcgYW55d2hlcmUsIEknZCBzdWdnZXN0IHNpbXBseSByZW1vdmluZyBh bGwgdGhlIHJlZmVyZW5jZXMuIElmIHlvdSB3YW50IHRvIGFja25vd2xlZGdlIHRoYXQgd29yaywg dGhlIEFDSyBzZWN0aW9uIGlzIGJldHRlciBmb3IgdGhhdC4NCg0KPiAyLjUuIEZFVENIIGRpc2N1 c3Npb24NCg0KVGhpcyBjb3VsZCBiZSBjYWxsZWQgZS5nLiwgIkdlbmVyYXRpbmcgRkVUQ0ggcmVx dWVzdHMiIHNpbmNlIHRoYXQncyBhbGwgdGhpcyBpcyBhcHBhcmVudGx5IGFib3V0DQoNClNlY3Rp b24gMi42Og0KPiAod2l0aCBhIENvbnRlbnQtRm9ybWF0IElEIG9mIE5OTiDigJMgbm90IGRlZmlu ZWQgYXMgdGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUpLA0KDQpUaGlzIGlzIG5vdCBzcGVjaWZpYyB0 byB0aGlzIGRyYWZ0LCBidXQgbWF5YmUgd2Ugc2hvdWxkIGFsbG9jYXRlIG9uZSBjb250ZW50IGZv cm1hdCBJRCBmb3IgZXhhbXBsZSBwdXJwb3Nlcy4NCg0KDQpDaGVlcnMsDQpBcmk= From nobody Wed Jul 13 05:20:41 2016 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 AAAEC12DF0C for ; Wed, 13 Jul 2016 05:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 cvFYgni3VXpZ for ; Wed, 13 Jul 2016 05:20:37 -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 9D0B812DD0C for ; Wed, 13 Jul 2016 05:20:35 -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 u6DCKU1v024894; Wed, 13 Jul 2016 14:20:30 +0200 (CEST) Received: from roku (ip-109-47-1-20.web.vodafone.de [109.47.1.20]) (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 3rqHwY6zfCzDgNh; Wed, 13 Jul 2016 14:20:29 +0200 (CEST) Date: Wed, 13 Jul 2016 14:20:28 +0200 From: Carsten Bormann To: =?utf-8?Q?Ari_Ker=C3=A4nen?= Message-ID: In-Reply-To: <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5786320c_6b8b4567_43f8" Archived-At: Cc: "\"=?utf-8?Q?draft-ietf-core-etch=40tools.ietf.org?=\"" , core Subject: Re: [core] =?utf-8?Q?=F0=9F=94=94_?=WG Last Call of draft-ietf-core-etch-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 12:20:39 -0000 --5786320c_6b8b4567_43f8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Ari, Unfortunately, before SEARCH/=46ETCH there was little incentive to regist= er a media type for a search structure. Eg, see rfc6901 (which would othe= rwise work quite well, except for just being a single pointer). Of course= we could invent one just to use in the example, but I'd rather have thes= e registrations be driven by actual application requirements. Inventing a= useful one on the spot sounds like a recipe for delay. I think COMI/COOL= will be the first real customer. =20 Gr=C3=BC=C3=9Fe, Carsten =20 --5786320c_6b8b4567_43f8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Ari,

Unfortunately, before SEARCH/=46ETCH there was = little incentive to register a media type for a search structure. Eg, see= rfc6901 (which would otherwise work quite well, except for just being a = single pointer). Of course we could invent one just to use in the example= , but I'd rather have these registrations be driven by actual application= requirements. Inventing a useful one on the spot sounds like a recipe fo= r delay. I think COMI/COOL will be the first real customer.

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

On 13 Jul 2016 13:27, Ari Ker=C3=A4nen wrote:

=09

Hi,&=2313;
&=2313;
I read the draft and have couple = of questions/comments.&=2313;
&=2313;
What media type could be to= day used with =46ETCH=3F What do the implementations use=3F I'm thinking = that something like xpath (/jsonpath=3F) media type would be easy to defi= ne.&=2313;
&=2313;
Section 2:&=2313;

The payload returned in response to a =46ETCH cannot be assumed t= o be a complete representation of the resource identified by the effectiv= e request URI.&=2313;
&=2313;
Can't I use =46ETCH to= produce same result as GET=3F Even if I use it without any additional re= quest parameters=3F&=2313;
&=2313;
= (Note that this aspect differs markedly from =5BI-D.snell-search-method=5D= .)&=2313;
&=2313;
I'm not sure these references to t= he HTTP search method draft are of any use, rather they are a distraction= . Since that draft is expired and apparently not going anywhere, I'd sugg= est simply removing all the references. If you want to acknowledge that w= ork, the ACK section is better for that.&=2313;
&=2313;
2.5. =46ETCH discussion&=2313;
&=23= 13;
This could be called e.g., =22Generating =46ETCH requests=22 sinc= e that's all this is apparently about&=2313;
&=2313;
Section 2.6:= &=2313;
(with a Content-=46ormat ID of = NNN =E2=80=93 not defined as this is just an example),&=2313;
&=2313;
This is not specific to this draft, but maybe we should= allocate one content format ID for example purposes.&=2313;
&=2313;<= br/>&=2313;
Cheers,&=2313;
Ari&=2313;
&=2313;
&=2313;
--5786320c_6b8b4567_43f8-- From nobody Wed Jul 13 05:23:07 2016 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 75D1112DF37 for ; Wed, 13 Jul 2016 05:23: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, HTML_MESSAGE=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 xlpXGl6rs7G3 for ; Wed, 13 Jul 2016 05:23: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 0C45F12DF34 for ; Wed, 13 Jul 2016 05:23: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 u6DCN0K0029946; Wed, 13 Jul 2016 14:23:00 +0200 (CEST) Received: from roku (ip-109-47-1-20.web.vodafone.de [109.47.1.20]) (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 3rqHzS42MkzDgNm; Wed, 13 Jul 2016 14:23:00 +0200 (CEST) Date: Wed, 13 Jul 2016 14:22:59 +0200 From: Carsten Bormann To: =?utf-8?Q?Ari_Ker=C3=A4nen?= Message-ID: <54914fe2-f854-4172-8ff4-9e38c8f0bd65@roku> In-Reply-To: <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="578632a3_327b23c6_43f8" Archived-At: Cc: "\"=?utf-8?Q?draft-ietf-core-etch=40tools.ietf.org?=\"" , core Subject: Re: [core] =?utf-8?Q?=F0=9F=94=94_?=WG Last Call of draft-ietf-core-etch-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 12:23:06 -0000 --578632a3_327b23c6_43f8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Ari, On the editorial items: these are all good suggestions. To bad there is n= o section =22historical references=22 for the pointer to the SEARCH draft= ... Gr=C3=BC=C3=9Fe, Carsten --578632a3_327b23c6_43f8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Ari,

On the editorial items: these are all good sugg= estions. To bad there is no section =22historical references=22 for the p= ointer to the SEARCH draft...

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

On 13 Jul 2016 13:27, Ari Ker=C3=A4nen wrote:

=09

Hi,&=2313;
&=2313;
I read the draft and have couple = of questions/comments.&=2313;
&=2313;
What media type could be to= day used with =46ETCH=3F What do the implementations use=3F I'm thinking = that something like xpath (/jsonpath=3F) media type would be easy to defi= ne.&=2313;
&=2313;
Section 2:&=2313;

The payload returned in response to a =46ETCH cannot be assumed t= o be a complete representation of the resource identified by the effectiv= e request URI.&=2313;
&=2313;
Can't I use =46ETCH to= produce same result as GET=3F Even if I use it without any additional re= quest parameters=3F&=2313;
&=2313;
= (Note that this aspect differs markedly from =5BI-D.snell-search-method=5D= .)&=2313;
&=2313;
I'm not sure these references to t= he HTTP search method draft are of any use, rather they are a distraction= . Since that draft is expired and apparently not going anywhere, I'd sugg= est simply removing all the references. If you want to acknowledge that w= ork, the ACK section is better for that.&=2313;
&=2313;
2.5. =46ETCH discussion&=2313;
&=23= 13;
This could be called e.g., =22Generating =46ETCH requests=22 sinc= e that's all this is apparently about&=2313;
&=2313;
Section 2.6:= &=2313;
(with a Content-=46ormat ID of = NNN =E2=80=93 not defined as this is just an example),&=2313;
&=2313;
This is not specific to this draft, but maybe we should= allocate one content format ID for example purposes.&=2313;
&=2313;<= br/>&=2313;
Cheers,&=2313;
Ari&=2313;
&=2313;
&=2313;
--578632a3_327b23c6_43f8-- From nobody Wed Jul 13 05:28:20 2016 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 A73D612DF4B for ; Wed, 13 Jul 2016 05:28:18 -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 JjtxHU2TXWaN for ; Wed, 13 Jul 2016 05:28:17 -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 1C74412DF4F for ; Wed, 13 Jul 2016 05:28:16 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud2.xs4all.net with ESMTP id JCUD1t0084d84Ai01CUDPy; Wed, 13 Jul 2016 14:28:15 +0200 Received: from 2001:983:a264:1:5123:947c:8d20:1a86 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 14:28:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 13 Jul 2016 14:28:13 +0200 From: peter van der Stok To: =?UTF-8?Q?Ari_Ker=C3=A4nen?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> Message-ID: X-Sender: stokcons@xs4all.nl (sxGW4nJ5qfTBFs3eyg5hKX+IYtqyky73) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-etch@tools.ietf.org, core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 12:28:19 -0000 Hi Ari, thanks for the comments. See below for my reaction. Carsten may have different opinions though. Ari Keränen schreef op 2016-07-13 13:27: > Hi, > > I read the draft and have couple of questions/comments. > > What media type could be today used with FETCH? What do the > implementations use? I'm thinking that something like xpath > (/jsonpath?) media type would be easy to define. An array of JSON identifiers looks reasonable. Is it your suggestion to define that in this draft? > > Section 2: >> The payload returned in response to a FETCH cannot be assumed to be a >> complete representation of the resource identified by the effective >> request URI. > > Can't I use FETCH to produce same result as GET? Even if I use it > without any additional request parameters? Depends on media type, but by using an array of one JSON identifier, I would say yes. > >> (Note that this aspect differs markedly from >> [I-D.snell-search-method].) > > I'm not sure these references to the HTTP search method draft are of > any use, rather they are a distraction. Since that draft is expired > and apparently not going anywhere, I'd suggest simply removing all the > references. If you want to acknowledge that work, the ACK section is > better for that. For me OK. > >> 2.5. FETCH discussion > > This could be called e.g., "Generating FETCH requests" since that's > all this is apparently about > > Section 2.6: >> (with a Content-Format ID of NNN – not defined as this is just an >> example), > > This is not specific to this draft, but maybe we should allocate one > content format ID for example purposes. YEP, could be useful it seems. > > > Cheers, > Ari Cheerio, Peter From nobody Wed Jul 13 05:41:47 2016 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 2BD6C12D7BB for ; Wed, 13 Jul 2016 05:41:46 -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 dsu2WMgf-0uP for ; Wed, 13 Jul 2016 05:41:45 -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 D24A812D0F8 for ; Wed, 13 Jul 2016 05:41:44 -0700 (PDT) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 63B10A80F0; Wed, 13 Jul 2016 14:41:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id aukXAaq6F8Su; Wed, 13 Jul 2016 14:41:41 +0200 (CEST) X-Originating-IP: 109.47.1.20 Received: from nar-3.local (ip-109-47-1-20.web.vodafone.de [109.47.1.20]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8985BA810A; Wed, 13 Jul 2016 14:41:03 +0200 (CEST) Message-ID: <578636BC.2010208@tzi.org> Date: Wed, 13 Jul 2016 14:40:28 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> In-Reply-To: <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-core-etch@tools.ietf.org" , core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 12:41:46 -0000 Ari Keränen wrote: > Section 2: >> > The payload returned in response to a FETCH cannot be assumed to be a complete representation of the resource identified by the effective request URI. > > Can't I use FETCH to produce same result as GET? Even if I use it without any additional request parameters? Depending on the request body media type, you may be able to (it may not always be obvious that you just did -- the server may have some leeway in some cases). This sentence is an admonition not to cache a FETCH result as if it were a GET result. (Should we say this more explicitly?) Grüße, Carsten From nobody Wed Jul 13 06:21:30 2016 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 5754C12D756 for ; Wed, 13 Jul 2016 06:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CyE3mEyslCO for ; Wed, 13 Jul 2016 06:21:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EE5F012D11A for ; Wed, 13 Jul 2016 06:21:22 -0700 (PDT) Received: from localhost ([::1]:37728 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bNK6L-0003t6-TM; Wed, 13 Jul 2016 06:21:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, lauri.piikivi@arm.com X-Trac-Project: core Date: Wed, 13 Jul 2016 13:21:21 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/414 Message-ID: <061.1d5cb7c19048f47f4cabf407679e6ab5@trac.tools.ietf.org> X-Trac-Ticket-ID: 414 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, lauri.piikivi@arm.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160713132122.EE5F012D11A@ietfa.amsl.com> Resent-Date: Wed, 13 Jul 2016 06:21:22 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #414 (resource-directory): RESTful operation and link parameter changes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 13:21:28 -0000 #414: RESTful operation and link parameter changes Hi, Some thought son the device registry. Started with making it more RESTful api, and expanded on the way to expressing more information as link parameters, and utilizing existing link parameters. 1. change the URL shceme to be more RESTful, resources in URL path, not in query parameters 2. Proposal that lifetime, lt, is a new link-format parameter 3. endpoint as URI in link-format payload for registration, in URL path segment for lookup (no ep parameter as in draft, ep was used as query parameter and link parameter) 4. Collection (aka "domain") and group expressed as link parameters (no d, gp parameters as in draft) I also would like to see the "domain" parameter changed to more neutral collection. It forces clarity to the usage of domain in DNS vs as collection of endpoints in RD. The domain usage seemed confusing to me. It may or may not be a DNS domain in the end. Sincerely, - Lauri Piikivi # Link parameters ## Endpoint as the first target URI The first link in link-format is the endpoint name. ;lt=600 It can have domain Justification: endpoint is the base-link to the related resources in the endpoint. Expressing it as link is logical. Note, it an endpoint does not have static DNS entry or name, the RD can return in registration response a link, with explicit relation "host", that is the registered link to the endpoint. For example endpoint can learn the RD seen IP address in NAT environment, or RD can indicate back the DNS name for the endpoint. > Discussion > Endpoint can have multiple schemes, coap over UDP, coap > over DTLS, coap over TCP. Are these 1 registration (1 > location) or do they need to be registered separately? > draft has ep as link parameter, ch 7.1 page 25 ## New link parameter: lifetime lt := Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. If resource link for an endpoint does not define own lt, the endpoint lt MUST be assumed. Justification: the lifetime is a parameter of the endpoint link, and for the resource links at the endpoint. > Discussion > Gives the possibility that resources may have different > lifetime than the endpoint host. Those can be updated in > RD ## Domain and group as Collection link parameter Collection and item link parameters are defined in RFC6573. Since the RD grouping of endpoints does not necessarily imply DNS domain usage, the logical grouping of endpoints into collections and groups is clearer. The relation can be also expressed in link parameters. Endpoint information, when retrieved from RD, can give the collection and group links for and endpoint. The links are URIs to the RD, with the relation parameter "collection" See https://tools.ietf.org/html/rfc6573#section-2.2 Domain, as used in draft, is "collection". Group is a expressed as "collection item" Groups are links, and can express the Name, Scheme, IP, Port. In registration the RD may return link-format document, and endpoint can learn additional information of the groups and collection it belongs to from that link-format. Most often the collection information is only used in the URL PATH to the endpoint. However, being able to read the registration data with collection information may help use cases for persistent storage of information and when reverse lookup from endpoint (or resoure) to the collections it belongs to are needed # Resource Directory Operations ## Device Registration Method: POST URI Template: /rd/ep/EP_INSTANCE ## Registration path components rd/ep := RD Function Set path for endpoints (mandatory). This is the path of the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. The mandatory segment "ep" is used to indicate endpoint related registration, update or query operations in the information hierarchy. EP_INSTANCE := The endpoint name (mandatory). The maximum length of this parameter is 63 bytes. After registration the endpoint name is an identifier that MUST be unique within a domain. RD service may return unique domain path and endpoint name in HTTP locator field, which MUST be used as the identifier from there on by the endpoint. An endpoint may get new locator in registration (for example if an endpoint resets and performs registration anew, while the old regstration is still valid for lifetime) ## Registration payload All other data, including context (link) are given in payload. ## Examples The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. Context, scheme, authority and port is given as a link with the new lifetime parameter. Req: POST coap://rd.example.com/rd/ep/node1 Content-Format: 40 Payload: ;lt=600 ;ct=41;rt="temperature-c";if="sensor", ;ct=41;rt="light-lux";if="sensor" Res: 2.01 Created Location: /rd/ep/node1 Device name is not unique, and the created resource for the device is named by the RD and device is found from path /ep/node1_1. Device does not have a domain name, so the RD acting as proxy inserts own context information to the registration Req: POST /rd/ep/node1 HTTP/1.1 Host : example.com Content-Type: application/link-format Payload: ;lt=600 ;ct=41;rt="temperature-c";if="sensor", ;ct=41;rt="light-lux";if="sensor" Res: 201 Created Location: /rd/ep/node1_1 Further references to the device MUST use the location /ep/node1_1 ## Registration Update URI Template: /{+location} URI Template Variables: location := This is the Location path returned by the RD as a result of a successful earlier registration. P lt := Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. lt is kept as variable as it is not a hierarchical part of resource name Req: PATCH /rd/ep/node1_1 Res: 2.04 Changed With explicit lt parameter Req: PATCH /rd/ep/node1_1?lt=600 Res: 2.04 Changed ## Registration Change The following example shows an endpoint updating its registration with a new context, changing an existing link, and adding a new link using this interface. Lifetime is updated as another call. With the initial registration the client set the following values: o lifetime (lt)=500 o context base-link=coap://local-proxy-old.example.com:5683 o resource= ;ct=41;rt="foobar";if="sensor" Req: PATCH /rd/ep/node1 Content-Format: 40 Payload: ;lt=1200 ;ct=41;rt="temperature-f";if="core.s core.p custom- sensor", ;ct=41;rt="door";if="core.s custom-sensor" Res: 2.04 Changed # Resource Lookup ## General on the URL format URI Template may have domain. High level hierarchy is **rd-lookup-base/collection/group/endpoint/resource/interface** In shorter format, which SHOULD be supported the hierarchy is expressed as **rdlu/c/gp/ep/res/inf** With the formalization work for interfaces, they are raised to explicit parts of the information hierarchy. ## lookups to logical collections These lookups return links to RD logical collections. A client must further query the RD for a list of endpoints in the logical collection These queries return a list of logical collections in the RD (links to RD with parameter rel="collection") ### lookup endpoint types, resource types and interface types Req /rdlu/rt/ Returns a list of link-formats, to different resource types known by the RD Resp Req /rdlu/et/ Resp Req /rdlu/if/ Resp Further call to e.g. /rdlu/rt/door/ or /rdlu/if/core.s/ would return a list of endpoint links that have registered that resource type ###lookup all collections (formerly "domains") /rdlu/c/ Returns EITHER a list of groups in the collection (links to RD with parameter rel="collection item") OR links to endpoints >Discussion > it is not possible to have a collection with direct > children of groups and endpoints both ## lookup endpoints As the endpoint is the host of resources, queries to path segment ep and lower (/ep, /ep/INSTANCE/res, ep/INSTANCE/res/INSTANCE/if) return links to endpoints, which a client can directly use to communicate with a endpoint. Note, that in practise the endpoint link can be to a proxy or gateway. > Discussion > Should the GW or proxy be expressed explicitly with a > VIA link relation for an endpoint? Assuming it it often > known by the RD that the system has a GW or proxy ###lookup all endpoints in collection COL_A /rdlu/c/COL_A/ep/ It is expected that the common structure is more flat, and endpoints can be often listed directly, collection is optional. ###lookup all endpoints /rdlu/ep/ ###lookup all resources in endpoint EP_A /rdlu/ep/EP_A/res/ ###lookup all resource types in specific resource /rdlu/ep/EP_A/res/RES_3/if/ ###lookup all resources in endpoint types HOME_SENSOR ??? /rdlu/et/HOME_SENSOR/res /rdlu/c/COL_A/gp/ #lookup groups in collection /rdlu/c/rt/ # lookup resource types in collection ## URI Query part to lookups URI QUERY PART: ?page,count and count are query filters. They are used as query parameters, since they are not resource selection but modify the amount of data shown for a path identifier. # Examples ## Logical group lookups The following example shows a client performing a lookup for endpoints in sepcific endpoint type: Req: GET /rdlu/et Res: 2.05 Content ;et="power-node";rel="collection", ;et="actuator";rel="collection" The following example shows a client performing a collection (previously domain) lookup: Req: GET /rdlu/c Res: 2.05 Content ;rel="collection", ;rel="collection" The following example shows a client performing a group lookup for groups in collection: Req: GET /rdlu/c/collection1/gp Res: 2.05 Content ;rel="collection item", ;rel="collection item" ## Endpoint lookups The following examples show endpoint queries for certain interface and resource type Req: GET /rdlu/if/core.s Res: 2.05 Content ;rt="temperature" Req: GET /rdlu/rt/temperature Res: 2.05 Content ;rt="temperature" The following example shows a client performing a lookup for endpoints in sepcific endpoint type: Req: GET /rdlu/et/power-node Res: 2.05 Content , The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rdlu/gp/lights1/ Res: 2.05 Content , ## Endpoint information query The following example shows a client performing a lookup for all groups an endpoint belongs to. To do this, the specific endpoint information is queried and collection and group information is parsed from the link- format. It is expected that this kind of reverse lookups are rare. Req: GET /rdlu/ep/node1 Res: 2.05 Content Content-Format: 40 Payload: ;lt=1200 ;ct=41;rt="temperature-f";if="core.s core.p custom- sensor", ;ct=41;rt="door";if="core.s custom-sensor", ;rel="collection",;rel="collection item", ;rel="collection item" -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- lauri.piikivi@arm.com | directory@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: resource- | Keywords: directory | Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 13 07:36:16 2016 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 53C2B12D82E for ; Wed, 13 Jul 2016 07:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 cV4N7Glqgf1f for ; Wed, 13 Jul 2016 07:36:12 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.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 2A16B12D661 for ; Wed, 13 Jul 2016 07:36:12 -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=lQM4srZgZ4O5soNZkXPwvimK1rmT6k+2sy3C8N6wSJ8=; b=SceQzC5m5E886efePvUsq3dwDvABT8xRGuwmMXfqNbeIXyrVGQgEwFKjYuJf27JGBdPQ/x8Mqeaj/UrmujehEv4gOZG0c7JxedPfw1ZgbM3Fie3THEfNcJMUX1TkCO7uzT6x8JkGFiNnKGabIY7eBT1qF9WCgLav7OEDbCsET4E= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 14:36:09 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 14:36:09 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYCugCAAFEisIABBZSAgACEZ/A= Date: Wed, 13 Jul 2016 14:36:09 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> 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: [24.225.215.88] x-ms-office365-filtering-correlation-id: c6e10c93-3c4c-4f7b-94ba-08d3ab2b0823 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:kqg59X+u7ShoPs3WesmhfsCczA/dmsUYNcN7hWMdQEcQh9QcAHxAElEWuQRo97VyL3lptGWDDqY5FU95p0Wdp8AfRaDBjP6PoaBPoOcbUUEVlHIyE88HsCKHmKT6QeeLFkd78WIhSCaSn1toTOMSwzdBlaJdvzZdWGWm/Z+mpnKZCUdSWFrIq+2chjZXARkrVfC+TVR+rQ+O4Fd9QHUUzEPuFzdavQEIykDKLtiwtE3V+JHTRyBqW5FFHPQhyYor7JLXPtGvX/k2WUNlXeRFmq2MiqKXUj+bd36QH6tprQY=; 5:3kE9DDZGY7JShZtBGYXXSOc7K+D2MNE3zUotrHfxNA8p3Z7xsS2SLyeCI8nAgpLUcagqBgfA2FECJTqFZpimSSQgP8nSaS9+ePJCIoxiAQNCzv6DWEQVtr0/tAwbGg75RXzXIgoa+k1u0q8kwZfybg==; 24:CDSgOIMcXLkKWCtMs/zAJJZtwUdVkILJXAiLGmQgx/tah+qdAj4KuoEDTu+Ns/ZFxCzxR37rCxFbyWe98N4+1IhehLu74L/zlHjLvD21y1o=; 7:i24Y9xIWtUuUMMFDVl88wBH9KV59uib7RXi/L5irXDoFBcrRK+5xjZrVeYTDkebQ4hzzsJe1DjRLljHBM6AFtgw7M1HPcz84qEsEHGnD7QW4z0PlZ4RmqKdDHkAR6ZnGuhXzN7zouA9frdXkdDLItv5dUiPOsdnJdUAiw91mGRd1H+J86eqTnzVrbF3jBWTaZIq6UV7vDfxhi+hpMygXGw1HQceaJvvpWBO8jUbwq639E2TdxR7aOvBVKQvt2inv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377424004)(199003)(189002)(377454003)(93886004)(2900100001)(2906002)(92566002)(2950100001)(74316002)(122556002)(99286002)(50986999)(2351001)(2501003)(3280700002)(3660700001)(8936002)(4326007)(3846002)(81166006)(6116002)(81156014)(5640700001)(76576001)(102836003)(5002640100001)(586003)(15975445007)(11100500001)(19580395003)(66066001)(86362001)(8676002)(5003600100003)(68736007)(7736002)(1730700003)(106356001)(87936001)(101416001)(106116001)(10400500002)(305945005)(77096005)(76176999)(105586002)(54356999)(189998001)(7846002)(9686002)(19580405001)(110136002)(33656002)(7696003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.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: 13 Jul 2016 14:36:09.4912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 14:36:15 -0000 Hi Peter The scenario you described is part of the generic discovery problem. To perform its tasks, clients typically need to known the list of modules, = features, deviations implemented by a server and associated versions. This problem is addressed in http://core-wg.github.io/yang-cbor/draft-veill= ette-core-cool-library-latest.html which is the constrained version of http= s://datatracker.ietf.org/doc/rfc7895/=20 module: ietf-cool-library +--ro modules-state +--ro module-set-id union +--ro module* [sid revision] +--ro sid sid +--ro revision revision +--ro feature* sid +--ro deviation* [sid revision] | +--ro sid sid | +--ro revision revision +--ro conformance-type enumeration +--ro submodules +--ro submodule* [sid revision] +--ro sid sid +--ro revision revision notifications: +---n yang-library-change +--ro module-set-id -> /modules-state/module-set-id Regards Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Wednesday, July 13, 2016 2:34 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 Hi Michel, When a specification changes it set of of keys, I don't think the SIDs will= change. It is for sure that the hashes are not affected by the attribution of a key= . Therefore, what happens when client and server use different keys in otherw= ise identical list specification? Peter Michel Veillette schreef op 2016-07-12 17:07: > Hi Peter >=20 > The validations performed by the entity which de-serialize the CBOR=20 > payload is based on the YANG schema. > This validation is based on all king of YANG statements such as: > key, unique, range, pattern, length, min-elements, max-elements, must,=20 > when, if-feature >=20 > The identification of which data nodes are keys is considered=20 > unnecessary meta-data since available in the schema. > Even more heavy weight representations such as xml and json don't=20 > include this meta-data in the encode payload. >=20 > Regards, > Michel >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday, July 12, 2016 6:08 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 >=20 > Hi Michel, >=20 >>=20 >> However, I am missing how to transport a given list instance with its=20 >> key values in the CBOR encoding. Section 4.4 describes the encoding=20 >> of a complete list not a subset of its instances. >>=20 >> [MV] A list instance is a collection which is described in section=20 >> 4.2. >> _____________________________________________________________________ >> _ >> _______________________ >=20 > With the current text I don't see how you distinguish instances with=20 > the same key from instances with different keys. >=20 > Example: >=20 > list server { > key name; >=20 > leaf name { > type string; > } > leaf iburst { > type boolean; > default false; > } >=20 > How to distinguish that in the list below that two instances are=20 > identical (should not occur) > [ > { > 1755 : "NRC TIC server", # name (SID 1755) > 1754 : false, # iburst (SID 1754) > }, > { > 1755 : "NRC TIC server", # name (SID 1755) > 1754 : true, # iburst (SID 1754) > } > ] >=20 > And the following two instances are different (valid array) >=20 > [ > { > 1755 : "NRC TAC server", # name (SID 1755) > 1754 : true, # iburst (SID 1754) > }, > { > 1755 : "NRC TIC server", # name (SID 1755) > 1754 : true, # iburst (SID 1754) > } > ] From nobody Wed Jul 13 09:54:41 2016 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 CDBB712D15F for ; Wed, 13 Jul 2016 09:54:39 -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 5NDSNy7FiHlh for ; Wed, 13 Jul 2016 09:54:37 -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 332B612B006 for ; Wed, 13 Jul 2016 09:54:37 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.205]) by smtp-cloud3.xs4all.net with ESMTP id JGuZ1t0054RV18J01GuZup; Wed, 13 Jul 2016 18:54:35 +0200 Received: from 2001:983:a264:1:dddc:ebbf:62de:a3e1 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 18:54:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 18:54:33 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> Message-ID: <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> X-Sender: stokcons@xs4all.nl (ZWrSfliuHrVO6jqcDnBDuNGdJUEKfB4C) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 16:54:40 -0000 Hi Michel, That looks pretty complex to me; while the keys can be elegantly expressed in the CBOR contents. Peter Michel Veillette schreef op 2016-07-13 16:36: > Hi Peter > > The scenario you described is part of the generic discovery problem. > To perform its tasks, clients typically need to known the list of > modules, features, deviations implemented by a server and associated > versions. > This problem is addressed in > http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-latest.html > which is the constrained version of > https://datatracker.ietf.org/doc/rfc7895/ > > module: ietf-cool-library > +--ro modules-state > +--ro module-set-id union > +--ro module* [sid revision] > +--ro sid sid > +--ro revision revision > +--ro feature* sid > +--ro deviation* [sid revision] > | +--ro sid sid > | +--ro revision revision > +--ro conformance-type enumeration > +--ro submodules > +--ro submodule* [sid revision] > +--ro sid sid > +--ro revision revision > notifications: > +---n yang-library-change > +--ro module-set-id -> /modules-state/module-set-id > > Regards > Michel > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Wednesday, July 13, 2016 2:34 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 > > Hi Michel, > > When a specification changes it set of of keys, I don't think the SIDs > will change. > It is for sure that the hashes are not affected by the attribution of a > key. > > Therefore, what happens when client and server use different keys in > otherwise identical list specification? > > Peter > > Michel Veillette schreef op 2016-07-12 17:07: >> Hi Peter >> >> The validations performed by the entity which de-serialize the CBOR >> payload is based on the YANG schema. >> This validation is based on all king of YANG statements such as: >> key, unique, range, pattern, length, min-elements, max-elements, must, >> when, if-feature >> >> The identification of which data nodes are keys is considered >> unnecessary meta-data since available in the schema. >> Even more heavy weight representations such as xml and json don't >> include this meta-data in the encode payload. >> >> Regards, >> Michel >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Tuesday, July 12, 2016 6:08 AM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >> >> Hi Michel, >> >>> >>> However, I am missing how to transport a given list instance with its >>> key values in the CBOR encoding. Section 4.4 describes the encoding >>> of a complete list not a subset of its instances. >>> >>> [MV] A list instance is a collection which is described in section >>> 4.2. >>> _____________________________________________________________________ >>> _ >>> _______________________ >> >> With the current text I don't see how you distinguish instances with >> the same key from instances with different keys. >> >> Example: >> >> list server { >> key name; >> >> leaf name { >> type string; >> } >> leaf iburst { >> type boolean; >> default false; >> } >> >> How to distinguish that in the list below that two instances are >> identical (should not occur) >> [ >> { >> 1755 : "NRC TIC server", # name (SID 1755) >> 1754 : false, # iburst (SID 1754) >> }, >> { >> 1755 : "NRC TIC server", # name (SID 1755) >> 1754 : true, # iburst (SID 1754) >> } >> ] >> >> And the following two instances are different (valid array) >> >> [ >> { >> 1755 : "NRC TAC server", # name (SID 1755) >> 1754 : true, # iburst (SID 1754) >> }, >> { >> 1755 : "NRC TIC server", # name (SID 1755) >> 1754 : true, # iburst (SID 1754) >> } >> ] From nobody Wed Jul 13 10:06:10 2016 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 E068812D0DC for ; Wed, 13 Jul 2016 10:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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=-0.001, 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 GfXQWXOyJPUc for ; Wed, 13 Jul 2016 10:06:07 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BED12D0C9 for ; Wed, 13 Jul 2016 10:06: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=fJILYpxZbvGgtX9dc3rY4YvYPb/fdPUDZCCuqwk6OnQ=; b=ZPyXuaW7tFMjmDEX7F2LHXWiNfp73RJaTNEBecxqxy6fDqeFF9A1g1J+dw2BSw0T/v6ebGMGtczfrAfcEWc0hu9d2vTExa3GDp8Fw8mXZgIYPU/f/MtjhEoGKhNS3NEYCWDIuYFeU/VfARUBjPZBluBVzTPS3FWOxYymEvOCQaw= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 17:06:04 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 17:06:04 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYCugCAAFEisIABBZSAgACEZ/CAACjkgIAAAPZA Date: Wed, 13 Jul 2016 17:06:04 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> In-Reply-To: <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> 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: [24.225.215.88] x-ms-office365-filtering-correlation-id: aac46af9-8a45-44d5-5e08-08d3ab3ff9b1 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:J4YbpnybzR1RTip35qaEEVov4HFxvX+DFgmMQw9i02xd894lSIxW0tlvyS+mfpKMutLhRw3lEBQ1DgxTqCc96JxEMTjn3mOZO+6Rqh8zqOy5pB8pVLjbziwExvXHVH0q3HuDOopkVro3A58bY2eOO7A73xfCg6w/TUm6ENn/xsj6Y9QT/5ko/+DLIz4Slo30GzqY8L0r/5sDWWa/bU0UXVds79j2AdQFyNZgV88jQfb9a1zi3z+ORD/rcfRgW3Pgfn6X/P1NyaVTCPOurNJObdwt3JSq0S99Nz0I9Jysexo=; 5:RDwWy111wruaSAjpZ5iN6LcUlBXDk1R3Gb4kgpKevKDf1AfgTb8Zq5u8WpPJcv4quIi+FYybCZw/KGBid9NQx+kLoyu0G1WOrNJ7xId0ItJEr1uRiGJHfxQvtMiopJSTMFsWYNpQzkxnxwg8J0O/fw==; 24:b1Slx2s8474x968XTWJodFOnXLB6CLPgoWksNQlaoAkf7mR/1WZzdW6GzSQXvdggIaWHZSGukl4ZPL9zCVayG8Y0Or/8poVivmeQ+MpFPb0=; 7:j9WxyA4azqNaMZw9RBmBfp6zcVB8UCrHUOqgwybkbSQGFBvc6WV5VTLbR/CiG9SSrwx6fi62BIjHE9TgXiIs2ycjBOEy7QM16PjDEBFsRS8w9G451HNMTXJM9rjdNZyL9zrDkv7w5PTcgvCmRF/hSaZrv2eeViAKhhZkoJzZJQh60zrY8IrkYQIu5p5ed4MJjb6zTRODA/cATZzq1fdxA48NuWV0uOz9+ln41+XkKCV4StFhKc1Va9RcJx5LI8eW x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377424004)(199003)(189002)(377454003)(93886004)(2900100001)(2906002)(92566002)(2950100001)(74316002)(99286002)(122556002)(50986999)(2501003)(3280700002)(3660700001)(8936002)(4326007)(3846002)(6116002)(81156014)(81166006)(5640700001)(2351001)(76576001)(102836003)(5002640100001)(586003)(15975445007)(11100500001)(19580395003)(66066001)(86362001)(8676002)(5003600100003)(68736007)(7736002)(1730700003)(87936001)(10400500002)(101416001)(106116001)(305945005)(106356001)(77096005)(1720100001)(105586002)(76176999)(54356999)(189998001)(7846002)(9686002)(19580405001)(110136002)(7696003)(33656002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.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: 13 Jul 2016 17:06:04.7660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jul 2016 17:06:09 -0000 Hi Peter I'm not convinced that Including in the encoding which data nodes are the k= eys completely solve the issue. If the client transmit a payload with one key and the server required two k= eys, the payload will be rejected. If the client transmit a payload with two keys (marked as such) and the ser= ver require one key, the payload will be rejected. To work, both sides need to known the number of keys used by the other side= and only 'ietf-cool-library' can resolve that. Also, not making which data nodes are keys might help during the migration. Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Wednesday, July 13, 2016 12:55 PM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 Hi Michel, That looks pretty complex to me; while the keys can be elegantly expressed = in the CBOR contents. Peter Michel Veillette schreef op 2016-07-13 16:36: > Hi Peter >=20 > The scenario you described is part of the generic discovery problem. > To perform its tasks, clients typically need to known the list of=20 > modules, features, deviations implemented by a server and associated=20 > versions. > This problem is addressed in > http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-l > atest.html > which is the constrained version of > https://datatracker.ietf.org/doc/rfc7895/ >=20 > module: ietf-cool-library > +--ro modules-state > +--ro module-set-id union > +--ro module* [sid revision] > +--ro sid sid > +--ro revision revision > +--ro feature* sid > +--ro deviation* [sid revision] > | +--ro sid sid > | +--ro revision revision > +--ro conformance-type enumeration > +--ro submodules > +--ro submodule* [sid revision] > +--ro sid sid > +--ro revision revision > notifications: > +---n yang-library-change > +--ro module-set-id -> /modules-state/module-set-id >=20 > Regards > Michel >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Wednesday, July 13, 2016 2:34 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 >=20 > Hi Michel, >=20 > When a specification changes it set of of keys, I don't think the SIDs=20 > will change. > It is for sure that the hashes are not affected by the attribution of=20 > a key. >=20 > Therefore, what happens when client and server use different keys in=20 > otherwise identical list specification? >=20 > Peter >=20 > Michel Veillette schreef op 2016-07-12 17:07: >> Hi Peter >>=20 >> The validations performed by the entity which de-serialize the CBOR=20 >> payload is based on the YANG schema. >> This validation is based on all king of YANG statements such as: >> key, unique, range, pattern, length, min-elements, max-elements,=20 >> must, when, if-feature >>=20 >> The identification of which data nodes are keys is considered=20 >> unnecessary meta-data since available in the schema. >> Even more heavy weight representations such as xml and json don't=20 >> include this meta-data in the encode payload. >>=20 >> Regards, >> Michel >>=20 >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Tuesday, July 12, 2016 6:08 AM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >>=20 >> Hi Michel, >>=20 >>>=20 >>> However, I am missing how to transport a given list instance with=20 >>> its key values in the CBOR encoding. Section 4.4 describes the=20 >>> encoding of a complete list not a subset of its instances. >>>=20 >>> [MV] A list instance is a collection which is described in section=20 >>> 4.2. >>> ____________________________________________________________________ >>> _ >>> _ >>> _______________________ >>=20 >> With the current text I don't see how you distinguish instances with=20 >> the same key from instances with different keys. >>=20 >> Example: >>=20 >> list server { >> key name; >>=20 >> leaf name { >> type string; >> } >> leaf iburst { >> type boolean; >> default false; >> } >>=20 >> How to distinguish that in the list below that two instances are=20 >> identical (should not occur) >> [ >> { >> 1755 : "NRC TIC server", # name (SID 1755) >> 1754 : false, # iburst (SID 1754) >> }, >> { >> 1755 : "NRC TIC server", # name (SID 1755) >> 1754 : true, # iburst (SID 1754) >> } >> ] >>=20 >> And the following two instances are different (valid array) >>=20 >> [ >> { >> 1755 : "NRC TAC server", # name (SID 1755) >> 1754 : true, # iburst (SID 1754) >> }, >> { >> 1755 : "NRC TIC server", # name (SID 1755) >> 1754 : true, # iburst (SID 1754) >> } >> ] From nobody Thu Jul 14 00:57:01 2016 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 8577F12B028 for ; Thu, 14 Jul 2016 00:56:59 -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 7F7dsEp0V96j for ; Thu, 14 Jul 2016 00:56:57 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A081B128E19 for ; Thu, 14 Jul 2016 00:56:56 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud2.xs4all.net with ESMTP id JXwu1t0084aYjWA01XwuHL; Thu, 14 Jul 2016 09:56:54 +0200 Received: from static.ip-80-255-245-232.signet.nl ([80.255.245.232]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 09:56:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Jul 2016 09:56:54 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> Message-ID: <43805298839959a534d83c720ac6239c@xs4all.nl> X-Sender: stokcons@xs4all.nl (XYGnccwFMz1NKFTwZBggev/w80pGfCuJ) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:56:59 -0000 Hi Michel, IMO, an error is an error and should be treated as such. Trying to salvage unhealthy situations leads to worse problems. My approach would be that servers and clients are simple and don't need to parse the yang modules during operation; and keep extensive state information about each other. The discussion seems to confirm my growing conviction that the CoMI and CoOL approaches are fundamentally different. Peter Michel Veillette schreef op 2016-07-13 19:06: > Hi Peter > > I'm not convinced that Including in the encoding which data nodes are > the keys completely solve the issue. > If the client transmit a payload with one key and the server required > two keys, the payload will be rejected. > If the client transmit a payload with two keys (marked as such) and > the server require one key, the payload will be rejected. > To work, both sides need to known the number of keys used by the other > side and only 'ietf-cool-library' can resolve that. > > Also, not making which data nodes are keys might help during the > migration. > > Regards, > Michel > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Wednesday, July 13, 2016 12:55 PM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 > > Hi Michel, > > That looks pretty complex to me; while the keys can be elegantly > expressed in the CBOR contents. > > Peter > > Michel Veillette schreef op 2016-07-13 16:36: >> Hi Peter >> >> The scenario you described is part of the generic discovery problem. >> To perform its tasks, clients typically need to known the list of >> modules, features, deviations implemented by a server and associated >> versions. >> This problem is addressed in >> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-l >> atest.html >> which is the constrained version of >> https://datatracker.ietf.org/doc/rfc7895/ >> >> module: ietf-cool-library >> +--ro modules-state >> +--ro module-set-id union >> +--ro module* [sid revision] >> +--ro sid sid >> +--ro revision revision >> +--ro feature* sid >> +--ro deviation* [sid revision] >> | +--ro sid sid >> | +--ro revision revision >> +--ro conformance-type enumeration >> +--ro submodules >> +--ro submodule* [sid revision] >> +--ro sid sid >> +--ro revision revision >> notifications: >> +---n yang-library-change >> +--ro module-set-id -> /modules-state/module-set-id >> >> Regards >> Michel >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Wednesday, July 13, 2016 2:34 AM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >> >> Hi Michel, >> >> When a specification changes it set of of keys, I don't think the SIDs >> will change. >> It is for sure that the hashes are not affected by the attribution of >> a key. >> >> Therefore, what happens when client and server use different keys in >> otherwise identical list specification? >> >> Peter >> >> Michel Veillette schreef op 2016-07-12 17:07: >>> Hi Peter >>> >>> The validations performed by the entity which de-serialize the CBOR >>> payload is based on the YANG schema. >>> This validation is based on all king of YANG statements such as: >>> key, unique, range, pattern, length, min-elements, max-elements, >>> must, when, if-feature >>> >>> The identification of which data nodes are keys is considered >>> unnecessary meta-data since available in the schema. >>> Even more heavy weight representations such as xml and json don't >>> include this meta-data in the encode payload. >>> >>> Regards, >>> Michel >>> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Tuesday, July 12, 2016 6:08 AM >>> To: Michel Veillette >>> Cc: consultancy@vanderstok.org; Core >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>> >>> Hi Michel, >>> >>>> >>>> However, I am missing how to transport a given list instance with >>>> its key values in the CBOR encoding. Section 4.4 describes the >>>> encoding of a complete list not a subset of its instances. >>>> >>>> [MV] A list instance is a collection which is described in section >>>> 4.2. >>>> ____________________________________________________________________ >>>> _ >>>> _ >>>> _______________________ >>> >>> With the current text I don't see how you distinguish instances with >>> the same key from instances with different keys. >>> >>> Example: >>> >>> list server { >>> key name; >>> >>> leaf name { >>> type string; >>> } >>> leaf iburst { >>> type boolean; >>> default false; >>> } >>> >>> How to distinguish that in the list below that two instances are >>> identical (should not occur) >>> [ >>> { >>> 1755 : "NRC TIC server", # name (SID 1755) >>> 1754 : false, # iburst (SID 1754) >>> }, >>> { >>> 1755 : "NRC TIC server", # name (SID 1755) >>> 1754 : true, # iburst (SID 1754) >>> } >>> ] >>> >>> And the following two instances are different (valid array) >>> >>> [ >>> { >>> 1755 : "NRC TAC server", # name (SID 1755) >>> 1754 : true, # iburst (SID 1754) >>> }, >>> { >>> 1755 : "NRC TIC server", # name (SID 1755) >>> 1754 : true, # iburst (SID 1754) >>> } >>> ] From nobody Thu Jul 14 01:39:56 2016 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 8108412DB12 for ; Thu, 14 Jul 2016 01:39:55 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 K2y9YjBEnvfW for ; Thu, 14 Jul 2016 01:39:53 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEBA12DB10 for ; Thu, 14 Jul 2016 01:39:51 -0700 (PDT) Received: from mfilter45-d.gandi.net (mfilter45-d.gandi.net [217.70.178.176]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id A9D4E41C08A; Thu, 14 Jul 2016 10:39:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter45-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter45-d.gandi.net (mfilter45-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id BR5OwbgXLrpK; Thu, 14 Jul 2016 10:39:48 +0200 (CEST) X-Originating-IP: 37.166.79.179 Received: from [192.168.43.129] (unknown [37.166.79.179]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 5EECC41C091; Thu, 14 Jul 2016 10:39:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: <43805298839959a534d83c720ac6239c@xs4all.nl> Date: Thu, 14 Jul 2016 10:39:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9409ECE5-77DF-481B-B2C6-0BA6337EA60A@ackl.io> References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <43805298839959a534d83c720ac6239c@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 08:39:55 -0000 Dear Peter, I agree with you - if a server expects TWO keys, but receives ONE this = is an error. What I don=E2=80=99t understand is how marking the CBOR = content changes anything to this. (if the client insists that a leaf is = a key and the server disagrees - then you have error. if the server = requires a key and the client does not provide it - stil an error).=20 =46rom implementation point of view, the server will never recompile the = YANG module. YANG is used compile-time (when you generate your program = on your laptop) and as a contract between the client and the server. The = same goes for constrained clients.=20 In most cases, the server and the client will actually not need to have = the YANG module scheme at all - only a couple of SIDs, associated = meta-data (in binary - such as the type) and the associated functions = (which you need anyways). As SIDs never change, you don=E2=80=99t need = anything else on the device. It could be even simpler - without the = meta-data - but then the associated functions need to do the validation = (e.g. Arduino implementations). Alexander > Le 14 juil. 2016 =C3=A0 09:56, peter van der Stok = a =C3=A9crit : >=20 > Hi Michel, >=20 > IMO, an error is an error and should be treated as such. Trying to = salvage unhealthy situations leads to worse problems. >=20 > My approach would be that servers and clients are simple and don't = need to parse the yang modules during operation; and keep extensive = state information about each other. >=20 > The discussion seems to confirm my growing conviction that the CoMI = and CoOL approaches are fundamentally different. >=20 > Peter >=20 > Michel Veillette schreef op 2016-07-13 19:06: >> Hi Peter >> I'm not convinced that Including in the encoding which data nodes are >> the keys completely solve the issue. >> If the client transmit a payload with one key and the server required >> two keys, the payload will be rejected. >> If the client transmit a payload with two keys (marked as such) and >> the server require one key, the payload will be rejected. >> To work, both sides need to known the number of keys used by the = other >> side and only 'ietf-cool-library' can resolve that. >> Also, not making which data nodes are keys might help during the = migration. >> Regards, >> Michel >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Wednesday, July 13, 2016 12:55 PM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >> Hi Michel, >> That looks pretty complex to me; while the keys can be elegantly >> expressed in the CBOR contents. >> Peter >> Michel Veillette schreef op 2016-07-13 16:36: >>> Hi Peter >>> The scenario you described is part of the generic discovery problem. >>> To perform its tasks, clients typically need to known the list of >>> modules, features, deviations implemented by a server and associated >>> versions. >>> This problem is addressed in >>> = http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-l >>> atest.html >>> which is the constrained version of >>> https://datatracker.ietf.org/doc/rfc7895/ >>> module: ietf-cool-library >>> +--ro modules-state >>> +--ro module-set-id union >>> +--ro module* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> +--ro feature* sid >>> +--ro deviation* [sid revision] >>> | +--ro sid sid >>> | +--ro revision revision >>> +--ro conformance-type enumeration >>> +--ro submodules >>> +--ro submodule* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> notifications: >>> +---n yang-library-change >>> +--ro module-set-id -> /modules-state/module-set-id >>> Regards >>> Michel >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Wednesday, July 13, 2016 2:34 AM >>> To: Michel Veillette >>> Cc: consultancy@vanderstok.org; Core >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>> Hi Michel, >>> When a specification changes it set of of keys, I don't think the = SIDs >>> will change. >>> It is for sure that the hashes are not affected by the attribution = of >>> a key. >>> Therefore, what happens when client and server use different keys in >>> otherwise identical list specification? >>> Peter >>> Michel Veillette schreef op 2016-07-12 17:07: >>>> Hi Peter >>>> The validations performed by the entity which de-serialize the CBOR >>>> payload is based on the YANG schema. >>>> This validation is based on all king of YANG statements such as: >>>> key, unique, range, pattern, length, min-elements, max-elements, >>>> must, when, if-feature >>>> The identification of which data nodes are keys is considered >>>> unnecessary meta-data since available in the schema. >>>> Even more heavy weight representations such as xml and json don't >>>> include this meta-data in the encode payload. >>>> Regards, >>>> Michel >>>> -----Original Message----- >>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>> Sent: Tuesday, July 12, 2016 6:08 AM >>>> To: Michel Veillette >>>> Cc: consultancy@vanderstok.org; Core >>>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>> Hi Michel, >>>>> However, I am missing how to transport a given list instance with >>>>> its key values in the CBOR encoding. Section 4.4 describes the >>>>> encoding of a complete list not a subset of its instances. >>>>> [MV] A list instance is a collection which is described in section >>>>> 4.2. >>>>> = ____________________________________________________________________ >>>>> _ >>>>> _ >>>>> _______________________ >>>> With the current text I don't see how you distinguish instances = with >>>> the same key from instances with different keys. >>>> Example: >>>> list server { >>>> key name; >>>> leaf name { >>>> type string; >>>> } >>>> leaf iburst { >>>> type boolean; >>>> default false; >>>> } >>>> How to distinguish that in the list below that two instances are >>>> identical (should not occur) >>>> [ >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : false, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] >>>> And the following two instances are different (valid array) >>>> [ >>>> { >>>> 1755 : "NRC TAC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 14 04:37:34 2016 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 80DF212D753 for ; Thu, 14 Jul 2016 04:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 ev2Ff8BiJkYZ for ; Thu, 14 Jul 2016 04:37:30 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3973812D526 for ; Thu, 14 Jul 2016 04:37:30 -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=kwSaYvEYhl/blOk5Zr/MWpghRppRTi6aDPNCkB5eefE=; b=qLmXfpqpG7ULY5F9jwt1Yl4pToLLxK/UWWHovcXNNTr9D3q2cPDT+N8ghs0NCXlnwkHQVlk2gnl24ipsSab343cqblE4xLkEsA0Iy0ZkZIEdCumsWbvhha6rJo09bfbQqCMSKqeeSUU46xHPeR9pb7nWw/SB0YDqaAhDkjPMHGo= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Thu, 14 Jul 2016 11:37:28 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Thu, 14 Jul 2016 11:37:28 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYCugCAAFEisIABBZSAgACEZ/CAACjkgIAAAPZAgAD7JwCAADlmwA== Date: Thu, 14 Jul 2016 11:37:28 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <43805298839959a534d83c720ac6239c@xs4all.nl> In-Reply-To: <43805298839959a534d83c720ac6239c@xs4all.nl> 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: [24.225.215.88] x-ms-office365-filtering-correlation-id: 7dd11be8-36d3-447c-9c00-08d3abdb3c18 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:4CkK2CIu3CcwTxDQ4mSNUsqVHJWeEzdp1p21sFq1QpNqSQOwMPRXT6VGUb0FzRaFsnl5Y5rig0vI7OpGMtEcVRoEb9pC/Ug8IG0iu3U/oIHdj7eTcoZQ6bYLke5iEK9BHE6VizeD5TFXIDGjw9JyLkyjjw0K/P6QjSG5C6AivtFUiZQ0N15RuG8V5r/8Wm/v9JvJPjFWJzcFuGQZhOPQtgNdwudpTvC9lFD3rhOwbG1A5v/r7rm6YO0840O9FBt2dA5HCO8Goi5PU9Xm2gGzWs2l38hgBkGdBdxn3m2gm2U=; 5:ape3BbGBS6QwFw/Z5FJAT1EjADGec8LzNxgGOpHwL6yeh+NfZPdVPSZLJvCNv8J6Qav2A/YMCdZUJJEelUu7R8SM0i0FEhHvIYf2iBnyfjtwHi7oliFv4eaAXBfyPHMmMe2jRUiPKI8SHvPviY/NZg==; 24:E7gzgJIY9gEoXNg6EPwKp/8djDIf508KZx0fdLmlPvuwvzQ7QgjaIteI9WKdCz6ZV7SOb2ajineeUlP7NE+YywIlTZWfc8d2tsZYStw/J3Q=; 7:6jUf85R1avzpOuznMcK2aU8HbEMBJz8JUClh+Gyq2om3z1nX5d2TT5H5kUkMU01LcLn9cFqXaEBLaEFt+aAZfHt4JdzH5CRVz6NS9o5ieZ+upL1Kd02Crs7/+3UX/KNpHad08RrU9erCOrMSlVD95c0NowxJt5kI++RGejFo8pPvVRIvj2/IM26YgXQKoMG/HCna2Kigqmks6jmsWku0s6HahQVnQRK1IN+21ztp+zDLtDXAUlwJrsKasGRuzhoG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377424004)(377454003)(13464003)(199003)(10400500002)(33656002)(7696003)(1730700003)(87936001)(8676002)(8936002)(105586002)(86362001)(11100500001)(66066001)(7846002)(81166006)(81156014)(76176999)(189998001)(110136002)(97736004)(7736002)(5003600100003)(74316002)(68736007)(50986999)(19580405001)(4326007)(305945005)(6116002)(2501003)(5002640100001)(2906002)(15975445007)(99286002)(101416001)(3846002)(102836003)(2950100001)(586003)(2900100001)(19580395003)(76576001)(77096005)(106116001)(92566002)(93886004)(54356999)(3660700001)(2351001)(106356001)(3280700002)(9686002)(1720100001)(122556002)(5640700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.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: 14 Jul 2016 11:37:28.2443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 11:37:32 -0000 Hi Peter Validation mechanisms are defined by YANG ('key', 'unique', 'range', 'patt= ern', 'length', 'min-elements', 'max-elements',=20 'must', 'when', 'if-feature'), not by CoOL or CoMI.=20 Any protocol based on YANG need to be able to support those mechanisms. Adding meta data in the encoding to identity which data nodes are keys don'= t eliminate de need for clients and servers to have some knowledge of the s= chema. The general rule established for "draft-ietf-core-yang-cbor" is simple. " In order to minimize the size of the encoded data, the proposed mapping avoid any unnecessary meta-information beyond those natively supported by CBOR." https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-3 In this case, you propose to add more meta data than "draft-ietf-netmod-yan= g-json" which don't share the same limitations on the payload size. https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Thursday, July 14, 2016 3:57 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 Hi Michel, IMO, an error is an error and should be treated as such. Trying to salvage = unhealthy situations leads to worse problems. My approach would be that servers and clients are simple and don't need to = parse the yang modules during operation; and keep extensive state informati= on about each other. The discussion seems to confirm my growing conviction that the CoMI and CoO= L approaches are fundamentally different. Peter Michel Veillette schreef op 2016-07-13 19:06: > Hi Peter >=20 > I'm not convinced that Including in the encoding which data nodes are=20 > the keys completely solve the issue. > If the client transmit a payload with one key and the server required=20 > two keys, the payload will be rejected. > If the client transmit a payload with two keys (marked as such) and=20 > the server require one key, the payload will be rejected. > To work, both sides need to known the number of keys used by the other=20 > side and only 'ietf-cool-library' can resolve that. >=20 > Also, not making which data nodes are keys might help during the=20 > migration. >=20 > Regards, > Michel >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Wednesday, July 13, 2016 12:55 PM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 >=20 > Hi Michel, >=20 > That looks pretty complex to me; while the keys can be elegantly=20 > expressed in the CBOR contents. >=20 > Peter >=20 > Michel Veillette schreef op 2016-07-13 16:36: >> Hi Peter >>=20 >> The scenario you described is part of the generic discovery problem. >> To perform its tasks, clients typically need to known the list of=20 >> modules, features, deviations implemented by a server and associated=20 >> versions. >> This problem is addressed in >> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library- >> l >> atest.html >> which is the constrained version of >> https://datatracker.ietf.org/doc/rfc7895/ >>=20 >> module: ietf-cool-library >> +--ro modules-state >> +--ro module-set-id union >> +--ro module* [sid revision] >> +--ro sid sid >> +--ro revision revision >> +--ro feature* sid >> +--ro deviation* [sid revision] >> | +--ro sid sid >> | +--ro revision revision >> +--ro conformance-type enumeration >> +--ro submodules >> +--ro submodule* [sid revision] >> +--ro sid sid >> +--ro revision revision >> notifications: >> +---n yang-library-change >> +--ro module-set-id -> /modules-state/module-set-id >>=20 >> Regards >> Michel >>=20 >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Wednesday, July 13, 2016 2:34 AM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >>=20 >> Hi Michel, >>=20 >> When a specification changes it set of of keys, I don't think the=20 >> SIDs will change. >> It is for sure that the hashes are not affected by the attribution of=20 >> a key. >>=20 >> Therefore, what happens when client and server use different keys in=20 >> otherwise identical list specification? >>=20 >> Peter >>=20 >> Michel Veillette schreef op 2016-07-12 17:07: >>> Hi Peter >>>=20 >>> The validations performed by the entity which de-serialize the CBOR=20 >>> payload is based on the YANG schema. >>> This validation is based on all king of YANG statements such as: >>> key, unique, range, pattern, length, min-elements, max-elements,=20 >>> must, when, if-feature >>>=20 >>> The identification of which data nodes are keys is considered=20 >>> unnecessary meta-data since available in the schema. >>> Even more heavy weight representations such as xml and json don't=20 >>> include this meta-data in the encode payload. >>>=20 >>> Regards, >>> Michel >>>=20 >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Tuesday, July 12, 2016 6:08 AM >>> To: Michel Veillette >>> Cc: consultancy@vanderstok.org; Core >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>=20 >>> Hi Michel, >>>=20 >>>>=20 >>>> However, I am missing how to transport a given list instance with=20 >>>> its key values in the CBOR encoding. Section 4.4 describes the=20 >>>> encoding of a complete list not a subset of its instances. >>>>=20 >>>> [MV] A list instance is a collection which is described in section=20 >>>> 4.2. >>>> ___________________________________________________________________ >>>> _ >>>> _ >>>> _ >>>> _______________________ >>>=20 >>> With the current text I don't see how you distinguish instances with=20 >>> the same key from instances with different keys. >>>=20 >>> Example: >>>=20 >>> list server { >>> key name; >>>=20 >>> leaf name { >>> type string; >>> } >>> leaf iburst { >>> type boolean; >>> default false; >>> } >>>=20 >>> How to distinguish that in the list below that two instances are=20 >>> identical (should not occur) >>> [ >>> { >>> 1755 : "NRC TIC server", # name (SID 1755) >>> 1754 : false, # iburst (SID 1754) >>> }, >>> { >>> 1755 : "NRC TIC server", # name (SID 1755) >>> 1754 : true, # iburst (SID 1754) >>> } >>> ] >>>=20 >>> And the following two instances are different (valid array) >>>=20 >>> [ >>> { >>> 1755 : "NRC TAC server", # name (SID 1755) >>> 1754 : true, # iburst (SID 1754) >>> }, >>> { >>> 1755 : "NRC TIC server", # name (SID 1755) >>> 1754 : true, # iburst (SID 1754) >>> } >>> ] From nobody Thu Jul 14 04:44:21 2016 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 345AB12D56F for ; Thu, 14 Jul 2016 04:44:19 -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 KztnsDPMXroR for ; Thu, 14 Jul 2016 04:44:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC9812B010 for ; Thu, 14 Jul 2016 04:44:17 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-fc-57877b0f12ce Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.B5.12516.F0B77875; Thu, 14 Jul 2016 13:44:15 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.140]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 13:44:14 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1l?= =?utf-8?Q?tch-01?= Thread-Index: AQHR0JnQdP6iR0Z21EyknS8RGJOeqaAWMHsAgAAUQgCAAXSDAA== Date: Thu, 14 Jul 2016 11:44:13 +0000 Message-ID: References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> <578636BC.2010208@tzi.org> In-Reply-To: <578636BC.2010208@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7qC5/dXu4wd1OAYsjU+6yWux7u57Z Yu0SbwdmjyVLfjJ5fLn8mc1j2qLMAOYoLpuU1JzMstQifbsEroyOt8fZC+ZwVOz59pilgbGB o4uRk0NCwETi0sf9LBC2mMSFe+vZuhi5OIQEjjBKLPzWyA7hLGGU2PR+JiNIFZuArcST1n2s ILaIgJLEhYtr2EBsZoF0iZMdi8HiwgJZEpd2fGOBqMmWODhlPTuE7SRx5+QfsHoWAVWJvz/3 MIHYvAL2EnM7DoLNFxKYxChxcIkliM0poC4x79pxsBpGoOu+n1rDBLFLXOLWk/lMEFcLSCzZ c54ZwhaVePn4HyuErSSxYvsloJkcQPWaEut36UOY1hJ7f8hBTFGUmNL9kB3iAkGJkzOfsExg FJ+FZMEshOZZCM2zkDTPQtK8gJF1FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZg5B3c8lt3 B+Pq146HGAU4GJV4eBc0toULsSaWFVfmHmKU4GBWEuE9UNkeLsSbklhZlVqUH19UmpNafIhR moNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoGRY+qOOhPNLpOW1rd8QdP1jvBJPvvb+bLl ZNbHhdcWnX1v9+ahO2f84s8snB7Ci5TWMzv/L12043dG6SbWr62t7lMsUy5O12XPYGiNXyb4 wDDXd/ouTVVL1d35D00CfG1c3BZ/5mssPVci4sbd802yUUXlaPwyWVshhSlFDzZIuyRb/04P +KjEUpyRaKjFXFScCADRfo9nuAIAAA== Archived-At: Cc: "draft-ietf-core-etch@tools.ietf.org" , core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 11:44:19 -0000 DQo+IE9uIDEzIEp1bCAyMDE2LCBhdCAxNTo0MCwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5v cmc+IHdyb3RlOg0KPiANCj4gQXJpIEtlcsOkbmVuIHdyb3RlOg0KPj4gU2VjdGlvbiAyOg0KPj4+ PiBUaGUgcGF5bG9hZCByZXR1cm5lZCBpbiByZXNwb25zZSB0byBhIEZFVENIIGNhbm5vdCBiZSBh c3N1bWVkIHRvIGJlIGEgY29tcGxldGUgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlIGlk ZW50aWZpZWQgYnkgdGhlIGVmZmVjdGl2ZSByZXF1ZXN0IFVSSS4NCj4+IA0KPj4gQ2FuJ3QgSSB1 c2UgRkVUQ0ggdG8gcHJvZHVjZSBzYW1lIHJlc3VsdCBhcyBHRVQ/IEV2ZW4gaWYgSSB1c2UgaXQg d2l0aG91dCBhbnkgYWRkaXRpb25hbCByZXF1ZXN0IHBhcmFtZXRlcnM/DQo+IA0KPiBEZXBlbmRp bmcgb24gdGhlIHJlcXVlc3QgYm9keSBtZWRpYSB0eXBlLCB5b3UgbWF5IGJlIGFibGUgdG8gKGl0 IG1heSBub3QNCj4gYWx3YXlzIGJlIG9idmlvdXMgdGhhdCB5b3UganVzdCBkaWQgLS0gdGhlIHNl cnZlciBtYXkgaGF2ZSBzb21lIGxlZXdheQ0KPiBpbiBzb21lIGNhc2VzKS4gIFRoaXMgc2VudGVu Y2UgaXMgYW4gYWRtb25pdGlvbiBub3QgdG8gY2FjaGUgYSBGRVRDSA0KPiByZXN1bHQgYXMgaWYg aXQgd2VyZSBhIEdFVCByZXN1bHQuICAoU2hvdWxkIHdlIHNheSB0aGlzIG1vcmUgZXhwbGljaXRs eT8pDQoNCk9LLCBtYWtpbmcgaXQgbW9yZSBleHBsaWNpdCBzb3VuZHMgbGlrZSBhIHZlcnkgZ29v ZCBpZGVhLiANCg0KDQpDaGVlcnMsDQpBcmk= From nobody Thu Jul 14 04:44:30 2016 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 1056712B010 for ; Thu, 14 Jul 2016 04:44:24 -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 h6MunwWifCXo for ; Thu, 14 Jul 2016 04:44:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A5312D0AE for ; Thu, 14 Jul 2016 04:44:20 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-10-57877b123c86 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 45.E9.12926.21B77875; Thu, 14 Jul 2016 13:44:18 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.140]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 13:44:17 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "consultancy@vanderstok.org" , Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1l?= =?utf-8?Q?tch-01?= Thread-Index: AQHR0JnQdP6iR0Z21EyknS8RGJOeqaAWMHsAgAAQ1oCAAYXPAA== Date: Thu, 14 Jul 2016 11:44:16 +0000 Message-ID: References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@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.148] Content-Type: text/plain; charset="utf-8" Content-ID: <8E959A8D12B9A747829ACBE1C0B2A967@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7rq5QdXu4wf2DIhZHptxltXi0fxWb xb6365kt1i7xdmDxWLLkJ5PHl8uf2TymLcr0ONGwnT2AJYrLJiU1J7MstUjfLoErY8/ZKewF n0Qq2s/fZWpgXCPSxcjJISFgIjHl6VJWCFtM4sK99WxdjFwcQgJHGCU+z/8K5SxhlPiw8z4T SBWbgK3Ek9Z9YB0iAvESd7bMBoszC6RLnOxYDBYXFsiSuLTjGwtETbbEwSnr2SFsJ4mXRyeD 2SwCqhJNH/qYQWxeAXuJTTMaEZZt/nIdrJlTwFJi+4ZWsKGMQOd9P7UGapm4xK0n85kgzhaQ WLLnPDOELSrx8vE/qHeUJBqXPAGyOYDqNSXW79KHaLWW+H1jHzOErSgxpfshO8QNghInZz5h mcAoPgvJhlkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIExeXDL b9UdjJffOB5iFOBgVOLhXdDYFi7EmlhWXJl7iFGCg1lJhPdAZXu4EG9KYmVValF+fFFpTmrx IUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsasU/Xp7gurRHiup60W+9Qw/djF7R6L oiJupSSYa/oKsU2trn14/aoSQ1G9hhrTmTnL3c6acn9bv7TvlsJPk+cxyhGTjNfO546aqnNO KT6B9XCpp075Qp6+CxcFyptZXs1efnTFup1GjoYFjp3fT1hOcHjEemkz25VLJxZFiUSu/FN1 KVfwc6QSS3FGoqEWc1FxIgDgSs3dxQIAAA== Archived-At: Cc: "draft-ietf-core-etch@tools.ietf.org" , core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 11:44:26 -0000 DQo+IE9uIDEzIEp1bCAyMDE2LCBhdCAxNToyOCwgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29u c0B4czRhbGwubmw+IHdyb3RlOg0KPiANCj4gSGkgQXJpLA0KPiANCj4gdGhhbmtzIGZvciB0aGUg Y29tbWVudHMuIFNlZSBiZWxvdyBmb3IgbXkgcmVhY3Rpb24uDQo+IENhcnN0ZW4gbWF5IGhhdmUg ZGlmZmVyZW50IG9waW5pb25zIHRob3VnaC4NCj4gDQo+IEFyaSBLZXLDpG5lbiBzY2hyZWVmIG9w IDIwMTYtMDctMTMgMTM6Mjc6DQo+PiBIaSwNCj4+IEkgcmVhZCB0aGUgZHJhZnQgYW5kIGhhdmUg Y291cGxlIG9mIHF1ZXN0aW9ucy9jb21tZW50cy4NCj4+IFdoYXQgbWVkaWEgdHlwZSBjb3VsZCBi ZSB0b2RheSB1c2VkIHdpdGggRkVUQ0g/IFdoYXQgZG8gdGhlDQo+PiBpbXBsZW1lbnRhdGlvbnMg dXNlPyBJJ20gdGhpbmtpbmcgdGhhdCBzb21ldGhpbmcgbGlrZSB4cGF0aA0KPj4gKC9qc29ucGF0 aD8pIG1lZGlhIHR5cGUgd291bGQgYmUgZWFzeSB0byBkZWZpbmUuDQo+IA0KPiBBbiBhcnJheSBv ZiBKU09OIGlkZW50aWZpZXJzIGxvb2tzIHJlYXNvbmFibGUuIElzIGl0IHlvdXIgc3VnZ2VzdGlv biB0byBkZWZpbmUgdGhhdCBpbiB0aGlzIGRyYWZ0Pw0KDQpXaGF0IHdvdWxkIGJlIHRoZSBzZW1h bnRpY3Mgb2YgdGhhdCBhcnJheT8gIkdpdmUgb25seSB0aGVzZSBrZXktdmFsdWUtcGFpcnMiPyBI b3cgd291bGQgdGhhdCB3b3JrIHdpdGggbmVzdGVkIHN0cnVjdHVyZXMgYW5kIGFycmF5cz8NCg0K VGhlIHhwYXRoIGFuZCBqc29ucGF0aCBtZWRpYSB0eXBlcyBjb3VsZCBkbyB0aGF0IGFuZCBtdWNo IG1vcmUuIFNvbWUgb2YgdGhhdCBjb21wbGV4aXR5IG1heSBub3QgYmUgZ29vZCBmb3IgdGhlIG1v c3QgY29uc3RyYWluZWQgZGV2aWNlcyB0aG91Z2guDQoNClBlcmhhcHMgdGhlIG1vc3Qgc2ltcGxl IHRoaW5nIHdvdWxkIGJlIHRvIGJlIGFibGUgdG8gZGVmaW5lIGFyYml0cmFyeSBudW1iZXIgb2Yg KHN0cmluZz8pIGtleS12YWx1ZSBwYWlycywgbGlrZSBpbiBxdWVyeSBwYXJhbWV0ZXJzLCBhbmQg aGF2ZSByZXNvdXJjZSBzcGVjaWZpYyBzZW1hbnRpY3MgZm9yIHRob3NlLiANCg0KSSB0aGluayBD YXJzdGVuIGhhcyBhIHZhbGlkIHBvaW50IHRoYXQgdGhlc2Ugc2hvdWxkIGJlIGRyaXZlbiBieSBy ZWFsIGN1c3RvbWVycywgYnV0IGlmIHdlIGRvbid0IGhhdmUgeWV0IGFueSB1c2VyIGZvciB0aGlz IG1lY2hhbmlzbSBkZWZpbmVkLCB3aHkgYXJlIHdlIGluIGEgaHVycnkgdG8gZ2V0IGl0IGZpbmFs aXplZD8NCg0KPj4gU2VjdGlvbiAyOg0KPj4+IFRoZSBwYXlsb2FkIHJldHVybmVkIGluIHJlc3Bv bnNlIHRvIGEgRkVUQ0ggY2Fubm90IGJlIGFzc3VtZWQgdG8gYmUgYSBjb21wbGV0ZSByZXByZXNl bnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgZWZmZWN0aXZlIHJlcXVl c3QgVVJJLg0KPj4gQ2FuJ3QgSSB1c2UgRkVUQ0ggdG8gcHJvZHVjZSBzYW1lIHJlc3VsdCBhcyBH RVQ/IEV2ZW4gaWYgSSB1c2UgaXQNCj4+IHdpdGhvdXQgYW55IGFkZGl0aW9uYWwgcmVxdWVzdCBw YXJhbWV0ZXJzPw0KPiANCj4gRGVwZW5kcyBvbiBtZWRpYSB0eXBlLCBidXQgYnkgdXNpbmcgYW4g YXJyYXkgb2Ygb25lIEpTT04gaWRlbnRpZmllciwgSSB3b3VsZCBzYXkgeWVzLg0KDQpPciB3b3Vs ZCB0aGF0IGJlIHplcm8gaWRlbnRpZmllcnM/IEFueXdheSwgbWF5YmUgaGVyZSB5b3UgY291bGQg Y2xhcmlmeSB0aGF0IHRoZSByZWFzb24gZm9yIGFib3ZlIGlzIHRoYXQgbWVkaWEgdHlwZSBhbmQg dGhlIHBheWxvYWQgb2YgcmVxdWVzdCBpbXBhY3QgdGhlIHJlc3BvbnNlLCBhbmQgaGVuY2Ugb25l IGNhbm5vdCBhc3N1bWUgYW55dGhpbmcgYmFzZWQgb24gdGhlIFVSSSBhbG9uZS4NCg0KDQpDaGVl cnMsDQpBcmkNCg0KUC5TLiBJIHJlbW92ZWQgcGFydHMgb2YgdGhlIHRocmVhZCB0aGF0IHdlcmUg Y2xlYXIgYWxyZWFkeQ== From nobody Thu Jul 14 05:01:08 2016 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 EB33612D799 for ; Thu, 14 Jul 2016 05:01:06 -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 z_h4_sDtv2wE for ; Thu, 14 Jul 2016 05:01:05 -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 F375512D796 for ; Thu, 14 Jul 2016 05:01:04 -0700 (PDT) Received: from mfilter41-d.gandi.net (mfilter41-d.gandi.net [217.70.178.173]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4A4471720C8; Thu, 14 Jul 2016 14:01:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter41-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter41-d.gandi.net (mfilter41-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EoQ9VwA9XMhQ; Thu, 14 Jul 2016 14:01:01 +0200 (CEST) X-Originating-IP: 109.45.0.68 Received: from nar-3.local (ip-109-45-0-68.web.vodafone.de [109.45.0.68]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A471A1720D6; Thu, 14 Jul 2016 14:00:59 +0200 (CEST) Message-ID: <57877EFA.7080503@tzi.org> Date: Thu, 14 Jul 2016 14:00:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core , "draft-ietf-core-etch@tools.ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 12:01:07 -0000 Ari Keränen wrote: > I think Carsten has a valid point that these should be driven by real customers, but if we don't have yet any user for this mechanism defined, why are we in a hurry to get it finalized? As I said, the first customer is COMI. They can of course work around the lack of FETCH by coming up with some horrible base64-encoded Uri-Query parameter encoding hack or some such, and will probably do this if FETCH does not go through. The IETF has a long history of inappropriately intermingling the timelines of unrelated drafts. RFC 7252 (CoAP) is a great example: Its publication had to wait for an extra year to go through because of some petty squabble in the security area about documents that we somehow didn't prevent from becoming normative references. I will never knowingly contribute to repeating that kind of mistake again. Keep dependencies simple. Grüße, Carsten From nobody Thu Jul 14 06:43:46 2016 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 0095212D128; Thu, 14 Jul 2016 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klvNKPkYgN7j; Thu, 14 Jul 2016 06:43:39 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 1A72E12D10B; Thu, 14 Jul 2016 06:43:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,362,1464645600"; d="scan'208,217";a="226719268" Received: from mail-lf0-f51.google.com ([209.85.215.51]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 14 Jul 2016 15:43:35 +0200 Received: by mail-lf0-f51.google.com with SMTP id b199so64332846lfe.0; Thu, 14 Jul 2016 06:43:35 -0700 (PDT) X-Gm-Message-State: ALyK8tLjetIjQNFOKHsI1bc2fSEEiTxKkQ2bdsHDWiueESUORHQJaPNxOPLYKVpIMhFEKuR+r+SqBOS/EF+Aww== X-Received: by 10.46.5.213 with SMTP id 204mr6956284ljf.64.1468503815362; Thu, 14 Jul 2016 06:43:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Thu, 14 Jul 2016 06:43:15 -0700 (PDT) From: Thomas Watteyne Date: Thu, 14 Jul 2016 15:43:15 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, core , IETF ROLL , cose@ietf.org, lwig@ietf.org, lp-wan@ietf.org, "iot-dir@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "t2trg@irtf.org" Content-Type: multipart/alternative; boundary=001a114a683e44263e053798b068 Archived-At: Subject: [core] F-Interop info session @IETF96 - Monday 8.30-9-30pm - Charlottenburg I X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 13:43:42 -0000 --001a114a683e44263e053798b068 Content-Type: text/plain; charset=UTF-8 All, We are organizing an information meeting about F-Interop, an online platform for remote interoperability testing, IETF96 Monday 8.30-9.30pm, in Charlottenburg I. F-Interop (www.f-interop.eu) is a platform for online and remote conformance and interoperability testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN, CoAP, RPL, ...) The purpose of this info session is to give you a technical overview of the platform, describe how the IETF community can use and contribute to it, and get feedback. The platform is built as part of the 2016-2018 F-Interop H2020 European project. As part of that project, we will have an open call for entities to contribute additional tools and test descriptions to the platform. Selected projects will be funded; we will explain the process during the info session as well. Looking forward to seeing you there, Thomas --001a114a683e44263e053798b068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

We are organizing an in= formation meeting about F-Interop, an online platform for remote interopera= bility testing, IETF96 Monday 8.30-9.30pm, in Charlottenburg I.
<= br>
F-Interop (www.f-interop.= eu) is a platform for online and remote conformance and interoperabilit= y testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN, CoAP, RPL, .= ..)

The purpose of this info session is to give yo= u a technical overview of the platform, describe how the IETF community can= use and contribute to it, and get feedback.

The p= latform is built as part of the 2016-2018 F-Interop H2020 European project.= As part of that project, we will have an open call for entities to contrib= ute additional tools and test descriptions to the platform. Selected projec= ts will be funded; we will explain the process during the info session as w= ell.

Looking forward to seeing you there,

Thomas
--001a114a683e44263e053798b068-- From nobody Thu Jul 14 08:19:40 2016 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 8827B12D7EA for ; Thu, 14 Jul 2016 08:19:38 -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 VSylR0C9ZhoV for ; Thu, 14 Jul 2016 08:19:36 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646FF12D7DA for ; Thu, 14 Jul 2016 08:19:36 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id JfKZ1t0034WfiVN01fKZff; Thu, 14 Jul 2016 17:19:33 +0200 Received: from 2001:983:a264:1:4563:dcea:23df:e56a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 17:19:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 14 Jul 2016 17:19:33 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57877EFA.7080503@tzi.org> References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> <57877EFA.7080503@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (uZvfSoBnTGpG2HXaNsHQGRnNVItz38Jv) User-Agent: XS4ALL Webmail Archived-At: Cc: core , draft-ietf-core-etch@tools.ietf.org Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:19:38 -0000 Carsten Bormann schreef op 2016-07-14 14:00: > Ari Keränen wrote: >> I think Carsten has a valid point that these should be driven by real >> customers, but if we don't have yet any user for this mechanism >> defined, why are we in a hurry to get it finalized? > > As I said, the first customer is COMI. They can of course work around > the lack of FETCH by coming up with some horrible base64-encoded > Uri-Query parameter encoding hack or some such, and will probably do > this if FETCH does not go through. > As one of the authors of CoMI I like to confirm that we have taken pains to get the FETCH part of this draft of the ground. Greetings, Peter From nobody Thu Jul 14 08:28:05 2016 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 3498C12D7EF for ; Thu, 14 Jul 2016 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 YXSda41MONJM for ; Thu, 14 Jul 2016 08:28:03 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F6E12D685 for ; Thu, 14 Jul 2016 08:28:02 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id JfU01t00n4WfiVN01fU019; Thu, 14 Jul 2016 17:28:01 +0200 Received: from 2001:983:a264:1:4563:dcea:23df:e56a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 17:28:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Jul 2016 17:28:00 +0200 From: peter van der Stok To: =?UTF-8?Q?Ari_Ker=C3=A4nen?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> Message-ID: X-Sender: stokcons@xs4all.nl (Pp8R1TPfb9aiR8JoycM4YxbJKWBVO91V) User-Agent: XS4ALL Webmail Archived-At: Cc: core , draft-ietf-core-etch@tools.ietf.org Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:28:04 -0000 What do the >>> implementations use? I'm thinking that something like xpath >>> (/jsonpath?) media type would be easy to define. >> >> An array of JSON identifiers looks reasonable. Is it your suggestion >> to define that in this draft? > > What would be the semantics of that array? "Give only these > key-value-pairs"? How would that work with nested structures and > arrays? > > The xpath and jsonpath media types could do that and much more. Some > of that complexity may not be good for the most constrained devices > though. > In CoMI we will define an array of YANG identifiers. I can imagine that this is confirmed (extended) in a later content format draft. PS. For the other point I refer to Carsten's e-mails. Peter From nobody Thu Jul 14 08:39:54 2016 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 7714D12D0F9 for ; Thu, 14 Jul 2016 08:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 3hB8hKWc1QiY for ; Thu, 14 Jul 2016 08:39:51 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806BE12D0BB for ; Thu, 14 Jul 2016 08:39:51 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id Jffp1t00Y4WfiVN01ffpkS; Thu, 14 Jul 2016 17:39:50 +0200 Received: from 2001:983:a264:1:4563:dcea:23df:e56a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 17:39:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Jul 2016 17:39:49 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <43805298839959a534d83c720ac6239c@xs4all.nl> Message-ID: <8a6ece7e540f02c064c8d638b2d83463@xs4all.nl> X-Sender: stokcons@xs4all.nl (tESzVuV9u4rSpl/inKNdSKHHp//Qa6k6) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:39:53 -0000 Hi Michel, > In this case, you propose to add more meta data than > "draft-ietf-netmod-yang-json" > which don't share the same limitations on the payload size. > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 I don't think extra meta-data is needed (depending on your definition of meta-data) > > Regards, > Michel Greetings, Peter > > > -----Original Message----- > > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Thursday, July 14, 2016 3:57 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 > > Hi Michel, > > IMO, an error is an error and should be treated as such. Trying to > salvage unhealthy situations leads to worse problems. > > My approach would be that servers and clients are simple and don't > need to parse the yang modules during operation; and keep extensive > state information about each other. > > The discussion seems to confirm my growing conviction that the CoMI > and CoOL approaches are fundamentally different. > > Peter > > Michel Veillette schreef op 2016-07-13 19:06: >> Hi Peter >> >> I'm not convinced that Including in the encoding which data nodes are >> the keys completely solve the issue. >> If the client transmit a payload with one key and the server required >> two keys, the payload will be rejected. >> If the client transmit a payload with two keys (marked as such) and >> the server require one key, the payload will be rejected. >> To work, both sides need to known the number of keys used by the other >> side and only 'ietf-cool-library' can resolve that. >> >> Also, not making which data nodes are keys might help during the >> migration. >> >> Regards, >> Michel >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Wednesday, July 13, 2016 12:55 PM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >> >> Hi Michel, >> >> That looks pretty complex to me; while the keys can be elegantly >> expressed in the CBOR contents. >> >> Peter >> >> Michel Veillette schreef op 2016-07-13 16:36: >>> Hi Peter >>> >>> The scenario you described is part of the generic discovery problem. >>> To perform its tasks, clients typically need to known the list of >>> modules, features, deviations implemented by a server and associated >>> versions. >>> This problem is addressed in >>> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library- >>> l >>> atest.html >>> which is the constrained version of >>> https://datatracker.ietf.org/doc/rfc7895/ >>> >>> module: ietf-cool-library >>> +--ro modules-state >>> +--ro module-set-id union >>> +--ro module* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> +--ro feature* sid >>> +--ro deviation* [sid revision] >>> | +--ro sid sid >>> | +--ro revision revision >>> +--ro conformance-type enumeration >>> +--ro submodules >>> +--ro submodule* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> notifications: >>> +---n yang-library-change >>> +--ro module-set-id -> /modules-state/module-set-id >>> >>> Regards >>> Michel >>> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Wednesday, July 13, 2016 2:34 AM >>> To: Michel Veillette >>> Cc: consultancy@vanderstok.org; Core >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>> >>> Hi Michel, >>> >>> When a specification changes it set of of keys, I don't think the >>> SIDs will change. >>> It is for sure that the hashes are not affected by the attribution of >>> a key. >>> >>> Therefore, what happens when client and server use different keys in >>> otherwise identical list specification? >>> >>> Peter >>> >>> Michel Veillette schreef op 2016-07-12 17:07: >>>> Hi Peter >>>> >>>> The validations performed by the entity which de-serialize the CBOR >>>> payload is based on the YANG schema. >>>> This validation is based on all king of YANG statements such as: >>>> key, unique, range, pattern, length, min-elements, max-elements, >>>> must, when, if-feature >>>> >>>> The identification of which data nodes are keys is considered >>>> unnecessary meta-data since available in the schema. >>>> Even more heavy weight representations such as xml and json don't >>>> include this meta-data in the encode payload. >>>> >>>> Regards, >>>> Michel >>>> >>>> -----Original Message----- >>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>> Sent: Tuesday, July 12, 2016 6:08 AM >>>> To: Michel Veillette >>>> Cc: consultancy@vanderstok.org; Core >>>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>> >>>> Hi Michel, >>>> >>>>> >>>>> However, I am missing how to transport a given list instance with >>>>> its key values in the CBOR encoding. Section 4.4 describes the >>>>> encoding of a complete list not a subset of its instances. >>>>> >>>>> [MV] A list instance is a collection which is described in section >>>>> 4.2. >>>>> ___________________________________________________________________ >>>>> _ >>>>> _ >>>>> _ >>>>> _______________________ >>>> >>>> With the current text I don't see how you distinguish instances with >>>> the same key from instances with different keys. >>>> >>>> Example: >>>> >>>> list server { >>>> key name; >>>> >>>> leaf name { >>>> type string; >>>> } >>>> leaf iburst { >>>> type boolean; >>>> default false; >>>> } >>>> >>>> How to distinguish that in the list below that two instances are >>>> identical (should not occur) >>>> [ >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : false, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] >>>> >>>> And the following two instances are different (valid array) >>>> >>>> [ >>>> { >>>> 1755 : "NRC TAC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] From nobody Thu Jul 14 08:46:32 2016 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 9A70E12D53C for ; Thu, 14 Jul 2016 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 IuSXz2TDiSJ0 for ; Thu, 14 Jul 2016 08:46:29 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAC312D0F9 for ; Thu, 14 Jul 2016 08:46:28 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id JfmT1t0064WfiVN01fmTh4; Thu, 14 Jul 2016 17:46:27 +0200 Received: from 2001:983:a264:1:4563:dcea:23df:e56a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 17:46:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 14 Jul 2016 17:46:27 +0200 From: peter van der Stok To: Alexander Pelov Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <9409ECE5-77DF-481B-B2C6-0BA6337EA60A@ackl.io> References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <43805298839959a534d83c720ac6239c@xs4all.nl> <9409ECE5-77DF-481B-B2C6-0BA6337EA60A@ackl.io> Message-ID: X-Sender: stokcons@xs4all.nl (bEWbkZcd82ri5/BfpqhBlNlD5zqTlk7E) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:46:30 -0000 Alexander Pelov schreef op 2016-07-14 10:39: > Dear Peter, > > I agree with you - if a server expects TWO keys, but receives ONE this > is an error. What I don’t understand is how marking the CBOR content > changes anything to this. (if the client insists that a leaf is a key > and the server disagrees - then you have error. if the server requires > a key and the client does not provide it - stil an error). > > From implementation point of view, the server will never recompile the > YANG module. YANG is used compile-time (when you generate your program > on your laptop) and as a contract between the client and the server. > The same goes for constrained clients. > > In most cases, the server and the client will actually not need to > have the YANG module scheme at all - only a couple of SIDs, associated > meta-data (in binary - such as the type) and the associated functions > (which you need anyways). As SIDs never change, you don’t need > anything else on the device. It could be even simpler - without the > meta-data - but then the associated functions need to do the > validation (e.g. Arduino implementations). > > Alexander Hi Alexander, absolutely agree with you in the above. The need to identify keys and to distinguish different instances is needed when you want to "replace" (same key values) or "add" (different key values) individual instances to a list. I try to argue that you want that express this in the payload because you cannot count on server and client to have the same view on the key set. Peter From nobody Thu Jul 14 09:13:44 2016 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 8DF4112D0AD for ; Thu, 14 Jul 2016 09:13: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 PDVqS2Z4M9w3 for ; Thu, 14 Jul 2016 09:13:40 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE28F12D0E9 for ; Thu, 14 Jul 2016 09:13:39 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u6EGDa0m004238 for ; Thu, 14 Jul 2016 18:13:37 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D763B1D53C1; Thu, 14 Jul 2016 18:13:36 +0200 (CEST) Received: from 131.111.5.144 by webmail.entel.upc.edu with HTTP; Thu, 14 Jul 2016 18:14:23 +0200 Message-ID: Date: Thu, 14 Jul 2016 18:14:23 +0200 From: "Carles Gomez Montenegro" To: core@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Thu, 14 Jul 2016 18:13:37 +0200 (CEST) Archived-At: Subject: [core] CoCoA and Aggregate Congestion Control [Fwd: New Version Notification for draft-bormann-core-cocoa-04.txt] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 16:13:42 -0000 Dear CoRE WG list members, We submitted revision -04 of draft-bormann-core-cocoa, as you can see below. On Thursday next week, in Berlin, we will present the latest draft updates and results, and will ask for WG adoption of the draft. As the meeting agenda is quite compressed, we would like to achieve some progress already on the list, in particular, regarding Aggregate Congestion Control (ACC). ACC is currently included in the CoCoA draft as an appendix. While CoCoA is intended to be generally applicable, ACC is more interesting on the cloud side, where a single CoAP endpoint may need to talk to thousands of other endpoints and may need to control the burstiness of the resulting aggregate traffic. We would like to ask the WG opinion about which is the best place for ACC: - Is ACC a feature that you would like to see in this draft? - Should ACC be pushed to a new draft? Your comments will be very helpful to make a decision in this regard. Thank you in advance! Cheers, Carles ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-bormann-core-cocoa-04.txt From: internet-drafts@ietf.org Date: Fri, July 8, 2016 9:08 pm To: "August Betzler" "Carsten Bormann" "Carles Gomez" "Dr. Carsten Bormann" "Ilker Demirkol" -------------------------------------------------------------------------- A new version of I-D, draft-bormann-core-cocoa-04.txt has been successfully submitted by Carsten Bormann and posted to the IETF repository. Name: draft-bormann-core-cocoa Revision: 04 Title: CoAP Simple Congestion Control/Advanced Document date: 2016-07-08 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-bormann-core-cocoa-04.txt Status: https://datatracker.ietf.org/doc/draft-bormann-core-cocoa/ Htmlized: https://tools.ietf.org/html/draft-bormann-core-cocoa-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-bormann-core-cocoa-04 Abstract: The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. It is making use of input from simulations and experiments in real networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jul 15 03:23:48 2016 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 978B812DD0D for ; Fri, 15 Jul 2016 03:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY7mEHRAhA_p for ; Fri, 15 Jul 2016 03:23:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3658112DC29 for ; Fri, 15 Jul 2016 03:23:45 -0700 (PDT) Received: from localhost ([::1]:51081 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bO0HK-00081g-01; Fri, 15 Jul 2016 03:23:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-interfaces@tools.ietf.org, lauri.piikivi@arm.com X-Trac-Project: core Date: Fri, 15 Jul 2016 10:23:29 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/415 Message-ID: <061.bb9885835d474fbcc690496598378041@trac.tools.ietf.org> X-Trac-Ticket-ID: 415 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-interfaces@tools.ietf.org, lauri.piikivi@arm.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-interfaces@ietf.org Resent-Message-Id: <20160715102345.3658112DC29@ietfa.amsl.com> Resent-Date: Fri, 15 Jul 2016 03:23:45 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #415 (interfaces): Linked Batched post usage, persistency and version need for interfaces X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 10:23:47 -0000 #415: Linked Batched post usage, persistency and version need for interfaces Hi, Reading the draft, some comments below. == POST usage == In chapter 5.3 for the linked batch, POST is used as modification and creation of the list. POST is usually understood as creation (for CRUD operations). We have PATCH for modify operation. I recommend to use PATCH for modification operations. - POST creates - PUT replaces - PATCH modifies (appends) - DELETE removes == Linked Batch as persistent resource or transient configuration == There may be servers that create a persistent linked batch. They should be able to return the location, the new resource, to client. Even for transient (RAM storage linked batch), location usage could clarify the situations with server reset. The server is often in an embedded, maybe wireless, device and reset operations are common. If a linked batch is created, and server resets, a modification later on can actually be a creation operation, especially if POST is used for both creation and modification. Server should return a new resource id in location header for linked batch creation. Later operations use that resource URI for modifications and delete. If the resource is lost (RAM reset), a not found error is returned. It may be not too far in future that an embedded server has different linked batch for different clients. Persistent linked batch is reported to the RD or client well-known query as a resource in the server. Should we have different interface type or identification for persistent linked batch? == Interface Version == The chapter on function set (ch 6) talks about the need for versioning. It is not clear to me how the version would work? Do we need version in the interface information? Web/REST apis are truly fast evolving, and a version information might be needed for a client to understand what version of an interface is in use. The version information might be in the interface name (v1, v2 in the end) or in link parameter even? If linked batch returns a new resource, should we have the version information as link parameter? Creation makes version 1, modifications increase the version number? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- lauri.piikivi@arm.com | interfaces@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: interfaces | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 15 06:45:49 2016 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 7CC7F12D7BB for ; Fri, 15 Jul 2016 06:45:47 -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 rR0xMd0jIuTU for ; Fri, 15 Jul 2016 06:45:46 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C4412D7B6 for ; Fri, 15 Jul 2016 06:45:45 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-e7-5788e907f7a7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.F8.27088.709E8875; Fri, 15 Jul 2016 15:45:43 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.140]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0294.000; Fri, 15 Jul 2016 15:45:42 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Carsten Bormann , "consultancy@vanderstok.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtY29yZS1l?= =?utf-8?Q?tch-01?= Thread-Index: AQHR0JnQdP6iR0Z21EyknS8RGJOeqaAWMHsAgAAQ1oCAAYXPAIAABOgAgAGvl4A= Date: Fri, 15 Jul 2016 13:45:42 +0000 Message-ID: References: <6292828E-BF6C-456B-82A5-6B86C120D013@ericsson.com> <81E0417A-71AC-4783-8D81-1B1C4111222D@ericsson.com> <57877EFA.7080503@tzi.org> In-Reply-To: <57877EFA.7080503@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <1F92C67921B67C4D8317EB34205B2B82@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7ri77y45wgwWX1SyOTLnLavFo/yo2 i31v1zNbrF3i7cDisWTJTyaPL5c/s3lMW5TpcaJhO3sASxSXTUpqTmZZapG+XQJXRue+9ywF u3gq7sxbwtTAOIGni5GTQ0LAROLb54msELaYxIV769m6GLk4hASOMEqs7tjJCuEsYZSY1d/P CFLFJmAr8aR1H1iHiEC8xPs511lAbGaBdImTHYvB4sICWRKXdnxjgajJljg4ZT07hO0n8a/p DxOIzSKgKrHq7G6wOK+AvcSjvnlQm78zSnTt2gPWzCmgLnF3+kewoYxA530/tYYJYpm4xK0n 85kgzhaQWLLnPDOELSrx8vE/qHeUJBqXPAGyOYDqNSXW79KHaLWWWHDrHxuErSgxpfsh1A2C EidnPmGZwCg+C8mGWQjds5B0z0LSPQtJ9wJG1lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsY gTF5cMtvgx2ML587HmIU4GBU4uFVuNweLsSaWFZcmXuIUYKDWUmE98vTjnAh3pTEyqrUovz4 otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjJP+fSnlmJfDvs+6RiLs5+Je 4azNKZoZTbZWd9sPXdc89odpsonlb4vU94ffXwgxrvRrCDFTZJ+61f951AZRlyf/2FMi1dOs lqdn6O13Z+IUv2OtmLhg9cv9r87Pv7tUrCM0d/vem9uv6V16FrMu9fXNyyuNN99vPrry6MEL KfuvToreMmfC1YNKLMUZiYZazEXFiQAWwi1YxQIAAA== Archived-At: Cc: "draft-ietf-core-etch@tools.ietf.org" , core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-etc?= =?utf-8?q?h-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jul 2016 13:45:47 -0000 DQo+IE9uIDE0IEp1bCAyMDE2LCBhdCAxNDowMCwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5v cmc+IHdyb3RlOg0KPiANCj4gQXJpIEtlcsOkbmVuIHdyb3RlOg0KPj4gSSB0aGluayBDYXJzdGVu IGhhcyBhIHZhbGlkIHBvaW50IHRoYXQgdGhlc2Ugc2hvdWxkIGJlIGRyaXZlbiBieSByZWFsIGN1 c3RvbWVycywgYnV0IGlmIHdlIGRvbid0IGhhdmUgeWV0IGFueSB1c2VyIGZvciB0aGlzIG1lY2hh bmlzbSBkZWZpbmVkLCB3aHkgYXJlIHdlIGluIGEgaHVycnkgdG8gZ2V0IGl0IGZpbmFsaXplZD8N Cj4gDQo+IEFzIEkgc2FpZCwgdGhlIGZpcnN0IGN1c3RvbWVyIGlzIENPTUkuICBUaGV5IGNhbiBv ZiBjb3Vyc2Ugd29yayBhcm91bmQNCj4gdGhlIGxhY2sgb2YgRkVUQ0ggYnkgY29taW5nIHVwIHdp dGggc29tZSBob3JyaWJsZSBiYXNlNjQtZW5jb2RlZA0KPiBVcmktUXVlcnkgcGFyYW1ldGVyIGVu Y29kaW5nIGhhY2sgb3Igc29tZSBzdWNoLCBhbmQgd2lsbCBwcm9iYWJseSBkbw0KPiB0aGlzIGlm IEZFVENIIGRvZXMgbm90IGdvIHRocm91Z2guDQo+IA0KPiBUaGUgSUVURiBoYXMgYSBsb25nIGhp c3Rvcnkgb2YgaW5hcHByb3ByaWF0ZWx5IGludGVybWluZ2xpbmcgdGhlDQo+IHRpbWVsaW5lcyBv ZiB1bnJlbGF0ZWQgZHJhZnRzLiAgUkZDIDcyNTIgKENvQVApIGlzIGEgZ3JlYXQgZXhhbXBsZTog SXRzDQo+IHB1YmxpY2F0aW9uIGhhZCB0byB3YWl0IGZvciBhbiBleHRyYSB5ZWFyIHRvIGdvIHRo cm91Z2ggYmVjYXVzZSBvZiBzb21lDQo+IHBldHR5IHNxdWFiYmxlIGluIHRoZSBzZWN1cml0eSBh cmVhIGFib3V0IGRvY3VtZW50cyB0aGF0IHdlIHNvbWVob3cNCj4gZGlkbid0IHByZXZlbnQgZnJv bSBiZWNvbWluZyBub3JtYXRpdmUgcmVmZXJlbmNlcy4NCj4gDQo+IEkgd2lsbCBuZXZlciBrbm93 aW5nbHkgY29udHJpYnV0ZSB0byByZXBlYXRpbmcgdGhhdCBraW5kIG9mIG1pc3Rha2UgYWdhaW4u DQo+IEtlZXAgZGVwZW5kZW5jaWVzIHNpbXBsZS4NCg0KSSBhZ3JlZSB0aGVyZSdzIGJpdCBvZiBh IGNoaWNrZW4tZWdnIHByb2JsZW0gaGVyZS4gQ29uc2lkZXJpbmcgdGhhdCBDb01JIGhhcyBhbHJl YWR5IHN0dWZmIGNvbWluZyBmb3IgdGhpcywgZ2V0dGluZyB0aGlzIGRvbmUgbWFrZXMgc2Vuc2Uu DQoNCg0KQ2hlZXJzLA0KQXJpDQoNCg== From nobody Fri Jul 15 11:27:31 2016 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 EA68812D107 for ; Fri, 15 Jul 2016 11:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 8xl7PLFGktIv for ; Fri, 15 Jul 2016 11:27:28 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0121.outbound.protection.outlook.com [104.47.32.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D82512B04F for ; Fri, 15 Jul 2016 11:27: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=MMIiyUetEsG9bjNYSo+nJOzTC4g3F5KmIqIKX9RM4VA=; b=iRaTws4b2/t+9v1XiTp9YNO7YFPo8NGWazoxGVV/82d+vb6cNniIr9Ah+/Xm2ZhiMGbnymC4azfWFxcsuPUuLeUtkVyDmGTujd2YVam2sckZ3gUK312+7+b9u16U5sXDh1kknNoghcbsnSa+CxbHN+HG0AdyrycEp+xOs6kZkyM= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Fri, 15 Jul 2016 18:27:25 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Fri, 15 Jul 2016 18:27:25 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYCugCAAFEisIABBZSAgACEZ/CAACjkgIAAAPZAgAD7JwCAADlmwIAAR/CAgAG5FcA= Date: Fri, 15 Jul 2016 18:27:25 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <43805298839959a534d83c720ac6239c@xs4all.nl> <8a6ece7e540f02c064c8d638b2d83463@xs4all.nl> In-Reply-To: <8a6ece7e540f02c064c8d638b2d83463@xs4all.nl> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 1f8f1529-cc59-4b3f-84b9-08d3acddab8f x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:Hy7wpdW38zGwc7qPupFv3hIYvKgQ5tDh/vhL3nf/FBbFj8i33JQIVxJAozn4AD7BPTSRRV0PByYb+R3v9O9O3W7FotfcDSsFyEQdvc7h0ou7wv6ib2Gs6N1XZ90qbiGklopxlUfq9SDJc1RcZdXXWKaUdv+Yjyk1na7Gjc3NppGHFsBrHY42xDrJNibKJLgfw2Tua4F/LGUowhsZ4ubZllN7UPOM7TvI740OXrZoUvnKBxFC7RnilmFlchq8eph05ord5G218aO5gCiGw/OVyNTewWaKpdQ2esk82KJXLl4=; 5:DzHLH5Qch0RJXlVHOg5UKf8f3UjGjoUcAcaHmx0bOIQiG+mDUMzZDSO2sTOpcoPcM3naKuRi7ES55DW1wKdmsExki/uoi0HQ7aVTdBWrxoV1dyKXPsvh3VtHwpTCvHuYZX8tiIdnqRjRmD3EAduuew==; 24:bFXL4ecLTP64kTlAYDDRwYdifaKfpBJiI2GBE2QXJEYl+HvhUjI4RErYbMUetD7S9fmsHr5/YZQoalBwYsZ3eLqrpbTsXWyPWAd2a6Vn5mc=; 7:rQjxEw7lhMBslRR9baLmXWfcApgVWH71moZa5pyGF44Qn/ceCc2z2TeN6Y6qiP8nnmoM5iKUvZNkcBmocEdQodUGcqOfiRzZQKFURqg3LjbTQKzM29+CNm3GLkog7Me2jAnO1+0XvKKAJi5QCmH3iHX/bfLKjd5wxvjkimOgLY2zYyuroqHHaAH7uyA5I2C/alY1FCmtnu/8ibW1k3jdAJzUuDhQFhClpwXyNEdzyfzELZBKCA5alA7Rj0xuH5Fc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(377454003)(377424004)(101416001)(3846002)(15975445007)(4326007)(99286002)(2900100001)(19580395003)(586003)(102836003)(2950100001)(122556002)(305945005)(5002640100001)(6116002)(19580405001)(2501003)(2351001)(76176999)(3280700002)(106356001)(9686002)(2906002)(1720100001)(54356999)(106116001)(5640700001)(92566002)(77096005)(76576001)(3660700001)(7696003)(66066001)(93886004)(81166006)(7846002)(33656002)(10400500002)(8936002)(105586002)(86362001)(11100500001)(1730700003)(87936001)(8676002)(74316002)(50986999)(68736007)(81156014)(5003600100003)(97736004)(110136002)(7736002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.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: 15 Jul 2016 18:27:25.4390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jul 2016 18:27:31 -0000 Hi Peter "Meta data" is defined as "data that provides information about other data" The identification of which data nodes are listed in the 'key' YANG statem= ent is information about the data transferred, not the data itself. So yes, extra meta-date is required if we want to identify the list of key(= s) in the encoded payload. Updating the list of keys is not something typical and if done, I assume t= hat the interactions between clients and servers change significantly. I st= ill believe that the discovery process is the most appropriate and generic = way to address these types of problems. Regards, -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Thursday, July 14, 2016 11:40 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] YANG to CBOR mapping version 1 Hi Michel, > In this case, you propose to add more meta data than=20 > "draft-ietf-netmod-yang-json" > which don't share the same limitations on the payload size. > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 I don't think extra meta-data is needed (depending on your definition of meta-data) >=20 > Regards, > Michel Greetings, Peter >=20 >=20 > -----Original Message----- >=20 > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Thursday, July 14, 2016 3:57 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 >=20 > Hi Michel, >=20 > IMO, an error is an error and should be treated as such. Trying to=20 > salvage unhealthy situations leads to worse problems. >=20 > My approach would be that servers and clients are simple and don't=20 > need to parse the yang modules during operation; and keep extensive=20 > state information about each other. >=20 > The discussion seems to confirm my growing conviction that the CoMI=20 > and CoOL approaches are fundamentally different. >=20 > Peter >=20 > Michel Veillette schreef op 2016-07-13 19:06: >> Hi Peter >>=20 >> I'm not convinced that Including in the encoding which data nodes are=20 >> the keys completely solve the issue. >> If the client transmit a payload with one key and the server required=20 >> two keys, the payload will be rejected. >> If the client transmit a payload with two keys (marked as such) and=20 >> the server require one key, the payload will be rejected. >> To work, both sides need to known the number of keys used by the=20 >> other side and only 'ietf-cool-library' can resolve that. >>=20 >> Also, not making which data nodes are keys might help during the=20 >> migration. >>=20 >> Regards, >> Michel >>=20 >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Wednesday, July 13, 2016 12:55 PM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >>=20 >> Hi Michel, >>=20 >> That looks pretty complex to me; while the keys can be elegantly=20 >> expressed in the CBOR contents. >>=20 >> Peter >>=20 >> Michel Veillette schreef op 2016-07-13 16:36: >>> Hi Peter >>>=20 >>> The scenario you described is part of the generic discovery problem. >>> To perform its tasks, clients typically need to known the list of=20 >>> modules, features, deviations implemented by a server and associated=20 >>> versions. >>> This problem is addressed in >>> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library >>> - >>> l >>> atest.html >>> which is the constrained version of >>> https://datatracker.ietf.org/doc/rfc7895/ >>>=20 >>> module: ietf-cool-library >>> +--ro modules-state >>> +--ro module-set-id union >>> +--ro module* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> +--ro feature* sid >>> +--ro deviation* [sid revision] >>> | +--ro sid sid >>> | +--ro revision revision >>> +--ro conformance-type enumeration >>> +--ro submodules >>> +--ro submodule* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> notifications: >>> +---n yang-library-change >>> +--ro module-set-id -> /modules-state/module-set-id >>>=20 >>> Regards >>> Michel >>>=20 >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Wednesday, July 13, 2016 2:34 AM >>> To: Michel Veillette >>> Cc: consultancy@vanderstok.org; Core >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>=20 >>> Hi Michel, >>>=20 >>> When a specification changes it set of of keys, I don't think the=20 >>> SIDs will change. >>> It is for sure that the hashes are not affected by the attribution=20 >>> of a key. >>>=20 >>> Therefore, what happens when client and server use different keys in=20 >>> otherwise identical list specification? >>>=20 >>> Peter >>>=20 >>> Michel Veillette schreef op 2016-07-12 17:07: >>>> Hi Peter >>>>=20 >>>> The validations performed by the entity which de-serialize the CBOR=20 >>>> payload is based on the YANG schema. >>>> This validation is based on all king of YANG statements such as: >>>> key, unique, range, pattern, length, min-elements, max-elements,=20 >>>> must, when, if-feature >>>>=20 >>>> The identification of which data nodes are keys is considered=20 >>>> unnecessary meta-data since available in the schema. >>>> Even more heavy weight representations such as xml and json don't=20 >>>> include this meta-data in the encode payload. >>>>=20 >>>> Regards, >>>> Michel >>>>=20 >>>> -----Original Message----- >>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>> Sent: Tuesday, July 12, 2016 6:08 AM >>>> To: Michel Veillette >>>> Cc: consultancy@vanderstok.org; Core >>>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>>=20 >>>> Hi Michel, >>>>=20 >>>>>=20 >>>>> However, I am missing how to transport a given list instance with=20 >>>>> its key values in the CBOR encoding. Section 4.4 describes the=20 >>>>> encoding of a complete list not a subset of its instances. >>>>>=20 >>>>> [MV] A list instance is a collection which is described in section=20 >>>>> 4.2. >>>>> __________________________________________________________________ >>>>> _ >>>>> _ >>>>> _ >>>>> _ >>>>> _______________________ >>>>=20 >>>> With the current text I don't see how you distinguish instances=20 >>>> with the same key from instances with different keys. >>>>=20 >>>> Example: >>>>=20 >>>> list server { >>>> key name; >>>>=20 >>>> leaf name { >>>> type string; >>>> } >>>> leaf iburst { >>>> type boolean; >>>> default false; >>>> } >>>>=20 >>>> How to distinguish that in the list below that two instances are=20 >>>> identical (should not occur) >>>> [ >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : false, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] >>>>=20 >>>> And the following two instances are different (valid array) >>>>=20 >>>> [ >>>> { >>>> 1755 : "NRC TAC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] From nobody Fri Jul 15 13:04:21 2016 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 390B612DDB1 for ; Fri, 15 Jul 2016 13:04:18 -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 9hEd5SeABTxO for ; Fri, 15 Jul 2016 13:04:15 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A63012DDAA for ; Fri, 15 Jul 2016 13:04: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=3nNx1BK2ftmUrcWWWlKQxOOUydh6C3oTuUVm07Rx1F8=; b=OtCpr7z0ruN0gO4F/KDZh0jM0QwKfukBoblgnT2nrSISGpKLvx7EUqndRLMZYLG0C5/3ijYy3xTKfhgQNtWoWpJdSU3QHtsa8JaBlW2eKSnRW1VIlXUt9IiliKJnhoQM9zCWBD3J2F/ULAc/G04TaSuZi81CApPrnM6QMpYshyc= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Fri, 15 Jul 2016 20:04:04 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Fri, 15 Jul 2016 20:04:04 +0000 From: Michel Veillette To: Alexander Pelov Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYAFQCAAAGjAIAAD30AgAAvp4CAABES0IAAFf2AgAT4ItA= Date: Fri, 15 Jul 2016 20:04:04 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: c1e99d29-1f31-4d8d-afc1-08d3aceb2bff x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:6bqjlb2s+9zZjlB5tI41PHwDFci2bEGWBDsIHuObzyCR45IEjEscx3DscyraeXUyij0AJtHb6em74wTU9msNYv+jeIJ9a6zorMoE4KddV2/EPHXnyFwfDSYjGMEQckClRmhIPeZclp/xyr9dMbYIl1lAhvpWp6+OvsPTG9D+uwoXef5Jik0bMJnPdEkWdYOhUn/wIEw3EO5bxIe6ksPXmLudYJ4oUCvhLYNiGNYAaubqIcns1iDdVXfQp6luX6NlJsDacBUxdv5eOHGAnuzy3ef8+CifsX7LMw6oDsEHitU=; 5:lkHqg4tosunRzNuH5au9vbb7FEy+pvCq0BGL3ooaojDHPHCzy5iYEakLnha5RjPTXOTb7zIGJcQvtI9Fb+90/hQdZgnyyLI+74INoFYwDDwrmlAvlEdWFruDiz/YNPMjyNoIBcMrRdsSguQl8CB07Q==; 24:CyQhSuQUG+69srWyxQuTrrZRElj+501GgWX6bsnAFBhWhNXjK+0xnM5h4v2D0vbCJ01jheFvPfdAYqQDb4PpY/ldWxzck1XG9fYupvkhtaA=; 7:N5wQJXfhP+MGnS3grqFB+35k5NatTOOJyNrNB27wiHeBwEibCvFLkgrIN6NorpGjUQa3dz+CtWzm8iNNIZMFA+bENAOWeNBRT9FWgY2BGD1pkyTZi1OmB8sSFXL/2xwZ4AipE5/i33cBFJm20A6HTRzIR7Rts+GNQYrV9q1eYOyIargRj4iz24N/6/8Kw8qAylBwA23zgoPweRSHEtVTLBXq5LcbkHBH9+Ocnj/96LaQDffSR8EcwmNn0Bp2DWQN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(51444003)(24454002)(199003)(10400500002)(7846002)(33656002)(16236675004)(87936001)(8676002)(8936002)(105586002)(86362001)(11100500001)(66066001)(7696003)(93886004)(81166006)(110136002)(7736002)(189998001)(97736004)(81156014)(5003600100003)(19609705001)(50986999)(790700001)(74316002)(68736007)(19580395003)(19580405001)(7906003)(6116002)(5002640100001)(76176999)(15975445007)(99286002)(101416001)(3846002)(19625215002)(102836003)(2950100001)(122556002)(2900100001)(586003)(4326007)(77096005)(92566002)(54356999)(106116001)(19617315012)(19300405004)(76576001)(3660700001)(3280700002)(106356001)(9686002)(2906002)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.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: multipart/alternative; boundary="_000_BLUPR06MB1763100454D0C9CC0AB37353FE330BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2016 20:04:04.2148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jul 2016 20:04:18 -0000 --_000_BLUPR06MB1763100454D0C9CC0AB37353FE330BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleGFuZGVyDQoNClRvIHNpbXBsaWZ5IHRoZSBpbXBsZW1lbnRhdGlvbiwgSSdsbCBwcmVm ZXIgdG8ga2VlcCB0aGUgc2FtZSByZXByZXNlbnRhdGlvbiBmb3IgZGVjaW1hbDY0IHdpdGhpbiBv ciB3aXRob3V0IGEgdW5pb24gKDIuNTcgb3IgMjU3KQ0KV2Ugc2ltcGx5IG5lZWQgdG8gc2VsZWN0 IG9uZS4NCkknbSBmaW5kIHdpdGggZWl0aGVyIG9uZXMgYnV0IExQV0FOIGltcGxlbWVudGVycyBt aWdodCBwcmVmZXIgdGhlIENCT1IgdW5zaWduZWQgaW50ZWdlciByZXByZXNlbnRhdGlvbi4NCg0K UmVnYXJkcywNCk1pY2hlbA0KDQpGcm9tOiBBbGV4YW5kZXIgUGVsb3YgW21haWx0bzphQGFja2wu aW9dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDEyLCAyMDE2IDEyOjEwIFBNDQpUbzogTWljaGVsIFZl aWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPg0KQ2M6IENhcnN0ZW4g Qm9ybWFubiA8Y2Fib0B0emkub3JnPjsgQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbY29yZV0gWUFORyB0byBDQk9SIG1hcHBpbmcgdmVyc2lvbiAxDQoNCkhpIE1pY2hlbCwNCg0K SWYgdGhlcmUgaXMgYSB3YXkgdG8gdW5hbWJpZ3VvdXNseSBkaWZmZXJlbnRpYXRlIGJldHdlZW4g dW5pb24gYW5kIG5vbi11bmlvbiwgdGhlbiB3ZSBzaG91bGQgdXNlIHRoZSBtb3N0IGVmZmljaWVu dCByZXByZXNlbnRhdGlvbi4gSG93ZXZlciwgSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB5b3Ug Y2FuIG1vZGlmeSBsb2NhbGx5IGEgbW9kdWxlLCB3aGljaCBjb3VsZCBjaGFuZ2UgdGhlIHR5cGUg b2YgYSBsZWFmIGZyb20gZGVjaW1hbCB0byB1bmlvbi4uIHdoaWNoIGNvdWxkIHRoZW4gbGVhZCB0 byBjb25mdXNpb24uDQoNCk9uZSBvZiB0aGUgbWFpbiBpc3N1ZXMgd2XigJlyZSBoYXZpbmcgaXMg dGhlIHBvc3NpYmxlIG1pc21hdGNoIGJldHdlZW4gdGhlIG1vZHVsZSB2ZXJzaW9ucyBvbiBhIHNl cnZlciBhbmQgYSBjbGllbnQuIEhvdyBhYm91dCB0aGlzIC0NCjEpIHdlIGRlZmluZSBhIChsaWdo dHdlaWdodCkgbWVjaGFuaXNtIGZvciBlbnN1cmluZyB0aGUgbWF0Y2hpbmcgb2YgdGhlIG1vZHVs ZSB2ZXJzaW9ucw0KMikgaWYgbWF0Y2hpbmcsIHRoZW4gdXNlIG1vc3QgZWZmaWNpZW50IHJlcHJl c2VudGF0aW9uIChlLmcuIGVuY29kZSAyLjU3IGFzIDI1NykNCjMpIGlmIG5vdCBtYXRjaGluZywg dGhlbiB1c2UgdGFncyBmb3IgYWxsIHJlcHJlc2VudGF0aW9ucw0KDQpIb3cgZG9lcyB0aGlzIHNv dW5kPw0KDQpBbGV4YW5kZXINCg0KDQpMZSAxMiBqdWlsLiAyMDE2IMOgIDE2OjU3LCBNaWNoZWwg VmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hl bC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT4+IGEgw6ljcml0IDoNCg0KSGkgQWxleGFuZGVy DQoNCkkgd2FudCB0byBiZSBzdXJlIG9mIHlvdXIgYW5zd2VyLg0KVGhlIENCT1IgdGFnIDQgKERl Y2ltYWwgZnJhY3Rpb24pIHJlcXVpcmUgMyBieXRlcyBvZiBvdmVyaGVhZCwgc2VlIGV4YW1wbGUg Zm9yIFJGQyA4MDQ5IHNlY3Rpb24gMi40LjMgYmVsbG93Lg0KVGhpcyBpcyB0aGUgdGFnIHlvdSBh cmUgcHJvcG9zaW5nPw0KVGhpcyB0YWcgd2lsbCBiZSB1c2VkIGFsbCB0aGUgdGltZSAod2l0aGlu IHRoZSBjb250ZXh0IG9mIGEgdW5pb24gYW5kIHdpdGhvdXQpPw0KDQpDNCAgICAgICAgICAgICAj IFRhZyA0DQogIDgyICAgICAgICAgICAjIEFycmF5IG9mIGxlbmd0aCAyDQogICAgMjEgICAgICAg ICAjIC0yDQogICAgMTkgMDEwMSAgICAjIHVuc2lnbmVkKDI1NykNCg0KUmVnYXJkcywNCk1pY2hl bA0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxleGFuZGVyIFBlbG92DQpTZW50OiBUdWVzZGF5LCBKdWx5IDEyLCAyMDE2IDk6NTAgQU0N ClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4N CkNjOiBDb3JlIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbY29yZV0gWUFORyB0byBDQk9SIG1hcHBpbmcgdmVyc2lvbiAxDQoNCkhpIENhcnN0ZW4s DQoNClllcywgeW91IGFyZSByaWdodC4gSSB0aG91Z2h0IHRoYXQgd2UgY291bGQga2VlcCB0aGlz IHJlcHJlc2VudGF0aW9uIG91dHNpZGUgb2YgdW5pb25zLiBCdXQgb2YgY291cnNlLCB3ZSBuZWVk IHRvIGJhbGFuY2UgdGhlIGNvbXBsZXhpdHkgb2YgZG9pbmcgdGhpcy4NCg0KVGhlcmUgY291bGQg YmUgYSBjb25mdXNpb24gaWYgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCBoYXZlIGRpZmZlcmVu dCB2ZXJzaW9ucyBvZiB0aGUgc2FtZSBtb2R1bGUgKHJhcmUsIGJ1dCBtdXN0IGJlIHRha2VuIGNh cmUgb2YpLiBXaGljaCBpcyBvZiBjb3Vyc2UsIHRoZSB0aGluZyB3ZeKAmXZlIGFsd2F5cyB0cmll ZCB0byBhdm9pZC4uIFNvIHllYWgsIGZvciB0aGUgbW9tZW50IHdlIGNvdWxkIGtlZXAgdGhlIENC T1IgZGVjaW1hbCB0YWcuDQoNCkJlc3QsDQpBbGV4YW5kZXINCg0KTGUgMTIganVpbC4gMjAxNiDD oCAxMjo1OSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9y Zz4+IGEgw6ljcml0IDoNCg0KSGkgQWxleGFuZGVyLA0KDQpUaGlzIGlzIHJpZ2h0LiBIb3dldmVy LCBJIHRob3VnaHQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiBvZiB1bmlvbnMgd2UgaGFkIGFycml2 ZWQgYXQgZW5jb2RpbmcgZGVjaW1hbHMgYXMgQ0JPUiBkZWNpbWFsIGZyYWN0aW9uIHRhZ3MuIEJ1 dCBtYXliZSBJJ20gbWlzcmVtZW1iZXJpbmcuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KT24gMTIg SnVsIDIwMTYgMTI6MDQsIEFsZXhhbmRlciBQZWxvdiB3cm90ZToNCkRlYXIgUGV0ZXIsDQoNCklu IHRoaXMgY2FzZSB5b3UgY2FuIGluZmVyIHRoZSBkZWNpbWFsIHBvaW50IHBvc2l0aW9uIGZyb20g dGhlIFlBTkcgZGVmaW5pdGlvbiwgZS5nLiB0aGUgc3RhdGVtZW50ICJmcmFjdGlvbi1kaWdpdHMg MjsiDQoNCldoaWNoIGluZGljYXRlcyB0aGF0IDI1NyByZXByZXNlbnRzIHRoZSBudW1iZXIgMi41 Ny4gMiByZXByZXNlbnRzIDAuMDIsIDUwIHJlcHJlc2VudHMgMC41MCwgMTAwMCByZXByZXNlbnRz IDEwLjAwDQoNCkkgdGhpbmsgdGhhdCB5b3UgYXJlIHJpZ2h0IHRoYXQgd2Ugc2hvdWxkIHByb3Zp ZGUgbW9yZSBleGFtcGxlcyB0byBiZSBjbGVhciBvbiB0aGlzIHBvaW50Lg0KDQpCZXN0LA0KQWxl eGFuZGVyDQoNCg0KTGUgMTIganVpbC4gMjAxNiDDoCAxMTo1OCwgcGV0ZXIgdmFuIGRlciBTdG9r IDxzdG9rY29uc0B4czRhbGwubmw8bWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubD4+IGEgw6ljcml0 IDoNCg0KSGkgTWljaGVsLA0KDQpJIHNlcGFyYXRlZCBteSBhbnN3ZXIgaW50byB0aHJlZSBwYXJ0 cyB0byBzaW1wbGlmeSB0aGUgZGlzY3Vzc2lvbi4NCg0KDQoNClNlY3Rpb24gNS4zOw0KSW4gdGhl IGV4YW1wbGUsIHdoZXJlIGRvIEkgZmluZCBpbiB0aGUgQ0JPUiBlbmNvZGluZyB0aGF0IHRoZSBm cmFjdGlvbg0KaXMgMiBkaWdpdHM/DQpbTVZdIFRoZSBudW1iZXIgb2YgZGlnaXRzIGlzIG5vdCBl bmNvZGVkLiBUaGlzIGluZm9ybWF0aW9uIGlzDQpjb25zaWRlcmVkIGFuIHVubmVjZXNzYXJ5IG1l dGFkYXRhDQpbTVZdIHNpbWlsYXIgdG8gInVuaXRzIiwgdGV4dCBvZiBhbiBlbnVtZXJhdGlvbiwg bmFtZSBvZiBhIGZsYWcgd2l0aGluDQpiaXRzLiBUaGlzIHdhcyB0aGUgY29uc2Vuc3VzDQpbTVZd IG9mIHRoZSBncm91cCB3aGljaCBpcyBhbGlnbmVkIHdpdGggdGhlIHN0YXRlbWVudCBpbiBzZWN0 aW9uIDMgKEluDQpvcmRlciB0byBtaW5pbWl6ZSB0aGUgc2l6ZSBvZg0KW01WXSB0aGUgZW5jb2Rl ZCBkYXRhLCB0aGUgcHJvcG9zZWQgbWFwcGluZyBhdm9pZCBhbnkgdW5uZWNlc3NhcnkNCm1ldGEt aW5mb3JtYXRpb24gYmV5b25kDQpbTVZdIHRob3NlIG5hdGl2ZWx5IHN1cHBvcnRlZCBieSBDQk9S LikNCltNVl0gSXQgbWlnaHQgYmUgd29ydGggaXQgdG8gcmFpc2UgdGhpcyB0b3BpYyB3aXRoaW4g YSBsYXJnZXIgYXVkaWVuY2UuDQoNClRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyB0aGUgZW5j b2Rpbmcgb2YgbGVhZiAnbXktZGVjaW1hbCcgc2V0IHRvDQoyLjU3Lg0KDQpEZWZpbml0aW9uIGV4 YW1wbGUgZnJvbSBbUkZDNzMxN106DQoNCmxlYWYgbXktZGVjaW1hbCB7DQp0eXBlIGRlY2ltYWw2 NCB7DQpmcmFjdGlvbi1kaWdpdHMgMjsNCnJhbmdlICIxIC4uIDMuMTQgfCAxMCB8IDIwLi5tYXgi Ow0KfQ0KfQ0KDQpDQk9SIGRpYWdub3N0aWMgbm90YXRpb246IDI1Nw0KDQo8cHZkcz4NClNob3Vs ZCBpdCBub3QgYmUgcG9pbnRlZCBvdXQgbW9yZSBzdHJvbmdseSB0aGF0IHRoZSB5YW5nIHRvIGNi b3IgY29udmVyc2lvbiBmYWlscyBpbiB0aGlzIGNhc2U/DQpJIGRvbid0IHNlZSBob3cgYSBjaGFu Z2UgZnJvbSAyLjU3IG9yIDI1NyByZXByZXNlbnRzIGxvb3NpbmcgdW5uZWNlc3NhcnkgbWV0YSBp bmZvcm1hdGlvbi4NClVubGVzcyBJIGNvbXBsZXRlbHkgbWlzcyB0aGUgcG9pbnQgb2YgdGhlIGV4 YW1wbGUuDQo8L3B2ZHM+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWls aW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K --_000_BLUPR06MB1763100454D0C9CC0AB37353FE330BLUPR06MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQWxleGFuZGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG8gc2ltcGxpZnkgdGhlIGltcGxlbWVu dGF0aW9uLCBJJ2xsIHByZWZlciB0byBrZWVwIHRoZSBzYW1lIHJlcHJlc2VudGF0aW9uIGZvciBk ZWNpbWFsNjQgd2l0aGluIG9yIHdpdGhvdXQgYSB1bmlvbiAoPC9zcGFuPjIuNTcgb3IgMjU3KTxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlIHNpbXBseSBu ZWVkIHRvIHNlbGVjdCBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSdtIGZpbmQgd2l0aCBlaXRoZXIg b25lcyBidXQgTFBXQU4gaW1wbGVtZW50ZXJzIG1pZ2h0IHByZWZlciB0aGUgQ0JPUiB1bnNpZ25l ZCBpbnRlZ2VyIHJlcHJlc2VudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWljaGVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFsZXhhbmRlciBQZWxvdiBbbWFpbHRvOmFAYWNr bC5pb10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDEyLCAyMDE2IDEyOjEwIFBN PGJyPg0KPGI+VG86PC9iPiBNaWNoZWwgVmVpbGxldHRlICZsdDtNaWNoZWwuVmVpbGxldHRlQHRy aWxsaWFudGluYy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDYXJzdGVuIEJvcm1hbm4gJmx0O2Nh Ym9AdHppLm9yZyZndDs7IENvcmUgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbY29yZV0gWUFORyB0byBDQk9SIG1hcHBpbmcgdmVyc2lvbiAxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWljaGVsLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUgaXMgYSB3YXkg dG8gdW5hbWJpZ3VvdXNseSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdW5pb24gYW5kIG5vbi11bmlv biwgdGhlbiB3ZSBzaG91bGQgdXNlIHRoZSBtb3N0IGVmZmljaWVudCByZXByZXNlbnRhdGlvbi4g SG93ZXZlciwgSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB5b3UgY2FuIG1vZGlmeSBsb2NhbGx5 IGEgbW9kdWxlLCB3aGljaCBjb3VsZCBjaGFuZ2UgdGhlIHR5cGUgb2YgYSBsZWFmDQogZnJvbSBk ZWNpbWFsIHRvIHVuaW9uLi4gd2hpY2ggY291bGQgdGhlbiBsZWFkIHRvIGNvbmZ1c2lvbi4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T25lIG9mIHRoZSBtYWluIGlzc3VlcyB3ZeKAmXJlIGhhdmluZyBpcyB0aGUgcG9zc2libGUgbWlz bWF0Y2ggYmV0d2VlbiB0aGUgbW9kdWxlIHZlcnNpb25zIG9uIGEgc2VydmVyIGFuZCBhIGNsaWVu dC4gSG93IGFib3V0IHRoaXMgLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgd2UgZGVmaW5lIGEgKGxpZ2h0d2VpZ2h0KSBtZWNoYW5p c20gZm9yIGVuc3VyaW5nIHRoZSBtYXRjaGluZyBvZiB0aGUgbW9kdWxlIHZlcnNpb25zPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBpZiBtYXRj aGluZywgdGhlbiB1c2UgbW9zdCBlZmZpY2llbnQgcmVwcmVzZW50YXRpb24gKGUuZy4gZW5jb2Rl IDIuNTcgYXMgMjU3KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MykgaWYgbm90IG1hdGNoaW5nLCB0aGVuIHVzZSB0YWdzIGZvciBhbGwgcmVwcmVz ZW50YXRpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhvdyBkb2VzIHRoaXMgc291bmQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsZXhhbmRlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAxMiBqdWlsLiAyMDE2 IMOgIDE2OjU3LCBNaWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZl aWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tIj5NaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5j b208L2E+Jmd0OyBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBBbGV4YW5kZXI8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JIHdhbnQgdG8gYmUgc3VyZSBvZiB5b3VyIGFuc3dlci48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgQ0JPUjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj50YWcgNCAoRGVjaW1h bCBmcmFjdGlvbikgcmVxdWlyZSAzIGJ5dGVzDQogb2Ygb3ZlcmhlYWQsIHNlZSBleGFtcGxlIGZv ciBSRkMgODA0OSBzZWN0aW9uIDIuNC4zIGJlbGxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMg aXMgdGhlIHRhZyB5b3UgYXJlIHByb3Bvc2luZz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgdGFn IHdpbGwgYmUgdXNlZCBhbGwgdGhlIHRpbWUgKHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIHVuaW9u IGFuZCB3aXRob3V0KT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5DNCAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsjIFRhZyA0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q291cmllciI+Jm5ic3A7IDgyICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgQXJyYXkgb2YgbGVuZ3RoIDI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsm bmJzcDsgMjEgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IyAtMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIi PiZuYnNwOyZuYnNwOyZuYnNwOyAxOSAwMTAxICZuYnNwOyZuYnNwOyZuYnNwOyMgdW5zaWduZWQo MjU3KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+TWljaGVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmNvcmUNCiBbPGEgaHJlZj0i bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkFsZXhhbmRlciBQZWxv djxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5UdWVzZGF5LCBKdWx5IDEyLCAyMDE2IDk6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhcnN0ZW4g Qm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+Y2Fib0B0emkub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Db3JlICZsdDs8 YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ Y29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW2NvcmVdIFlBTkcg dG8gQ0JPUiBtYXBwaW5nIHZlcnNpb24gMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENhcnN0ZW4s PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHlvdSBhcmUgcmlnaHQuIEkgdGhvdWdodCB0aGF0IHdl IGNvdWxkIGtlZXAgdGhpcyByZXByZXNlbnRhdGlvbiBvdXRzaWRlIG9mIHVuaW9ucy4gQnV0IG9m IGNvdXJzZSwgd2UgbmVlZCB0byBiYWxhbmNlIHRoZSBjb21wbGV4aXR5IG9mIGRvaW5nIHRoaXMu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGNvdWxkIGJlIGEgY29uZnVz aW9uIGlmIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgaGF2ZSBkaWZmZXJlbnQgdmVyc2lvbnMg b2YgdGhlIHNhbWUgbW9kdWxlIChyYXJlLCBidXQgbXVzdCBiZSB0YWtlbiBjYXJlIG9mKS4gV2hp Y2ggaXMgb2YgY291cnNlLCB0aGUgdGhpbmcgd2XigJl2ZSBhbHdheXMgdHJpZWQgdG8gYXZvaWQu LiBTbyB5ZWFoLCBmb3IgdGhlIG1vbWVudCB3ZSBjb3VsZCBrZWVwIHRoZQ0KIENCT1IgZGVjaW1h bCB0YWcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bGV4YW5kZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDEyIGp1aWwuIDIwMTYgw6Ag MTI6NTksIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2Fib0B0emkub3JnPC9zcGFuPjwvYT4mZ3Q7IGEg w6ljcml0IDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGV4YW5kZXIsPGJyPg0KPGJy Pg0KVGhpcyBpcyByaWdodC4gSG93ZXZlciwgSSB0aG91Z2h0IHRoYXQgaW4gdGhlIGRpc2N1c3Np b24gb2YgdW5pb25zIHdlIGhhZCBhcnJpdmVkIGF0IGVuY29kaW5nIGRlY2ltYWxzIGFzIENCT1Ig ZGVjaW1hbCBmcmFjdGlvbiB0YWdzLiBCdXQgbWF5YmUgSSdtIG1pc3JlbWVtYmVyaW5nLjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpH csO8w59lLCBDYXJzdGVuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDEyIEp1bCAy MDE2IDEyOjA0LCBBbGV4YW5kZXIgUGVsb3Ygd3JvdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5EZWFyIFBldGVyLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQo8YnI+DQpJbiB0aGlzIGNhc2UgeW91IGNhbiBpbmZlciB0aGUgZGVjaW1hbCBw b2ludCBwb3NpdGlvbiBmcm9tIHRoZSBZQU5HIGRlZmluaXRpb24sIGUuZy4gdGhlIHN0YXRlbWVu dCAmcXVvdDtmcmFjdGlvbi1kaWdpdHMgMjsmcXVvdDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KV2hpY2ggaW5kaWNhdGVzIHRoYXQg MjU3IHJlcHJlc2VudHMgdGhlIG51bWJlciAyLjU3LiAyIHJlcHJlc2VudHMgMC4wMiwgNTAgcmVw cmVzZW50cyAwLjUwLCAxMDAwIHJlcHJlc2VudHMgMTAuMDA8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IHlvdSBh cmUgcmlnaHQgdGhhdCB3ZSBzaG91bGQgcHJvdmlkZSBtb3JlIGV4YW1wbGVzIHRvIGJlIGNsZWFy IG9uIHRoaXMgcG9pbnQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxicj4NCkJlc3QsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCkFsZXhhbmRlcjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDEyIGp1aWwuIDIwMTYgw6AgMTE6NTgs IHBldGVyIHZhbiBkZXIgU3RvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0b2tjb25zQHhzNGFsbC5u bCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c3Rva2NvbnNAeHM0YWxsLm5sPC9zcGFuPjwv YT4mZ3Q7IGEgw6ljcml0IDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGJyPg0KSGkgTWljaGVsLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpJIHNlcGFyYXRlZCBteSBhbnN3ZXIg aW50byB0aHJlZSBwYXJ0cyB0byBzaW1wbGlmeSB0aGUgZGlzY3Vzc2lvbi48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNlY3Rpb24gNS4zOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQpJbiB0aGUgZXhhbXBsZSwgd2hlcmUgZG8gSSBmaW5kIGluIHRoZSBDQk9SIGVu Y29kaW5nIHRoYXQgdGhlIGZyYWN0aW9uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCmlzIDIgZGlnaXRzPzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpbTVZdIFRoZSBudW1iZXIgb2YgZGlnaXRz IGlzIG5vdCBlbmNvZGVkLiBUaGlzIGluZm9ybWF0aW9uIGlzPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCmNvbnNpZGVyZWQgYW4gdW5uZWNlc3Nh cnkgbWV0YWRhdGE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KW01WXSBzaW1pbGFyIHRvICZxdW90O3VuaXRzJnF1b3Q7LCB0ZXh0IG9mIGFuIGVu dW1lcmF0aW9uLCBuYW1lIG9mIGEgZmxhZyB3aXRoaW48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KYml0cy4gVGhpcyB3YXMgdGhlIGNvbnNlbnN1 czxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpb TVZdIG9mIHRoZSBncm91cCB3aGljaCBpcyBhbGlnbmVkIHdpdGggdGhlIHN0YXRlbWVudCBpbiBz ZWN0aW9uIDMgKEluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCm9yZGVyIHRvIG1pbmltaXplIHRoZSBzaXplIG9mPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCltNVl0gdGhlIGVuY29kZWQgZGF0 YSwgdGhlIHByb3Bvc2VkIG1hcHBpbmcgYXZvaWQgYW55IHVubmVjZXNzYXJ5PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCm1ldGEtaW5mb3JtYXRp b24gYmV5b25kPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4NCltNVl0gdGhvc2UgbmF0aXZlbHkgc3VwcG9ydGVkIGJ5IENCT1IuKTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpbTVZdIEl0IG1pZ2h0 IGJlIHdvcnRoIGl0IHRvIHJhaXNlIHRoaXMgdG9waWMgd2l0aGluIGEgbGFyZ2VyIGF1ZGllbmNl LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NClRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyB0aGUgZW5jb2Rpbmcgb2YgbGVh ZiAnbXktZGVjaW1hbCcgc2V0IHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjIuNTcuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCkRlZmluaXRpb24gZXhhbXBsZSBmcm9tIFtSRkM3 MzE3XTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KPGJyPg0KbGVhZiBteS1kZWNpbWFsIHs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KdHlwZSBkZWNpbWFsNjQgezxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpmcmFjdGlvbi1kaWdpdHMgMjs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KcmFu Z2UgJnF1b3Q7MSAuLiAzLjE0IHwgMTAgfCAyMC4ubWF4JnF1b3Q7OzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQp9PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCn08c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KQ0JPUiBkaWFnbm9zdGlj IG5vdGF0aW9uOiAyNTc8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KPGJyPg0KJmx0O3B2ZHMmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClNob3VsZCBpdCBub3QgYmUgcG9pbnRlZCBvdXQg bW9yZSBzdHJvbmdseSB0aGF0IHRoZSB5YW5nIHRvIGNib3IgY29udmVyc2lvbiBmYWlscyBpbiB0 aGlzIGNhc2U/PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4NCkkgZG9uJ3Qgc2VlIGhvdyBhIGNoYW5nZSBmcm9tIDIuNTcgb3IgMjU3IHJlcHJlc2Vu dHMgbG9vc2luZyB1bm5lY2Vzc2FyeSBtZXRhIGluZm9ybWF0aW9uLjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpVbmxlc3MgSSBjb21wbGV0ZWx5 IG1pc3MgdGhlIHBvaW50IG9mIHRoZSBleGFtcGxlLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombHQ7L3B2ZHMmZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCmNvcmUgbWFpbGluZyBsaXN0PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxhIGhyZWY9 Im1haWx0bzpjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jb3JlQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCmNvcmUgbWFpbGluZyBsaXN0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5jb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR06MB1763100454D0C9CC0AB37353FE330BLUPR06MB1763namp_-- From nobody Fri Jul 15 13:15:38 2016 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 A790812D0F6 for ; Fri, 15 Jul 2016 13:15:36 -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 fgas1IzpVc8s for ; Fri, 15 Jul 2016 13:15:34 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 C825D12D528 for ; Fri, 15 Jul 2016 13:15:33 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id w127so111577315vkh.2 for ; Fri, 15 Jul 2016 13:15:33 -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=qPtztnST7KsFyMMKyDDLAcTPOZyhkj0h2Qw60PVHf0I=; b=vulamBF8gNaupkzjjY7QdDDKHl9b7+uugciyjb/X/WmJBSSBTXKWfEtWyvFOk15c79 A3ZXVY5eHzcU2S0+eanaDtv3Q+3pAcSB756KtvxykSg1gBYfDeaQxlFvMqW239n+fvjn q67M2L0LuqlD+f8GHPM5aISt6Fry5N5JdwjZr9rw83NHrfAs7KXIG9cnoj3RtHGYEkNP VM4E30DjgIXdOltHVkuI+FNqk8Iv8X8fdFf1cU0puDajW13jaiLcfNveUbj4enqLU0vS ZoSn5Ph9/cVEh/GFD/Bnpc/04CLdqwYeS5OR233hDj6mXeLKe+x85CHLxgaAr2opXQVO 9Zuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qPtztnST7KsFyMMKyDDLAcTPOZyhkj0h2Qw60PVHf0I=; b=CJjOnUZHpfQdCMdFnUd7Kf2RxD09Yw2BBS+dJf2psuJYFG9l9VxRdM/AHUzV9hick/ FlxVZWHRjjmuGmdocXzs7jXkCDWDpa08HKiP2WeDGjU0cKIXMuznPuUCKpZiqI8guZC3 PDpe4IvZJCVeVwKhyMgqzTa5RUQrnaW1IO3w7zoMMVcJlG7NvrYf3UAeBdnsuEAi11OS Z6QlYx/adpCQjQ3nr6DfgUayWnXXspdrGHs/UgR9NakO0CPydWDg8X5EwJhI4TpbbO3e budAJjO0nrX+joBb6uWKGPyvngYxzaTvhIz1kopLtmu6UijsgymRoDJAFx0947Slzjkb g2GQ== X-Gm-Message-State: ALyK8tKNruxgTSP7F9r5rsdNah0xriT/4bgQ1ZFpGQ/0u7R2N/1PZrHmWNqvvC1YXmN9qM7648j8GJc+Pl0HyQ== X-Received: by 10.31.4.4 with SMTP id 4mr11830427vke.121.1468613732808; Fri, 15 Jul 2016 13:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 15 Jul 2016 13:15:30 -0700 (PDT) In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> From: Andy Bierman Date: Fri, 15 Jul 2016 13:15:30 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=001a114298c8db519e0537b2473e Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jul 2016 20:15:36 -0000 --001a114298c8db519e0537b2473e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2016 at 1:04 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Alexander > > > > To simplify the implementation, I'll prefer to keep the same > representation for decimal64 within or without a union (2.57 or 257) > > We simply need to select one. > > I'm find with either ones but LPWAN implementers might prefer the CBOR > unsigned integer representation. > > > So how is this union supported with the 2nd option? 2.57 seems the obvious choice if robustness is a concern. leaf foo { type union { type decimal64 { fraction-digits 2; } type decimal64 { fraction-digits 4; } } } Regards, > > Michel > Andy > > > *From:* Alexander Pelov [mailto:a@ackl.io] > *Sent:* Tuesday, July 12, 2016 12:10 PM > *To:* Michel Veillette > *Cc:* Carsten Bormann ; Core > *Subject:* Re: [core] YANG to CBOR mapping version 1 > > > > Hi Michel, > > > > If there is a way to unambiguously differentiate between union and > non-union, then we should use the most efficient representation. However,= I > get the impression that you can modify locally a module, which could chan= ge > the type of a leaf from decimal to union.. which could then lead to > confusion. > > > > One of the main issues we=E2=80=99re having is the possible mismatch betw= een the > module versions on a server and a client. How about this - > > 1) we define a (lightweight) mechanism for ensuring the matching of the > module versions > > 2) if matching, then use most efficient representation (e.g. encode 2.57 > as 257) > > 3) if not matching, then use tags for all representations > > > > How does this sound? > > > > Alexander > > > > > > Le 12 juil. 2016 =C3=A0 16:57, Michel Veillette < > Michel.Veillette@trilliantinc.com> a =C3=A9crit : > > > > Hi Alexander > > > > I want to be sure of your answer. > > The CBOR tag 4 (Decimal fraction) require 3 bytes of overhead, see > example for RFC 8049 section 2.4.3 bellow. > > This is the tag you are proposing? > > This tag will be used all the time (within the context of a union and > without)? > > > > C4 # Tag 4 > > 82 # Array of length 2 > > 21 # -2 > > 19 0101 # unsigned(257) > > > > Regards, > > Michel > > > > *From:* core [mailto:core-bounces@ietf.org ] *On > Behalf Of *Alexander Pelov > *Sent:* Tuesday, July 12, 2016 9:50 AM > *To:* Carsten Bormann > *Cc:* Core > *Subject:* Re: [core] YANG to CBOR mapping version 1 > > > > Hi Carsten, > > > > Yes, you are right. I thought that we could keep this representation > outside of unions. But of course, we need to balance the complexity of > doing this. > > > > There could be a confusion if the server and the client have different > versions of the same module (rare, but must be taken care of). Which is o= f > course, the thing we=E2=80=99ve always tried to avoid.. So yeah, for the = moment we > could keep the CBOR decimal tag. > > > > Best, > > Alexander > > > > Le 12 juil. 2016 =C3=A0 12:59, Carsten Bormann a =C3=A9cri= t : > > > > Hi Alexander, > > This is right. However, I thought that in the discussion of unions we had > arrived at encoding decimals as CBOR decimal fraction tags. But maybe I'm > misremembering. > > Gr=C3=BC=C3=9Fe, Carsten > > > On 12 Jul 2016 12:04, Alexander Pelov wrote: > > Dear Peter, > > In this case you can infer the decimal point position from the YANG > definition, e.g. the statement "fraction-digits 2;" > > Which indicates that 257 represents the number 2.57. 2 represents 0.02, 5= 0 > represents 0.50, 1000 represents 10.00 > > I think that you are right that we should provide more examples to be > clear on this point. > > Best, > Alexander > > > Le 12 juil. 2016 =C3=A0 11:58, peter van der Stok a = =C3=A9crit > : > > Hi Michel, > > I separated my answer into three parts to simplify the discussion. > > > > Section 5.3; > In the example, where do I find in the CBOR encoding that the fraction > is 2 digits? > [MV] The number of digits is not encoded. This information is > considered an unnecessary metadata > [MV] similar to "units", text of an enumeration, name of a flag within > bits. This was the consensus > [MV] of the group which is aligned with the statement in section 3 (In > order to minimize the size of > [MV] the encoded data, the proposed mapping avoid any unnecessary > meta-information beyond > [MV] those natively supported by CBOR.) > [MV] It might be worth it to raise this topic within a larger audience. > > > The following example shows the encoding of leaf 'my-decimal' set to > 2.57. > > Definition example from [RFC7317]: > > leaf my-decimal { > type decimal64 { > fraction-digits 2; > range "1 .. 3.14 | 10 | 20..max"; > } > } > > CBOR diagnostic notation: 257 > > > Should it not be pointed out more strongly that the yang to cbor > conversion fails in this case? > I don't see how a change from 2.57 or 257 represents loosing unnecessary > meta information. > Unless I completely miss the point of the example. > > > _______________________________________________ > 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 > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a114298c8db519e0537b2473e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 15, 2016 at 1:04 PM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:

Hi Alexander

=C2=A0

To simplify the implementation, I'll prefer to= keep the same representation for decimal64 within or without a union (2.57 or 257)

We simply need to select one.=

I'm find with either ones but LPWAN implemente= rs might prefer the CBOR unsigned integer representation.

=C2=A0

<= div>

So how is this union supported with the 2= nd option?
2.57 seems the obvious choice if robustness is a conce= rn.


=C2=A0 =C2=A0leaf foo {
=C2=A0 =C2=A0 =C2=A0 type union {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0type decimal64 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0fraction-digits 2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type decimal64 {=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fraction-digi= ts 4;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0= =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}


=

Regards,

Michel

Andy
=C2=A0

=C2=A0

From: Alexander Pelov [mailto:a@ackl.io]
Sent: Tuesday, July 12, 2016 12:10 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Carsten Bormann <cabo@tzi.org>; Core <core@ietf.org>
Subject: Re: [core] YANG to CBOR mapping version 1

=C2=A0

Hi Michel,

=C2=A0

If there is a way to unambiguously differentiate bet= ween union and non-union, then we should use the most efficient representat= ion. However, I get the impression that you can modify locally a module, wh= ich could change the type of a leaf from decimal to union.. which could then lead to confusion.=C2=A0

=C2=A0

One of the main issues we=E2=80=99re having is the p= ossible mismatch between the module versions on a server and a client. How = about this -=C2=A0

1) we define a (lightweight) mechanism for ensuring = the matching of the module versions

2) if matching, then use most efficient representati= on (e.g. encode 2.57 as 257)

3) if not matching, then use tags for all representa= tions

=C2=A0

How does this sound?=C2=A0

=C2=A0

Alexander

=C2=A0

=C2=A0

Le 12 juil. 2016 =C3=A0 16:57, Michel Veillette <= Mich= el.Veillette@trilliantinc.com> a =C3=A9crit :

=C2=A0

Hi Alexander

=C2=A0

I want to be sure of your answer.=

The CBOR=C2=A0tag 4 (Decimal fraction) requ= ire 3 bytes of overhead, see example for RFC 8049 section 2.4.3 bellow.<= u>

This is the tag you are proposing?

This tag will be used all the time (within the context of a union= and without)?

=C2=A0

C= 4 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0#= Tag 4

= =C2=A0 82 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# Arr= ay of length 2

= =C2=A0=C2=A0=C2=A0 21 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# -2<= /span>

= =C2=A0=C2=A0=C2=A0 19 0101 =C2=A0=C2=A0=C2=A0# unsigned(257)<= u>

=C2=A0

Regards,

Michel

=C2=A0

From:=C2=A0core [mailto:core-bounces@ietf.org]=C2=A0<= b>On Behalf Of=C2=A0Alexander Pelov
Sent:=C2=A0Tuesday, July 12, 2016 9:50 AM
To:=C2=A0Carsten Bormann <cabo@tzi.org>
Cc:=C2=A0Core <core@ietf.org>
Subject:=C2=A0Re: [core] YANG to CBOR mapping version 1=

=C2=A0

Hi Carsten,

=C2=A0

Yes, you are right. I thought that we could keep thi= s representation outside of unions. But of course, we need to balance the c= omplexity of doing this.=C2=A0

=C2=A0

There could be a confusion if the server and the cli= ent have different versions of the same module (rare, but must be taken car= e of). Which is of course, the thing we=E2=80=99ve always tried to avoid.. = So yeah, for the moment we could keep the CBOR decimal tag.=C2=A0

=C2=A0

Best,

Alexander

=C2=A0

Le 12 juil. 2016 =C3=A0 12:59, Carsten Bormann <<= a href=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org> a =C3=A9crit :

=C2=A0

Hi Alexander,

This is right. However, I thought that in the discussion of unions we had a= rrived at encoding decimals as CBOR decimal fraction tags. But maybe I'= m misremembering.=C2=A0

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


On 12 Jul 2016 12:04, Alexander Pelov wrote:=C2=A0

Dear Peter,=C2=A0=

In this case you can infer the decimal point position from the YANG definit= ion, e.g. the statement "fraction-digits 2;"=C2=A0
Which indicates that 257 represents the number 2.57. 2 represents 0.02, 50 = represents 0.50, 1000 represents 10.00=C2=A0

I think that you are right that we should provide more examples to be clear= on this point.=C2=A0

Best,=C2=A0
Alexander=C2=A0


Le 12 juil. 2016 =C3=A0 11:58, peter van der Stok &l= t;stokcons@xs4all.nl> a =C3=A9crit :=C2=A0

Hi Michel,=C2=A0

I separated my answer into three parts to simplify the discussion.=C2= =A0



Section 5.3;=C2=A0
In the example, where do I find in the CBOR encoding that the fraction=C2=A0
is 2 digits?=C2=A0
[MV] The number of digits is not encoded. This information is=C2=A0
considered an unnecessary metadata=C2=A0
[MV] similar to "units", text of an enumeration, name of a flag w= ithin=C2=A0
bits. This was the consensus=C2=A0
[MV] of the group which is aligned with the statement in section 3 (In=C2=A0
order to minimize the size of=C2=A0
[MV] the encoded data, the proposed mapping avoid any unnecessary=C2= =A0
meta-information beyond=C2=A0
[MV] those natively supported by CBOR.)=C2=A0
[MV] It might be worth it to raise this topic within a larger audience.=C2=A0


The following example shows the encoding of leaf 'my-decimal' set t= o=C2=A0
2.57.=C2=A0

Definition example from [RFC7317]:=C2=A0

leaf my-decimal {=C2=A0
type decimal64 {=C2=A0
fraction-digits 2;=C2=A0
range "1 .. 3.14 | 10 | 20..max";=C2=A0
}=C2=A0
}=C2=A0

CBOR diagnostic notation: 257=C2=A0

<pvds>=C2=A0
Should it not be pointed out more strongly that the yang to cbor conversion= fails in this case?=C2=A0
I don't see how a change from 2.57 or 257 represents loosing unnecessar= y meta information.=C2=A0
Unless I completely miss the point of the example.=C2=A0
</pvds>=C2=A0

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


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

=C2=A0


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


--001a114298c8db519e0537b2473e-- From nobody Fri Jul 15 13:33:20 2016 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 90D9612DDCF for ; Fri, 15 Jul 2016 13:33:19 -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 INbDG5JJpDkJ for ; Fri, 15 Jul 2016 13:33:17 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0090.outbound.protection.outlook.com [104.47.32.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7EE12DDCA for ; Fri, 15 Jul 2016 13:33:17 -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=PrjNZs6UNtggyE9EB9sSc9TTVxtLBTEYQGj7kuCpUmY=; b=ZuIzkvNoPB9omd/4xhxDdtMQlGXsXwyHnLWvUvJhYfzsUG70PWgZurs3ec6ODgK0wbodt/x3dCdDSTdpSAQkBkip1lkIshE7NOAjxuION87r0KOaKUIHPirRIXv0TfDtRv5aVa0dP4nt4przHN9cgI0o4g9jGidPV1owzzFa5rE= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Fri, 15 Jul 2016 20:33:15 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Fri, 15 Jul 2016 20:33:15 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] YANG to CBOR mapping version 1 Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYAFQCAAAGjAIAAD30AgAAvp4CAABES0IAAFf2AgAT4ItCAAAN8AIAAAg0g Date: Fri, 15 Jul 2016 20:33:15 +0000 Message-ID: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <30945651-d704-4b8a-9c4f-6a56a23daefb@roku> <68BC10EA-5978-4DF0-A380-7585597C7AE5@ackl.io> 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 5e535ee2-4e11-470e-d2c9-08d3acef3f99 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:HxTfrSvoHKwQBVrLB8hl4Vxwb5NPHO16AzpSd6A+umTRmhwWbpp3ITiVKId2jnW6KkTLY7+RxDenJVyiKFqu930i2WmyzHzRJb/rfs+CXiVjCg15btxDtph8dDAe2O4GtBnoAqm6mfJKJfhJp0sG4d6ozm//Ezj99j6Yhi+fNzzro/n5G09kQAj/rzkoalUnO5AxoB48ExhfdbrxMgwzbG/9yylYjfYQRrOGTF74lgE6JvdyLPNnVI+Et/pRkfBt61HmRlQJoLcUaf1MMmoIeXo3YWNvIc8ukxlcqYqcwhM=; 5:JUbWXfI+1vxzZgsJY1N5duD/wXqxPO2q+WAXYAzFFPsWJhWOS0l0a7A7+9+sfcwpytmzKEIUsN4CstYA88nzGIXeRG6mk73V6VuyGtNoDSPoRTrKsWMfog/ymCHEMQj9VrNDvgpDjzhNsE5XpBCY3A==; 24:SDU6EiFRXoRLiU/Dr4o+HyuEtM/GTlPht2wqYywiKAJamsKzI17hHoSVqLxNPJYaRwBDhWf0X48uzsVQO12z6bgxoRBdhILq5q3jN9kbWXg=; 7:Owcy38pdtK6rP2uiHL4gPENAqdzvrRs6f/aWYJGdZtC1G5R7xeiQTl9I9QtcHkDCZ70Y1qy3soWN9FUu84d7tdqnbbhMgQ8uCN+/zIFMVAT+S0tZeaAgEzaSr3Nq6tokXaxn/ZaUNVfuJssokrb6ZSGC6ZKEOkzBH480NUCPzbPpKc0QhENGLsupIEsOjaO8gfi4Fx2ZKRkOZZo4ptgl2KZlRODGnXdlMQJMHtAAFxZdoM0rFZwLSI8q2hMVLOV5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(199003)(51444003)(377454003)(81166006)(6116002)(93886004)(2900100001)(2906002)(8936002)(92566002)(81156014)(2950100001)(99286002)(76576001)(50986999)(3280700002)(74316002)(3846002)(5002640100001)(3660700001)(19300405004)(790700001)(16236675004)(102836003)(4326007)(586003)(7906003)(87936001)(19580395003)(122556002)(66066001)(8676002)(7736002)(5003600100003)(68736007)(10400500002)(106116001)(101416001)(106356001)(19625215002)(11100500001)(9686002)(86362001)(7696003)(110136002)(77096005)(54356999)(33656002)(189998001)(105586002)(19617315012)(19580405001)(7846002)(97736004)(76176999)(19609705001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.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: multipart/alternative; boundary="_000_BLUPR06MB176397EE3F1287CF61D51DF5FE330BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2016 20:33:15.1516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jul 2016 20:33:19 -0000 --_000_BLUPR06MB176397EE3F1287CF61D51DF5FE330BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpUaGUgY3VycmVudCBzb2x1dGlvbiBjb25zaXN0IG9mIHRhZ2dpbmcgZGVjaW1h bDY0IG9ubHkgd2hlbiB1c2VkIGluIHRoZSBjb250ZXh0IG9mIGEgdW5pb24uDQpTYW1lIGZvciBi aXRzLCBlbnVtZXJhdGlvbiwgaWRlbnRpdHlyZWYgYW5kIGluc3RhbmNlLWlkZW50aWZpZXIuDQoo aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS15YW5nLWNib3ItMDIj c2VjdGlvbi01LjEyKQ0KV2l0aCB0aGlzIHNvbHV0aW9uLCB0aGUgMiBvciAzIGJ5dGVzIG92ZXJo ZWFkIGlzIHByZXNlbnQgb25seSBpbiB0aGUgY29udGV4dCBvZiBhIHVuaW9uLg0KDQpJZiB0aGUg Z3JvdXAgcHJlZmVyIHRvIHNlcmlhbGl6ZSBkZWNpbWFsNjQgdXNpbmcgZGVjaW1hbCBmcmFjdGlv bnMNCihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA0OSNzZWN0aW9uLTIuNC4zKQ0K VGhlIDMgYnl0ZXMgb3ZlcmhlYWQgd2lsbCBhbHdheXMgYmUgcHJlc2VudC4NCg0KSSBsaWtlIHRo ZSBzZWNvbmQgYXBwcm9hY2ggYnV0IHVzZXJzIG9mIG1vcmUgY29uc3RyYWluZWQgbmV0d29ya3Mg bWlnaHQgcHJlZmVyIHRoZSBjdXJyZW50IHNvbHV0aW9uLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoN CkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IEZy aWRheSwgSnVseSAxNSwgMjAxNiA0OjE2IFBNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVs LlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPg0KQ2M6IEFsZXhhbmRlciBQZWxvdiA8YUBhY2ts LmlvPjsgQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gWUFORyB0byBD Qk9SIG1hcHBpbmcgdmVyc2lvbiAxDQoNCg0KDQpPbiBGcmksIEp1bCAxNSwgMjAxNiBhdCAxOjA0 IFBNLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208 bWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT4+IHdyb3RlOg0KSGkgQWxl eGFuZGVyDQoNClRvIHNpbXBsaWZ5IHRoZSBpbXBsZW1lbnRhdGlvbiwgSSdsbCBwcmVmZXIgdG8g a2VlcCB0aGUgc2FtZSByZXByZXNlbnRhdGlvbiBmb3IgZGVjaW1hbDY0IHdpdGhpbiBvciB3aXRo b3V0IGEgdW5pb24gKDIuNTcgb3IgMjU3KQ0KV2Ugc2ltcGx5IG5lZWQgdG8gc2VsZWN0IG9uZS4N CkknbSBmaW5kIHdpdGggZWl0aGVyIG9uZXMgYnV0IExQV0FOIGltcGxlbWVudGVycyBtaWdodCBw cmVmZXIgdGhlIENCT1IgdW5zaWduZWQgaW50ZWdlciByZXByZXNlbnRhdGlvbi4NCg0KDQoNClNv IGhvdyBpcyB0aGlzIHVuaW9uIHN1cHBvcnRlZCB3aXRoIHRoZSAybmQgb3B0aW9uPw0KMi41NyBz ZWVtcyB0aGUgb2J2aW91cyBjaG9pY2UgaWYgcm9idXN0bmVzcyBpcyBhIGNvbmNlcm4uDQoNCg0K ICAgbGVhZiBmb28gew0KICAgICAgdHlwZSB1bmlvbiB7DQogICAgICAgICB0eXBlIGRlY2ltYWw2 NCB7DQogICAgICAgICAgICAgZnJhY3Rpb24tZGlnaXRzIDI7DQogICAgICAgICAgfQ0KICAgICAg ICAgIHR5cGUgZGVjaW1hbDY0IHsNCiAgICAgICAgICAgICBmcmFjdGlvbi1kaWdpdHMgNDsNCiAg ICAgICAgICB9DQogICAgICB9DQogICB9DQoNCg0KUmVnYXJkcywNCk1pY2hlbA0KDQpBbmR5DQoN Cg0KRnJvbTogQWxleGFuZGVyIFBlbG92IFttYWlsdG86YUBhY2tsLmlvPG1haWx0bzphQGFja2wu aW8+XQ0KU2VudDogVHVlc2RheSwgSnVseSAxMiwgMjAxNiAxMjoxMCBQTQ0KVG86IE1pY2hlbCBW ZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTxtYWlsdG86TWljaGVs LlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPj4NCkNjOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj47IENvcmUgPGNvcmVAaWV0Zi5vcmc8bWFpbHRv OmNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBZQU5HIHRvIENCT1IgbWFwcGlu ZyB2ZXJzaW9uIDENCg0KSGkgTWljaGVsLA0KDQpJZiB0aGVyZSBpcyBhIHdheSB0byB1bmFtYmln dW91c2x5IGRpZmZlcmVudGlhdGUgYmV0d2VlbiB1bmlvbiBhbmQgbm9uLXVuaW9uLCB0aGVuIHdl IHNob3VsZCB1c2UgdGhlIG1vc3QgZWZmaWNpZW50IHJlcHJlc2VudGF0aW9uLiBIb3dldmVyLCBJ IGdldCB0aGUgaW1wcmVzc2lvbiB0aGF0IHlvdSBjYW4gbW9kaWZ5IGxvY2FsbHkgYSBtb2R1bGUs IHdoaWNoIGNvdWxkIGNoYW5nZSB0aGUgdHlwZSBvZiBhIGxlYWYgZnJvbSBkZWNpbWFsIHRvIHVu aW9uLi4gd2hpY2ggY291bGQgdGhlbiBsZWFkIHRvIGNvbmZ1c2lvbi4NCg0KT25lIG9mIHRoZSBt YWluIGlzc3VlcyB3ZeKAmXJlIGhhdmluZyBpcyB0aGUgcG9zc2libGUgbWlzbWF0Y2ggYmV0d2Vl biB0aGUgbW9kdWxlIHZlcnNpb25zIG9uIGEgc2VydmVyIGFuZCBhIGNsaWVudC4gSG93IGFib3V0 IHRoaXMgLQ0KMSkgd2UgZGVmaW5lIGEgKGxpZ2h0d2VpZ2h0KSBtZWNoYW5pc20gZm9yIGVuc3Vy aW5nIHRoZSBtYXRjaGluZyBvZiB0aGUgbW9kdWxlIHZlcnNpb25zDQoyKSBpZiBtYXRjaGluZywg dGhlbiB1c2UgbW9zdCBlZmZpY2llbnQgcmVwcmVzZW50YXRpb24gKGUuZy4gZW5jb2RlIDIuNTcg YXMgMjU3KQ0KMykgaWYgbm90IG1hdGNoaW5nLCB0aGVuIHVzZSB0YWdzIGZvciBhbGwgcmVwcmVz ZW50YXRpb25zDQoNCkhvdyBkb2VzIHRoaXMgc291bmQ/DQoNCkFsZXhhbmRlcg0KDQoNCkxlIDEy IGp1aWwuIDIwMTYgw6AgMTY6NTcsIE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVA dHJpbGxpYW50aW5jLmNvbTxtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29t Pj4gYSDDqWNyaXQgOg0KDQpIaSBBbGV4YW5kZXINCg0KSSB3YW50IHRvIGJlIHN1cmUgb2YgeW91 ciBhbnN3ZXIuDQpUaGUgQ0JPUiB0YWcgNCAoRGVjaW1hbCBmcmFjdGlvbikgcmVxdWlyZSAzIGJ5 dGVzIG9mIG92ZXJoZWFkLCBzZWUgZXhhbXBsZSBmb3IgUkZDIDgwNDkgc2VjdGlvbiAyLjQuMyBi ZWxsb3cuDQpUaGlzIGlzIHRoZSB0YWcgeW91IGFyZSBwcm9wb3Npbmc/DQpUaGlzIHRhZyB3aWxs IGJlIHVzZWQgYWxsIHRoZSB0aW1lICh3aXRoaW4gdGhlIGNvbnRleHQgb2YgYSB1bmlvbiBhbmQg d2l0aG91dCk/DQoNCkM0ICAgICAgICAgICAgICMgVGFnIDQNCiAgODIgICAgICAgICAgICMgQXJy YXkgb2YgbGVuZ3RoIDINCiAgICAyMSAgICAgICAgICMgLTINCiAgICAxOSAwMTAxICAgICMgdW5z aWduZWQoMjU3KQ0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgUGVsb3YNClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMTIsIDIwMTYgOTo1MCBBTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0 emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+Pg0KQ2M6IENvcmUgPGNvcmVAaWV0Zi5vcmc8bWFp bHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBZQU5HIHRvIENCT1IgbWFw cGluZyB2ZXJzaW9uIDENCg0KSGkgQ2Fyc3RlbiwNCg0KWWVzLCB5b3UgYXJlIHJpZ2h0LiBJIHRo b3VnaHQgdGhhdCB3ZSBjb3VsZCBrZWVwIHRoaXMgcmVwcmVzZW50YXRpb24gb3V0c2lkZSBvZiB1 bmlvbnMuIEJ1dCBvZiBjb3Vyc2UsIHdlIG5lZWQgdG8gYmFsYW5jZSB0aGUgY29tcGxleGl0eSBv ZiBkb2luZyB0aGlzLg0KDQpUaGVyZSBjb3VsZCBiZSBhIGNvbmZ1c2lvbiBpZiB0aGUgc2VydmVy IGFuZCB0aGUgY2xpZW50IGhhdmUgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZSBzYW1lIG1vZHVs ZSAocmFyZSwgYnV0IG11c3QgYmUgdGFrZW4gY2FyZSBvZikuIFdoaWNoIGlzIG9mIGNvdXJzZSwg dGhlIHRoaW5nIHdl4oCZdmUgYWx3YXlzIHRyaWVkIHRvIGF2b2lkLi4gU28geWVhaCwgZm9yIHRo ZSBtb21lbnQgd2UgY291bGQga2VlcCB0aGUgQ0JPUiBkZWNpbWFsIHRhZy4NCg0KQmVzdCwNCkFs ZXhhbmRlcg0KDQpMZSAxMiBqdWlsLiAyMDE2IMOgIDEyOjU5LCBDYXJzdGVuIEJvcm1hbm4gPGNh Ym9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gYSDDqWNyaXQgOg0KDQpIaSBBbGV4YW5k ZXIsDQoNClRoaXMgaXMgcmlnaHQuIEhvd2V2ZXIsIEkgdGhvdWdodCB0aGF0IGluIHRoZSBkaXNj dXNzaW9uIG9mIHVuaW9ucyB3ZSBoYWQgYXJyaXZlZCBhdCBlbmNvZGluZyBkZWNpbWFscyBhcyBD Qk9SIGRlY2ltYWwgZnJhY3Rpb24gdGFncy4gQnV0IG1heWJlIEknbSBtaXNyZW1lbWJlcmluZy4N Cg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpPbiAxMiBKdWwgMjAxNiAxMjowNCwgQWxleGFuZGVyIFBl bG92IHdyb3RlOg0KRGVhciBQZXRlciwNCg0KSW4gdGhpcyBjYXNlIHlvdSBjYW4gaW5mZXIgdGhl IGRlY2ltYWwgcG9pbnQgcG9zaXRpb24gZnJvbSB0aGUgWUFORyBkZWZpbml0aW9uLCBlLmcuIHRo ZSBzdGF0ZW1lbnQgImZyYWN0aW9uLWRpZ2l0cyAyOyINCg0KV2hpY2ggaW5kaWNhdGVzIHRoYXQg MjU3IHJlcHJlc2VudHMgdGhlIG51bWJlciAyLjU3LiAyIHJlcHJlc2VudHMgMC4wMiwgNTAgcmVw cmVzZW50cyAwLjUwLCAxMDAwIHJlcHJlc2VudHMgMTAuMDANCg0KSSB0aGluayB0aGF0IHlvdSBh cmUgcmlnaHQgdGhhdCB3ZSBzaG91bGQgcHJvdmlkZSBtb3JlIGV4YW1wbGVzIHRvIGJlIGNsZWFy IG9uIHRoaXMgcG9pbnQuDQoNCkJlc3QsDQpBbGV4YW5kZXINCg0KTGUgMTIganVpbC4gMjAxNiDD oCAxMTo1OCwgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw8bWFpbHRvOnN0 b2tjb25zQHhzNGFsbC5ubD4+IGEgw6ljcml0IDoNCg0KSGkgTWljaGVsLA0KDQpJIHNlcGFyYXRl ZCBteSBhbnN3ZXIgaW50byB0aHJlZSBwYXJ0cyB0byBzaW1wbGlmeSB0aGUgZGlzY3Vzc2lvbi4N Cg0KDQpTZWN0aW9uIDUuMzsNCkluIHRoZSBleGFtcGxlLCB3aGVyZSBkbyBJIGZpbmQgaW4gdGhl IENCT1IgZW5jb2RpbmcgdGhhdCB0aGUgZnJhY3Rpb24NCmlzIDIgZGlnaXRzPw0KW01WXSBUaGUg bnVtYmVyIG9mIGRpZ2l0cyBpcyBub3QgZW5jb2RlZC4gVGhpcyBpbmZvcm1hdGlvbiBpcw0KY29u c2lkZXJlZCBhbiB1bm5lY2Vzc2FyeSBtZXRhZGF0YQ0KW01WXSBzaW1pbGFyIHRvICJ1bml0cyIs IHRleHQgb2YgYW4gZW51bWVyYXRpb24sIG5hbWUgb2YgYSBmbGFnIHdpdGhpbg0KYml0cy4gVGhp cyB3YXMgdGhlIGNvbnNlbnN1cw0KW01WXSBvZiB0aGUgZ3JvdXAgd2hpY2ggaXMgYWxpZ25lZCB3 aXRoIHRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAzIChJbg0Kb3JkZXIgdG8gbWluaW1pemUgdGhl IHNpemUgb2YNCltNVl0gdGhlIGVuY29kZWQgZGF0YSwgdGhlIHByb3Bvc2VkIG1hcHBpbmcgYXZv aWQgYW55IHVubmVjZXNzYXJ5DQptZXRhLWluZm9ybWF0aW9uIGJleW9uZA0KW01WXSB0aG9zZSBu YXRpdmVseSBzdXBwb3J0ZWQgYnkgQ0JPUi4pDQpbTVZdIEl0IG1pZ2h0IGJlIHdvcnRoIGl0IHRv IHJhaXNlIHRoaXMgdG9waWMgd2l0aGluIGEgbGFyZ2VyIGF1ZGllbmNlLg0KDQpUaGUgZm9sbG93 aW5nIGV4YW1wbGUgc2hvd3MgdGhlIGVuY29kaW5nIG9mIGxlYWYgJ215LWRlY2ltYWwnIHNldCB0 bw0KMi41Ny4NCg0KRGVmaW5pdGlvbiBleGFtcGxlIGZyb20gW1JGQzczMTddOg0KDQpsZWFmIG15 LWRlY2ltYWwgew0KdHlwZSBkZWNpbWFsNjQgew0KZnJhY3Rpb24tZGlnaXRzIDI7DQpyYW5nZSAi MSAuLiAzLjE0IHwgMTAgfCAyMC4ubWF4IjsNCn0NCn0NCg0KQ0JPUiBkaWFnbm9zdGljIG5vdGF0 aW9uOiAyNTcNCg0KPHB2ZHM+DQpTaG91bGQgaXQgbm90IGJlIHBvaW50ZWQgb3V0IG1vcmUgc3Ry b25nbHkgdGhhdCB0aGUgeWFuZyB0byBjYm9yIGNvbnZlcnNpb24gZmFpbHMgaW4gdGhpcyBjYXNl Pw0KSSBkb24ndCBzZWUgaG93IGEgY2hhbmdlIGZyb20gMi41NyBvciAyNTcgcmVwcmVzZW50cyBs b29zaW5nIHVubmVjZXNzYXJ5IG1ldGEgaW5mb3JtYXRpb24uDQpVbmxlc3MgSSBjb21wbGV0ZWx5 IG1pc3MgdGhlIHBvaW50IG9mIHRoZSBleGFtcGxlLg0KPC9wdmRzPg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNv cmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNv cmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== --_000_BLUPR06MB176397EE3F1287CF61D51DF5FE330BLUPR06MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SGkgQW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBj dXJyZW50IHNvbHV0aW9uIGNvbnNpc3Qgb2YgdGFnZ2luZw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+ZGVjaW1hbDY0IG9ubHkgd2hlbiB1c2VkIGluIHRoZSBjb250ZXh0IG9mIGEgdW5pb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+U2FtZSBmb3IgYml0cywgZW51bWVyYXRpb24sIGlkZW50aXR5cmVmIGFu ZCBpbnN0YW5jZS1pZGVudGlmaWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLTAyI3NlY3Rpb24tNS4xMiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS15YW5nLWNib3ItMDIjc2VjdGlv bi01LjEyPC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPldpdGggdGhpcyBzb2x1dGlvbiwgdGhlIDIgb3IgMyBieXRlcyBvdmVy aGVhZCBpcyBwcmVzZW50IG9ubHkgaW4gdGhlIGNvbnRleHQgb2YgYSB1bmlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SWYgdGhlIGdyb3VwIHByZWZlciB0byBzZXJpYWxpemUgZGVjaW1hbDY0IHVzaW5nIGRl Y2ltYWwgZnJhY3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4oPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzcwNDkjc2VjdGlvbi0yLjQuMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcw NDkjc2VjdGlvbi0yLjQuMzwvYT4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgMyBieXRlcyBvdmVyaGVhZCB3aWxsIGFsd2F5 cyBiZSBwcmVzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGxpa2UgdGhlIHNlY29uZCBhcHByb2FjaCBi dXQgdXNlcnMgb2YgbW9yZSBjb25zdHJhaW5lZCBuZXR3b3JrcyBtaWdodCBwcmVmZXIgdGhlIGN1 cnJlbnQgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWNoZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKdWx5IDE1LCAyMDE2IDQ6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hl bCBWZWlsbGV0dGUgJmx0O01pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IEFsZXhhbmRlciBQZWxvdiAmbHQ7YUBhY2tsLmlvJmd0OzsgQ29yZSAmbHQ7 Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSBZQU5HIHRv IENCT1IgbWFwcGluZyB2ZXJzaW9uIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IEp1bCAxNSwgMjAxNiBhdCAxOjA0IFBNLCBNaWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEFsZXhhbmRlcjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbyBzaW1wbGlmeSB0aGUgaW1wbGVtZW50 YXRpb24sIEknbGwgcHJlZmVyIHRvIGtlZXAgdGhlIHNhbWUgcmVwcmVzZW50YXRpb24gZm9yIGRl Y2ltYWw2NCB3aXRoaW4gb3INCiB3aXRob3V0IGEgdW5pb24gKDwvc3Bhbj4yLjU3IG9yIDI1Nyk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+V2Ugc2ltcGx5IG5lZWQgdG8gc2VsZWN0IG9uZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkknbSBmaW5kIHdpdGggZWl0aGVyIG9uZXMgYnV0IExQV0FOIGltcGxlbWVudGVycyBtaWdo dCBwcmVmZXIgdGhlIENCT1IgdW5zaWduZWQgaW50ZWdlciByZXByZXNlbnRhdGlvbi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGhvdyBp cyB0aGlzIHVuaW9uIHN1cHBvcnRlZCB3aXRoIHRoZSAybmQgb3B0aW9uPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi41NyBzZWVtcyB0aGUgb2J2 aW91cyBjaG9pY2UgaWYgcm9idXN0bmVzcyBpcyBhIGNvbmNlcm4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2xlYWYg Zm9vIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgdW5pb24gezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3R5cGUgZGVjaW1hbDY0IHsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2ZyYWN0aW9uLWRpZ2l0cyAyOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0eXBlIGRlY2lt YWw2NCB7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtm cmFjdGlvbi1kaWdpdHMgNDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWljaGVs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFsZXhh bmRlciBQZWxvdiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphQGFja2wuaW8iIHRhcmdldD0iX2Js YW5rIj5hQGFja2wuaW88L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTIs IDIwMTYgMTI6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hlbCBWZWlsbGV0dGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20iIHRhcmdldD0iX2Js YW5rIj5NaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj4gQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0 YXJnZXQ9Il9ibGFuayI+Y2Fib0B0emkub3JnPC9hPiZndDs7IENvcmUgJmx0OzxhIGhyZWY9Im1h aWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gWUFORyB0byBDQk9SIG1hcHBpbmcgdmVy c2lvbiAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhpIE1pY2hlbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JZiB0aGVyZSBpcyBhIHdheSB0byB1bmFtYmlndW91c2x5IGRpZmZlcmVudGlhdGUgYmV0 d2VlbiB1bmlvbiBhbmQgbm9uLXVuaW9uLCB0aGVuIHdlIHNob3VsZCB1c2UgdGhlIG1vc3QgZWZm aWNpZW50IHJlcHJlc2VudGF0aW9uLiBIb3dldmVyLCBJIGdldCB0aGUgaW1wcmVzc2lvbiB0aGF0 IHlvdSBjYW4gbW9kaWZ5DQogbG9jYWxseSBhIG1vZHVsZSwgd2hpY2ggY291bGQgY2hhbmdlIHRo ZSB0eXBlIG9mIGEgbGVhZiBmcm9tIGRlY2ltYWwgdG8gdW5pb24uLiB3aGljaCBjb3VsZCB0aGVu IGxlYWQgdG8gY29uZnVzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIG9mIHRoZSBtYWluIGlzc3VlcyB3ZeKAmXJl IGhhdmluZyBpcyB0aGUgcG9zc2libGUgbWlzbWF0Y2ggYmV0d2VlbiB0aGUgbW9kdWxlIHZlcnNp b25zIG9uIGEgc2VydmVyIGFuZCBhIGNsaWVudC4gSG93IGFib3V0IHRoaXMgLSZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xKSB3ZSBk ZWZpbmUgYSAobGlnaHR3ZWlnaHQpIG1lY2hhbmlzbSBmb3IgZW5zdXJpbmcgdGhlIG1hdGNoaW5n IG9mIHRoZSBtb2R1bGUgdmVyc2lvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+MikgaWYgbWF0Y2hpbmcsIHRoZW4gdXNlIG1vc3QgZWZmaWNp ZW50IHJlcHJlc2VudGF0aW9uIChlLmcuIGVuY29kZSAyLjU3IGFzIDI1Nyk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MykgaWYgbm90IG1hdGNo aW5nLCB0aGVuIHVzZSB0YWdzIGZvciBhbGwgcmVwcmVzZW50YXRpb25zPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgZG9lcyB0aGlz IHNvdW5kPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QWxleGFuZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxlIDEyIGp1aWwuIDIwMTYgw6AgMTY6NTcs IE1pY2hlbCBWZWlsbGV0dGUgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRy aWxsaWFudGluYy5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dGluYy5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQWxl eGFuZGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FudCB0byBiZSBzdXJlIG9mIHlvdXIgYW5zd2Vy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIENCT1ImbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj50YWcgNCAoRGVjaW1hbCBmcmFjdGlvbikNCiByZXF1aXJlIDMgYnl0 ZXMgb2Ygb3ZlcmhlYWQsIHNlZSBleGFtcGxlIGZvciBSRkMgODA0OSBzZWN0aW9uIDIuNC4zIGJl bGxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB0aGUgdGFnIHlvdSBhcmUgcHJvcG9z aW5nPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIHRhZyB3aWxsIGJlIHVzZWQgYWxsIHRoZSB0 aW1lICh3aXRoaW4gdGhlIGNvbnRleHQgb2YgYSB1bmlvbiBhbmQgd2l0aG91dCk/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkM0ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgVGFnIDQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZu YnNwOyA4MiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsjIEFycmF5IG9mIGxlbmd0aCAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsmbmJzcDsgMjEgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IyAtMjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDE5IDAxMDEgJm5ic3A7Jm5ic3A7Jm5ic3A7IyB1bnNpZ25lZCgyNTcpPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWNo ZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Y29yZSBbPGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0mbmJzcDs8Yj5Pbg0KIEJl aGFsZiBPZiZuYnNwOzwvYj5BbGV4YW5kZXIgUGVsb3Y8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDtU dWVzZGF5LCBKdWx5IDEyLCAyMDE2IDk6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7Q2Fyc3Rl biBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2Fib0B0emkub3JnPC9zcGFuPjwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiZuYnNwO0NvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y29yZUBpZXRm Lm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbY29yZV0g WUFORyB0byBDQk9SIG1hcHBpbmcgdmVyc2lvbiAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhp IENhcnN0ZW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzLCB5b3UgYXJlIHJpZ2h0LiBJIHRo b3VnaHQgdGhhdCB3ZSBjb3VsZCBrZWVwIHRoaXMgcmVwcmVzZW50YXRpb24gb3V0c2lkZSBvZiB1 bmlvbnMuIEJ1dCBvZiBjb3Vyc2UsIHdlIG5lZWQgdG8gYmFsYW5jZSB0aGUgY29tcGxleGl0eSBv ZiBkb2luZyB0aGlzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUg Y291bGQgYmUgYSBjb25mdXNpb24gaWYgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCBoYXZlIGRp ZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUgc2FtZSBtb2R1bGUgKHJhcmUsIGJ1dCBtdXN0IGJlIHRh a2VuIGNhcmUgb2YpLiBXaGljaCBpcyBvZiBjb3Vyc2UsIHRoZSB0aGluZyB3ZeKAmXZlIGFsd2F5 cw0KIHRyaWVkIHRvIGF2b2lkLi4gU28geWVhaCwgZm9yIHRoZSBtb21lbnQgd2UgY291bGQga2Vl cCB0aGUgQ0JPUiBkZWNpbWFsIHRhZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsZXhhbmRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkxlIDEyIGp1aWwuIDIwMTYgw6AgMTI6NTksIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmNhYm9AdHppLm9yZzwvc3Bhbj48L2E+Jmd0OyBhIMOpY3JpdCA6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEFsZXhhbmRlciw8YnI+DQo8YnI+DQpUaGlzIGlz IHJpZ2h0LiBIb3dldmVyLCBJIHRob3VnaHQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiBvZiB1bmlv bnMgd2UgaGFkIGFycml2ZWQgYXQgZW5jb2RpbmcgZGVjaW1hbHMgYXMgQ0JPUiBkZWNpbWFsIGZy YWN0aW9uIHRhZ3MuIEJ1dCBtYXliZSBJJ20gbWlzcmVtZW1iZXJpbmcuJm5ic3A7PGJyPg0KPGJy Pg0KR3LDvMOfZSwgQ2Fyc3RlbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDEyIEp1bCAyMDE2IDEyOjA0LCBBbGV4 YW5kZXIgUGVsb3Ygd3JvdGU6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkRlYXIgUGV0ZXIsJm5ic3A7PGJyPg0KPGJyPg0KSW4g dGhpcyBjYXNlIHlvdSBjYW4gaW5mZXIgdGhlIGRlY2ltYWwgcG9pbnQgcG9zaXRpb24gZnJvbSB0 aGUgWUFORyBkZWZpbml0aW9uLCBlLmcuIHRoZSBzdGF0ZW1lbnQgJnF1b3Q7ZnJhY3Rpb24tZGln aXRzIDI7JnF1b3Q7Jm5ic3A7PGJyPg0KPGJyPg0KV2hpY2ggaW5kaWNhdGVzIHRoYXQgMjU3IHJl cHJlc2VudHMgdGhlIG51bWJlciAyLjU3LiAyIHJlcHJlc2VudHMgMC4wMiwgNTAgcmVwcmVzZW50 cyAwLjUwLCAxMDAwIHJlcHJlc2VudHMgMTAuMDAmbmJzcDs8YnI+DQo8YnI+DQpJIHRoaW5rIHRo YXQgeW91IGFyZSByaWdodCB0aGF0IHdlIHNob3VsZCBwcm92aWRlIG1vcmUgZXhhbXBsZXMgdG8g YmUgY2xlYXIgb24gdGhpcyBwb2ludC4mbmJzcDs8YnI+DQo8YnI+DQpCZXN0LCZuYnNwOzxicj4N CkFsZXhhbmRlciZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij5MZSAxMiBqdWlsLiAyMDE2IMOgIDExOjU4LCBwZXRlciB2YW4gZGVyIFN0 b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9rY29uc0B4czRhbGwubmwiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zdG9rY29uc0B4czRhbGwubmw8L3NwYW4+PC9h PiZndDsgYSDDqWNyaXQgOiZuYnNwOzxicj4NCjxicj4NCkhpIE1pY2hlbCwmbmJzcDs8YnI+DQo8 YnI+DQpJIHNlcGFyYXRlZCBteSBhbnN3ZXIgaW50byB0aHJlZSBwYXJ0cyB0byBzaW1wbGlmeSB0 aGUgZGlzY3Vzc2lvbi4mbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWN0aW9uIDUuMzsmbmJzcDs8 YnI+DQpJbiB0aGUgZXhhbXBsZSwgd2hlcmUgZG8gSSBmaW5kIGluIHRoZSBDQk9SIGVuY29kaW5n IHRoYXQgdGhlIGZyYWN0aW9uJm5ic3A7PGJyPg0KaXMgMiBkaWdpdHM/Jm5ic3A7PGJyPg0KW01W XSBUaGUgbnVtYmVyIG9mIGRpZ2l0cyBpcyBub3QgZW5jb2RlZC4gVGhpcyBpbmZvcm1hdGlvbiBp cyZuYnNwOzxicj4NCmNvbnNpZGVyZWQgYW4gdW5uZWNlc3NhcnkgbWV0YWRhdGEmbmJzcDs8YnI+ DQpbTVZdIHNpbWlsYXIgdG8gJnF1b3Q7dW5pdHMmcXVvdDssIHRleHQgb2YgYW4gZW51bWVyYXRp b24sIG5hbWUgb2YgYSBmbGFnIHdpdGhpbiZuYnNwOzxicj4NCmJpdHMuIFRoaXMgd2FzIHRoZSBj b25zZW5zdXMmbmJzcDs8YnI+DQpbTVZdIG9mIHRoZSBncm91cCB3aGljaCBpcyBhbGlnbmVkIHdp dGggdGhlIHN0YXRlbWVudCBpbiBzZWN0aW9uIDMgKEluJm5ic3A7PGJyPg0Kb3JkZXIgdG8gbWlu aW1pemUgdGhlIHNpemUgb2YmbmJzcDs8YnI+DQpbTVZdIHRoZSBlbmNvZGVkIGRhdGEsIHRoZSBw cm9wb3NlZCBtYXBwaW5nIGF2b2lkIGFueSB1bm5lY2Vzc2FyeSZuYnNwOzxicj4NCm1ldGEtaW5m b3JtYXRpb24gYmV5b25kJm5ic3A7PGJyPg0KW01WXSB0aG9zZSBuYXRpdmVseSBzdXBwb3J0ZWQg YnkgQ0JPUi4pJm5ic3A7PGJyPg0KW01WXSBJdCBtaWdodCBiZSB3b3J0aCBpdCB0byByYWlzZSB0 aGlzIHRvcGljIHdpdGhpbiBhIGxhcmdlciBhdWRpZW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy Pg0KVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHRoZSBlbmNvZGluZyBvZiBsZWFmICdteS1k ZWNpbWFsJyBzZXQgdG8mbmJzcDs8YnI+DQoyLjU3LiZuYnNwOzxicj4NCjxicj4NCkRlZmluaXRp b24gZXhhbXBsZSBmcm9tIFtSRkM3MzE3XTombmJzcDs8YnI+DQo8YnI+DQpsZWFmIG15LWRlY2lt YWwgeyZuYnNwOzxicj4NCnR5cGUgZGVjaW1hbDY0IHsmbmJzcDs8YnI+DQpmcmFjdGlvbi1kaWdp dHMgMjsmbmJzcDs8YnI+DQpyYW5nZSAmcXVvdDsxIC4uIDMuMTQgfCAxMCB8IDIwLi5tYXgmcXVv dDs7Jm5ic3A7PGJyPg0KfSZuYnNwOzxicj4NCn0mbmJzcDs8YnI+DQo8YnI+DQpDQk9SIGRpYWdu b3N0aWMgbm90YXRpb246IDI1NyZuYnNwOzxicj4NCjxicj4NCiZsdDtwdmRzJmd0OyZuYnNwOzxi cj4NClNob3VsZCBpdCBub3QgYmUgcG9pbnRlZCBvdXQgbW9yZSBzdHJvbmdseSB0aGF0IHRoZSB5 YW5nIHRvIGNib3IgY29udmVyc2lvbiBmYWlscyBpbiB0aGlzIGNhc2U/Jm5ic3A7PGJyPg0KSSBk b24ndCBzZWUgaG93IGEgY2hhbmdlIGZyb20gMi41NyBvciAyNTcgcmVwcmVzZW50cyBsb29zaW5n IHVubmVjZXNzYXJ5IG1ldGEgaW5mb3JtYXRpb24uJm5ic3A7PGJyPg0KVW5sZXNzIEkgY29tcGxl dGVseSBtaXNzIHRoZSBwb2ludCBvZiB0aGUgZXhhbXBsZS4mbmJzcDs8YnI+DQombHQ7L3B2ZHMm Z3Q7Jm5ic3A7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18mbmJzcDs8YnI+DQpjb3JlIG1haWxpbmcgbGlzdCZuYnNwOzxicj4NCjxhIGhy ZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+Y29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+Jm5ic3A7PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyZuYnNwOzxicj4NCmNvcmUgbWFpbGluZyBsaXN0Jm5ic3A7 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5jb3JlQGlldGYub3JnPC9zcGFuPjwvYT4mbmJzcDs8YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29y ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvcmUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BLUPR06MB176397EE3F1287CF61D51DF5FE330BLUPR06MB1763namp_-- From nobody Sun Jul 17 08:29:56 2016 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 248BF12B03A; Sun, 17 Jul 2016 08:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38jz0zARf_fU; Sun, 17 Jul 2016 08:29:44 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 993F712B010; Sun, 17 Jul 2016 08:22:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,379,1464645600"; d="scan'208,217";a="226929634" Received: from mail-lf0-f48.google.com ([209.85.215.48]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 17 Jul 2016 17:22:42 +0200 Received: by mail-lf0-f48.google.com with SMTP id g62so6642641lfe.3; Sun, 17 Jul 2016 08:22:42 -0700 (PDT) X-Gm-Message-State: ALyK8tJCAybCiUqhxkJBDTQPZ60FqKtV+g2hqRKQvEmE6Q5YIK3wxX/2n7776ezdqgMalLvn6PUo3qE73to5EA== X-Received: by 10.25.37.208 with SMTP id l199mr552324lfl.41.1468768961444; Sun, 17 Jul 2016 08:22:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Sun, 17 Jul 2016 08:22:21 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Sun, 17 Jul 2016 17:22:21 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, core , IETF ROLL , cose@ietf.org, lwig@ietf.org, lp-wan@ietf.org, "iot-dir@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "t2trg@irtf.org" Content-Type: multipart/alternative; boundary=001a11410ed43443780537d66cea Archived-At: Subject: Re: [core] F-Interop info session @IETF96 - Monday 8.30-9-30pm - Charlottenburg I X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jul 2016 15:29:46 -0000 --001a11410ed43443780537d66cea Content-Type: text/plain; charset=UTF-8 All, Please note that the info session is in the EVENING, i.e. 20.30. Some people got confused. Also, the Meetecho team is arranging for remote participation [1] to be possible, thanks to them! Thomas [1] http://ietf96.conf.meetecho.com/index.php/Remote_Participation On Thu, Jul 14, 2016 at 3:43 PM, Thomas Watteyne wrote: > All, > > We are organizing an information meeting about F-Interop, an online > platform for remote interoperability testing, IETF96 Monday 8.30-9.30pm, in > Charlottenburg I. > > F-Interop (www.f-interop.eu) is a platform for online and remote > conformance and interoperability testing, targeted at IoT-related standards > (6TiSCH, 6LoWPAN, CoAP, RPL, ...) > > The purpose of this info session is to give you a technical overview of > the platform, describe how the IETF community can use and contribute to it, > and get feedback. > > The platform is built as part of the 2016-2018 F-Interop H2020 European > project. As part of that project, we will have an open call for entities to > contribute additional tools and test descriptions to the platform. Selected > projects will be funded; we will explain the process during the info > session as well. > > Looking forward to seeing you there, > > Thomas > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11410ed43443780537d66cea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Please note that the info session = is in the EVENING, i.e. 20.30. Some people got confused.

Also, the Meetecho team is arranging for remote participation [1] to= be possible, thanks to them!

Thomas

On Thu, Jul 14, 2016 at 3:43 PM, Thomas Watteyne &= lt;thomas.wat= teyne@inria.fr> wrote:
All,

We are organizing an inform= ation meeting about F-Interop, an online platform for remote interoperabili= ty testing, IETF96 Monday 8.30-9.30pm, in Charlottenburg I.

<= /div>
F-Interop (= www.f-interop.eu) is a platform for online and remote conformance and i= nteroperability testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN= , CoAP, RPL, ...)

The purpose of this info session= is to give you a technical overview of the platform, describe how the IETF= community can use and contribute to it, and get feedback.

The platform is built as part of the 2016-2018 F-Interop H2020 Eur= opean project. As part of that project, we will have an open call for entit= ies to contribute additional tools and test descriptions to the platform. S= elected projects will be funded; we will explain the process during the inf= o session as well.

Looking forward to seeing you t= here,

Thomas



--
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________
--001a11410ed43443780537d66cea-- From nobody Sun Jul 17 13:26:57 2016 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 B26C312B029 for ; Sun, 17 Jul 2016 13:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 JJb0I6X1HLHe for ; Sun, 17 Jul 2016 13:26:50 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F2312B006 for ; Sun, 17 Jul 2016 13:26:39 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud6.xs4all.net with ESMTP id KwSc1t00A4SmhUa01wScZo; Sun, 17 Jul 2016 22:26:37 +0200 Received: from 2001:67c:370:136:fd87:6288:aec5:1b64 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sun, 17 Jul 2016 22:26:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 17 Jul 2016 22:26:36 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <43805298839959a534d83c720ac6239c@xs4all.nl> <8a6ece7e540f02c064c8d638b2d83463@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (lFU3C6Iz8+uUteo0HdBr9VdOMh8l9u9P) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping version 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 20:26:56 -0000 Then no extra meta data is needed. Peter Michel Veillette schreef op 2016-07-15 20:27: > Hi Peter > > "Meta data" is defined as "data that provides information about other > data" > The identification of which data nodes are listed in the 'key' YANG > statement is information about the data transferred, not the data > itself. > > So yes, extra meta-date is required if we want to identify the list of > key(s) in the encoded payload. > > Updating the list of keys is not something typical and if done, I > assume that the interactions between clients and servers change > significantly. I still believe that the discovery process is the most > appropriate and generic way to address these types of problems. > > Regards, > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Thursday, July 14, 2016 11:40 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] YANG to CBOR mapping version 1 > > Hi Michel, > > >> In this case, you propose to add more meta data than >> "draft-ietf-netmod-yang-json" >> which don't share the same limitations on the payload size. >> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 > > I don't think extra meta-data is needed (depending on your definition > of > meta-data) > >> >> Regards, >> Michel > > Greetings, > > Peter > >> >> >> -----Original Message----- >> >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Thursday, July 14, 2016 3:57 AM >> To: Michel Veillette >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] YANG to CBOR mapping version 1 >> >> Hi Michel, >> >> IMO, an error is an error and should be treated as such. Trying to >> salvage unhealthy situations leads to worse problems. >> >> My approach would be that servers and clients are simple and don't >> need to parse the yang modules during operation; and keep extensive >> state information about each other. >> >> The discussion seems to confirm my growing conviction that the CoMI >> and CoOL approaches are fundamentally different. >> >> Peter >> >> Michel Veillette schreef op 2016-07-13 19:06: >>> Hi Peter >>> >>> I'm not convinced that Including in the encoding which data nodes are >>> the keys completely solve the issue. >>> If the client transmit a payload with one key and the server required >>> two keys, the payload will be rejected. >>> If the client transmit a payload with two keys (marked as such) and >>> the server require one key, the payload will be rejected. >>> To work, both sides need to known the number of keys used by the >>> other side and only 'ietf-cool-library' can resolve that. >>> >>> Also, not making which data nodes are keys might help during the >>> migration. >>> >>> Regards, >>> Michel >>> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Wednesday, July 13, 2016 12:55 PM >>> To: Michel Veillette >>> Cc: consultancy@vanderstok.org; Core >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>> >>> Hi Michel, >>> >>> That looks pretty complex to me; while the keys can be elegantly >>> expressed in the CBOR contents. >>> >>> Peter >>> >>> Michel Veillette schreef op 2016-07-13 16:36: >>>> Hi Peter >>>> >>>> The scenario you described is part of the generic discovery problem. >>>> To perform its tasks, clients typically need to known the list of >>>> modules, features, deviations implemented by a server and associated >>>> versions. >>>> This problem is addressed in >>>> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library >>>> - >>>> l >>>> atest.html >>>> which is the constrained version of >>>> https://datatracker.ietf.org/doc/rfc7895/ >>>> >>>> module: ietf-cool-library >>>> +--ro modules-state >>>> +--ro module-set-id union >>>> +--ro module* [sid revision] >>>> +--ro sid sid >>>> +--ro revision revision >>>> +--ro feature* sid >>>> +--ro deviation* [sid revision] >>>> | +--ro sid sid >>>> | +--ro revision revision >>>> +--ro conformance-type enumeration >>>> +--ro submodules >>>> +--ro submodule* [sid revision] >>>> +--ro sid sid >>>> +--ro revision revision >>>> notifications: >>>> +---n yang-library-change >>>> +--ro module-set-id -> /modules-state/module-set-id >>>> >>>> Regards >>>> Michel >>>> >>>> -----Original Message----- >>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>> Sent: Wednesday, July 13, 2016 2:34 AM >>>> To: Michel Veillette >>>> Cc: consultancy@vanderstok.org; Core >>>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>> >>>> Hi Michel, >>>> >>>> When a specification changes it set of of keys, I don't think the >>>> SIDs will change. >>>> It is for sure that the hashes are not affected by the attribution >>>> of a key. >>>> >>>> Therefore, what happens when client and server use different keys in >>>> otherwise identical list specification? >>>> >>>> Peter >>>> >>>> Michel Veillette schreef op 2016-07-12 17:07: >>>>> Hi Peter >>>>> >>>>> The validations performed by the entity which de-serialize the CBOR >>>>> payload is based on the YANG schema. >>>>> This validation is based on all king of YANG statements such as: >>>>> key, unique, range, pattern, length, min-elements, max-elements, >>>>> must, when, if-feature >>>>> >>>>> The identification of which data nodes are keys is considered >>>>> unnecessary meta-data since available in the schema. >>>>> Even more heavy weight representations such as xml and json don't >>>>> include this meta-data in the encode payload. >>>>> >>>>> Regards, >>>>> Michel >>>>> >>>>> -----Original Message----- >>>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>>> Sent: Tuesday, July 12, 2016 6:08 AM >>>>> To: Michel Veillette >>>>> Cc: consultancy@vanderstok.org; Core >>>>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>>> >>>>> Hi Michel, >>>>> >>>>>> >>>>>> However, I am missing how to transport a given list instance with >>>>>> its key values in the CBOR encoding. Section 4.4 describes the >>>>>> encoding of a complete list not a subset of its instances. >>>>>> >>>>>> [MV] A list instance is a collection which is described in section >>>>>> 4.2. >>>>>> __________________________________________________________________ >>>>>> _ >>>>>> _ >>>>>> _ >>>>>> _ >>>>>> _______________________ >>>>> >>>>> With the current text I don't see how you distinguish instances >>>>> with the same key from instances with different keys. >>>>> >>>>> Example: >>>>> >>>>> list server { >>>>> key name; >>>>> >>>>> leaf name { >>>>> type string; >>>>> } >>>>> leaf iburst { >>>>> type boolean; >>>>> default false; >>>>> } >>>>> >>>>> How to distinguish that in the list below that two instances are >>>>> identical (should not occur) >>>>> [ >>>>> { >>>>> 1755 : "NRC TIC server", # name (SID 1755) >>>>> 1754 : false, # iburst (SID 1754) >>>>> }, >>>>> { >>>>> 1755 : "NRC TIC server", # name (SID 1755) >>>>> 1754 : true, # iburst (SID 1754) >>>>> } >>>>> ] >>>>> >>>>> And the following two instances are different (valid array) >>>>> >>>>> [ >>>>> { >>>>> 1755 : "NRC TAC server", # name (SID 1755) >>>>> 1754 : true, # iburst (SID 1754) >>>>> }, >>>>> { >>>>> 1755 : "NRC TIC server", # name (SID 1755) >>>>> 1754 : true, # iburst (SID 1754) >>>>> } >>>>> ] From nobody Sun Jul 17 16:22:09 2016 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 BA73312B00E for ; Sun, 17 Jul 2016 16:22:08 -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 Jo1GFAfpVF2w for ; Sun, 17 Jul 2016 16:22:06 -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 9BFEE12B00D for ; Sun, 17 Jul 2016 16:22:06 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 89CDB42F44; Mon, 18 Jul 2016 01:22:03 +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 830594A; Mon, 18 Jul 2016 01:22:01 +0200 (CEST) Received: from hephaistos.amsuess.com (ip5b405da5.dynamic.kabel-deutschland.de [91.64.93.165]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1F7F660; Mon, 18 Jul 2016 01:22:01 +0200 (CEST) Received: (nullmailer pid 24632 invoked by uid 1000); Sun, 17 Jul 2016 23:21:59 -0000 Date: Mon, 18 Jul 2016 01:21:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20160717232159.GA12256@hephaistos.amsuess.com> References: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-lin?= =?utf-8?q?ks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jul 2016 23:22:09 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael, hello group, On Sat, Jul 09, 2016 at 07:26:25AM +0000, Jaime Jim=C3=A9nez wrote: > This is the Working Group Last Call for the "Representing CoRE Formats in= JSON and CBOR=E2=80=9D document. > https://tools.ietf.org/html/draft-ietf-core-links-json-06 >=20 > Due to the IETF meeting, the call is planned to end three weeks from now = by July 30th. If possible, comments should be provided early so that we can= discuss this during the CoRE sessions on IETF96. Sorry this is a bit late, I've only now come around to review all my unread mails on the topic. It is my impression from the mails on links-json that the attempts to get a semantically parsable JSON representation were moved into the hypermedia approaches because JSON-LD could only do something meaningful with a list of rt (if, ct etc.) values, while links-json should stay simple and 1:1 take over link-format's whitespace separated strings. Michael, do you concur with the above? (The question goes anyone, but you were most active in the discussion.) The objectives section mentions has a "Consider other work that has links in JSON, e.g.: JSON-LD, JSON-Refernce" paragraph. If the above holds, JSON-LD was considerered and deemed unsuitable. Of JSON-Reference, I couldn't find a mention -- it was not adopted for links-json, so it was either not considered or also considered and deemed unsuitable. Shouldn't the results of these considerations be reflected in the text? I think so, because otherwise readers could be led to conclude from the mention that JSON Link Format would work with JSON-LD. To keep "code locality" in the text, my suggested course of action (assuming JSON-Reference was considered) is adding an additional bullet under "Consider": * Both JSON-LD and JSON-Reference were considered, but supporting them in JSON Link Format would have introduced too much complexity in the conversion to be practical. Best regards Christian --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjBMUAAoJEDmNERLTpL3hk8MQALCOtCptYX2k9QuMlrrfZ5pP IVWxjXWnPXz2J7NMnN/0DUJCZEDDOYxE9x7Ipkk3vZa8yEoWTIpRnrGy+02D0lEz GA/L+zCfXAJ0JNhYR4/1adwl9o4zcv0Cuc0lXbh6W5wdFwOG0tg12q8Axd5CWKIe F5UrPpPRnjk/KEXdMk129woCSpMJuQwfE75xAzdDpWyvvIo6Hrr6RmRscN+XtkEI 6Egv7exGnmIsNwaqzuU63SLTuVXfAPOf20iFGzm7ImfFf/fAEZi7EZN0fx7u+jO1 bGMbXug3TJiVhkj9Y4Lbb6Jii69lYchSHce71uJ1SdR+E720f7SiWQAhgasil01g 853jXoBmrpf//5Gm42ill+A7oIsls3zUXlwirSEIeG95shqUvQ67RAz41sPNOJVf nL2nrtj2GlcAGrGHALrgvqxOQLYluSQJ56cFBtZWm7AGUFnhzpJHdy+UR6x0uqup 3kz7QBrVe5t8xhF2AJ3gHNghaQL8jv2pYuqf5F2rw0G476rmprkmsIYWANZHLhib B483SWeubWbliS1HZFrJjMPTAe/NcsEO+B1i0dw+tPLH6aPww8w+2GrSYh6qHiHY 3DJCn3Xh6WVWELnuZxrnJiY2Rah7iQxIX2D8I1Nz0/43QjKHP8TDFy5Z1tHTSfdF H393sh+bdD9MY03JbNl/ =hPie -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From nobody Sun Jul 17 17:39:01 2016 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 B69BE12D0EB for ; Sun, 17 Jul 2016 17:38:59 -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 m-5Cyk2Y72jF for ; Sun, 17 Jul 2016 17:38:57 -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 CBDA612B01A for ; Sun, 17 Jul 2016 17:38:56 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4062640083 for ; Mon, 18 Jul 2016 02:38:54 +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 22B9F4A for ; Mon, 18 Jul 2016 02:38:53 +0200 (CEST) Received: from hephaistos.amsuess.com (p4FD4C980.dip0.t-ipconnect.de [79.212.201.128]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7023560 for ; Mon, 18 Jul 2016 02:38:52 +0200 (CEST) Received: (nullmailer pid 27921 invoked by uid 1000); Mon, 18 Jul 2016 00:38:50 -0000 Date: Mon, 18 Jul 2016 02:38:50 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20160718003849.GC19248@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 00:39:00 -0000 --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello group, I've read through the http-mapping-12 draft, I'm curious whether I've spotted a consistency error and a needless constraint in the draft, or just lack understanding of the involved mechanisms: * 5.3 Default Mapping states that "[t]he default mapping is for the Target CoAP URI to be appended as-is to the HC Proxy URI". Given the HC Proxy URI would typically be "http://.../hc", literal appending of a CoAP URI gives "http://.../hccoap://..." without a slash after "hc". In 5.5 Discovery, there is a "[t]he default template given in Section 5.3, i.e., {+tu}", again without a slash before it (similar with 5.5.1). As 5.4 states that the URI Mapping Template is concatenated to the HC Proxy URI, this would not result in a slash. (I've also checked RFC 6570 URI Templates: It does not specify any concatenation operation that would insert a slash.) =20 In another place (5.4.1.1 2.), the template of "/{+tu}" is given as a default. My interpretation of those inconsistencies is that the intention is to have a default template of "/{+tu}", and that the 5.3 phrase just misses mentioning the slash that comes with the default template. * 5.5 Discovery states that when discovered via CoAP, 'the link associated to the "core.hc" resource needs an explicit anchor referring to the HTTP origin', resulting in a link-format of ;anchor=3D"http://p.example.com";rt=3D"core.hc" =20 . While the anchor form is perfectly legal, why is it *needed*? A ;rt=3D"core.hc" could at worst be interpreted in a way that it is hosted by the CoAP server (because "hosts" is the default rel and is the default anchor), but that would go away as soon as any other rel is used by the application, and I think the "http://p.example.com hosts http://p.example.com/hc" statement is not really valuable. Is there, apart from the "hosts" rel which an application might set to any other value (an ext-rel-type), a reason for the "needs"? I know that it is late in the document process, and that neither of these issues (if they are issues at all and not just my misinterpretation) is likely to cause actually wrong implementations=20 (implementors that followed the letters of '{+tu}' would be likely to consider /hccoap:// to be buggy and fix it the obvious way). Is there something we should do about this? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjCUWAAoJEDmNERLTpL3hceAP/R4Tgnvkb4T5Pge7GHhS8xHf 2xcGtJ9xvMqdXb4prpkUwstj1ZgUyvfN6ZFBmBt3Vd0jn+Wh6GKz0evk9WjweqAX XMBelz5nYkoiw0iDsScNgabqNh1plnDgsku64Z5i3G9bnkXNB9KkDxMME8e9liut 3ulcwvBkzGLwibZcgqzYKBk0C5XiNQtshyG5frY1iToTLAUl45QGaV4nDXnw/oOW 7GVnwl+o6/6KHIDUfDOZ6x5qhdC21Lvk2yEOaxHpFJ+RQVn1jKp/WvODXdrfxx6+ BfA4cjVCbMbQ/I920RIjG+FaOhBc19G1YSUmnW3vREz4GM849hBZ/zO3lBVnV9b9 Cd/iX0OpN2dYRpiUkDk6kWdy/tuoOyGg72I9qww0LRkcrVelW9aS/hHvFP052Ca2 CJxSbzrKumyHcQzMVf2hTEbDUuG49PIqhljw6QxpL5LFUsG22XXmoNgGFQdAaRw+ /gRFN85dCNvnf2VfZO21abG/Qy9vdFOSxPDYj7n4lGjjEGsr82ybEmzi28lRSYBA lrMOnsW+VqJKikQghW++vCPKgBJX78FINA53oAY/p+Lo48okhGZf3jh/KYvZ0SUB t81YQF+RZhonAgHunrkC5oOztLVRSsgY9vUMzzcGHNJyGmToT/YupgEil6LzKlI5 IIebrbvDuonXZ5ehqAfU =A2iS -----END PGP SIGNATURE----- --O3RTKUHj+75w1tg5-- From nobody Sun Jul 17 23:52:00 2016 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 8A77D12D0F9 for ; Sun, 17 Jul 2016 23:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyTZtGQccL7r for ; Sun, 17 Jul 2016 23:51:56 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 6A63B12B02D for ; Sun, 17 Jul 2016 23:51:55 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id g62so14283662lfe.3 for ; Sun, 17 Jul 2016 23:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ngVIjjK1xdWnvnVxlzeAk7uJaNCN4PkDq/oK5UBZrBQ=; b=Cim0yWX5z2gEdTXwLgKy+fffmhXVzTux6fBqa2iNeEsM1bkKXOh91cZlRftW7AyJdP jMKuf79sjEjO+8Ic+4FQVIsPCBxP/XfLEg+H0Yk2347VwD9Fd6sezdFoJAdIpf3FzKmk ic5lwovYCMLx+Gm18/lwKIMiI36kKBP/LAqGhOB56ADx5mODSviFIOfq96hMxSKuL90v k5ZTP7PCtMMPO9b4LBnw6iq91ljEmY30OL54Sm3k1r6DNvwY+zfh4Eu+p0ZWxrS/MLUa raMqRgUJ2EzljyA6+HEimAhlY5iXCmyonvvbbX2agiFl9Zb1GywBglCCtPAXg6UlndY0 DGNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ngVIjjK1xdWnvnVxlzeAk7uJaNCN4PkDq/oK5UBZrBQ=; b=Jg8QK/RWycpyNniFn6jyN2oDDOZMeJoCR9YFxO0iR31lRHNsFEcfCGIiaCnPqmrB6U oUMPmBSZ+6/WRH4uWxZfqPLrImewUjo84HGEo4elaW0m5y4UMexRuqcoThU5I47EY+0J 3YyYb9wmag2pTJnVcaTRcgCzF2yFEpCNaZabIt+QpfoU40Q1WWcyJXKi4D3CkZO0Aych TfvZcOZboK1XFBoDyaHZZgWp6dpzCLm7ehu77s5BMS6bT4Ms/LBmWu4LeZDYakzBHIQ/ HpDWXbPTL+8hmlqOEwOzNBUjeizlJolZfkb1wRjuCNbXVsJmSE6lViPzz1WT7ehTjiwZ PY6A== X-Gm-Message-State: ALyK8tJRHgGQcEen2koWyaStoTLIrJITepWErB5sYw6YvZ4vsm/oQIQtwfOGCzkuPWDz7g== X-Received: by 10.25.90.209 with SMTP id o200mr13407305lfb.193.1468824713403; Sun, 17 Jul 2016 23:51:53 -0700 (PDT) Received: from [192.168.48.206] ([212.91.224.152]) by smtp.gmail.com with ESMTPSA id f139sm2820782lfb.11.2016.07.17.23.51.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Jul 2016 23:51:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CCDBD60F-49E7-40E9-8291-EF0C0BECD162" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <20160717232159.GA12256@hephaistos.amsuess.com> Date: Mon, 18 Jul 2016 08:51:50 +0200 Message-Id: <36F8FBDB-E334-4B87-8DAD-634DAD566015@gmail.com> References: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> <20160717232159.GA12256@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-lin?= =?utf-8?q?ks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 06:51:57 -0000 --Apple-Mail=_CCDBD60F-49E7-40E9-8291-EF0C0BECD162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian, I believe that it is a requirement for core-links-json tobe a 1:1 = bidirectionally lossless mapping to CoRE Link-Format. This has been my = assumption anyway. As I remember the earlier discussion, we considered using a JSON-LD = context file to process a core-links-json representation and map = keywords and values from the link-format representation to descriptive = URLs. We were discussing whether this was meaningful for high level = applications that want to comprenend the content of the links, i.e. = relation values, attribute values, etc. I don't think it was fully resolved, and would like to continue the = discussion. I think for the draft, if the use case and requirements are = clear about lossless mapping of CoRE Link-Format, we could set the = context for the comments about JSON-LD. Perhaps we could discuss JSON-LD mapping separately and involve any = other interested parties? Best regards, Michael > On Jul 18, 2016, at 1:21 AM, Christian Ams=C3=BCss = wrote: >=20 > It is my impression from the mails on links-json that the attempts to > get a semantically parsable JSON representation were moved into the > hypermedia approaches because JSON-LD could only do something = meaningful > with a list of rt (if, ct etc.) values, while links-json should stay > simple and 1:1 take over link-format's whitespace separated strings. >=20 > Michael, do you concur with the above? (The question goes anyone, but > you were most active in the discussion.) >=20 --Apple-Mail=_CCDBD60F-49E7-40E9-8291-EF0C0BECD162 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Christian,

I believe that it is a requirement for core-links-json tobe a = 1:1 bidirectionally lossless mapping to CoRE Link-Format. This has been = my assumption anyway.

As I remember the earlier discussion, we considered using a = JSON-LD context file to process a core-links-json representation and map = keywords and values from the link-format representation to descriptive = URLs. We were discussing whether this was meaningful for high level = applications that want to comprenend the content of the links, i.e. = relation values, attribute values, etc.

I don't think it was fully resolved, = and would like to continue the discussion. I think for the draft, if the = use case and requirements are clear about lossless mapping of CoRE = Link-Format, we could set the context for the comments about = JSON-LD.

Perhaps= we could discuss JSON-LD mapping separately and involve any other = interested parties?

Best regards,

Michael

On = Jul 18, 2016, at 1:21 AM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:

It is my impression from the mails on links-json = that the attempts to
get a semantically = parsable JSON representation were moved into the
hypermedia approaches because JSON-LD could only = do something meaningful
with a list of rt (if, ct = etc.) values, while links-json should stay
simple and 1:1 take over link-format's = whitespace separated strings.

Michael, do you concur = with the above? (The question goes anyone, but
you were most active in the = discussion.)


= --Apple-Mail=_CCDBD60F-49E7-40E9-8291-EF0C0BECD162-- From nobody Mon Jul 18 01:27:14 2016 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 21D5812B034 for ; Mon, 18 Jul 2016 01:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 KdOxt0JS4uQQ for ; Mon, 18 Jul 2016 01:27:10 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2173D12D0F7 for ; Mon, 18 Jul 2016 01:27:09 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 57B5BCFEFB1B4; Mon, 18 Jul 2016 08:27:05 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6I8R6pn006991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 08:27:07 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6I8R1Bm028350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 10:27:06 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 10:27:04 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4IzOMziR1rQe0ECS+m3saUK3wqAd2zcA Date: Mon, 18 Jul 2016 08:27:03 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> In-Reply-To: <20160718003849.GC19248@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <48634EC399AA344D8CEB06E48ED31D54@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 08:27:13 -0000 Hi Christian, Thanks very much for reviewing the draft. It's never too late for bug fixing! On 18/07/2016 02:38, "core on behalf of Christian Ams=FCss" wrote: >Hello group, > >I've read through the http-mapping-12 draft, I'm curious whether I've >spotted a consistency error and a needless constraint in the draft, or >just lack understanding of the involved mechanisms: > >* 5.3 Default Mapping states that "[t]he default mapping is for the Target > CoAP URI to be appended as-is to the HC Proxy URI". Given the HC Proxy > URI would typically be "http://.../hc", literal appending of a CoAP > URI gives "http://.../hccoap://..." without a slash after "hc". In 5.5 > Discovery, there is a "[t]he default template given in Section 5.3, > i.e., {+tu}", again without a slash before it (similar with 5.5.1). As > 5.4 states that the URI Mapping Template is concatenated to the HC > Proxy URI, this would not result in a slash. (I've also checked RFC > 6570 URI Templates: It does not specify any concatenation operation > that would insert a slash.) > =20 > In another place (5.4.1.1 2.), the template of "/{+tu}" is given as a > default. > > My interpretation of those inconsistencies is that the intention is to > have a default template of "/{+tu}", and that the 5.3 phrase just > misses mentioning the slash that comes with the default template. I think you are right. >* 5.5 Discovery states that when discovered via CoAP, 'the link > associated to the "core.hc" resource needs an explicit anchor > referring to the HTTP origin', resulting in a link-format of > > ;anchor=3D"http://p.example.com";rt=3D"core.hc" > =20 > . While the anchor form is perfectly legal, why is it *needed*? A > > ;rt=3D"core.hc" > > could at worst be interpreted in a way that it is hosted by the CoAP > server (because "hosts" is the default rel and is the default > anchor), but that would go away as soon as any other rel is used by > the application, and I think the "http://p.example.com hosts > http://p.example.com/hc" statement is not really valuable. > > Is there, apart from the "hosts" rel which an application might set > to any other value (an ext-rel-type), a reason for the "needs"? My reading of RFC 6690 section 2.1: """ Each link conveys one target URI as a URI-reference inside angle brackets ("<>"). The context URI of a link (also called the base URI in [RFC3986]) is determined by the following rules in this specification: (a) The context URI is set to the anchor parameter, when specified. (b) Origin of the target URI, when specified. (c) Origin of the link format resource's base URI. """ is that we MUST force (a) because otherwise a client would use (b) which is clearly wrong since if the query comes from the CoAP side, the "specified" origin is the coap:// origin -- and we need the http:// one instead. (Here my assumption is that (a), (b) & (c) are in strict order, otherwise there would be no way to disambiguate situations where, for example, both (a) and (b) apply.) >I know that it is late in the document process, and that neither of >these issues (if they are issues at all and not just my >misinterpretation) is likely to cause actually wrong implementations >(implementors that followed the letters of '{+tu}' would be likely to >consider /hccoap:// to be buggy and fix it the obvious way). Is there >something we should do about this? We have to fix the slash-less {+tu} text occurrences. I'm not sure when -- before or during IESG review? Jaime and Carsten will surely have a sensible answer for this. Cheers, t From nobody Mon Jul 18 01:47:23 2016 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 D334912D177 for ; Mon, 18 Jul 2016 01:47:21 -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 inAWjebgqOFL for ; Mon, 18 Jul 2016 01:47:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395C012D150 for ; Mon, 18 Jul 2016 01:47:19 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-74-578c9795314e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 61.2D.12926.5979C875; Mon, 18 Jul 2016 10:47:17 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.230]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 10:46:36 +0200 From: =?iso-8859-1?Q?Jaime_Jim=E9nez?= To: "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4IzK4sOHw4LP8EyQB5mgtsmv3qAdubGAgAAFdYA= Date: Mon, 18 Jul 2016 08:46:36 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.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.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <57F7058E7298794482FEAB3ED26DA418@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7ge7U6T3hBudvKVksv/CcxWLf2/XM Fi2fP7E5MHts3X+XyWPJkp9MHndvXWIKYI7isklJzcksSy3St0vgyphyeiZ7wSblislrW9ga GBfKdDFyckgImEic6/vFAmGLSVy4t54NxBYSOMIo8XG9fxcjF5C9BMieeJARJMEm4Czx7fMs JhBbRMBWYlPDNlYQm1kgS+L/r2awZmEBY4n27StZIWpMJHp/fIaqt5KYd+AL2BwWAVWJ64ee gdXzCthLzPn/hhFicYHE433fwXo5geJPZm9hB7EZgY77fmoNE8QucYlbT+YzQRwtILFkz3lm CFtU4uXjf6wQtpJE45InULfpSdyYOoUNwraWaLt6DSquLbFs4WtmiBsEJU7OfMIygVF8FpIV s5C0z0LSPgtJ+ywk7QsYWVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMbgwS2/VXcwXn7j eIhRgINRiYd3wfHucCHWxLLiytxDjBIczEoivP6Te8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MErxcflv0q755rb421qjmL9WIl7vm2+9NrrQqKsp GsZivz/6hNhp5VXxhavXGrVNTFrNGiW8Zsb3R9qzp905t1V707KPnS/e/N4oVL3qM0N7hkBa V8/yVEb/Ffprj14vWz5/R9rDAxOXWuptmTy/ZerRJ9836au8f3b94ma3JZyT9nyTijn14UKB EktxRqKhFnNRcSIA0aV6cr0CAAA= Archived-At: Cc: "core@ietf.org" , =?iso-8859-1?Q?Christian_Ams=FCss?= Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 08:47:22 -0000 Hi, As Thomas pointed out, there is still time to make the changes, you can sub= mit a new version reflecting the late WGLC comments. On 5.3. though the text could be made more clear by also pointing to the th= ree 5.4.1.1 examples and by editing the text on 5.3 to "/{+tu}". Ciao, - - Jaime Jimenez > On 18 Jul 2016, at 10:27, Fossati, Thomas (Nokia - GB) wrote: >=20 > Hi Christian, >=20 > Thanks very much for reviewing the draft. It's never too late for bug > fixing! >=20 > On 18/07/2016 02:38, "core on behalf of Christian Ams=FCss" > wrote: >> Hello group, >>=20 >> I've read through the http-mapping-12 draft, I'm curious whether I've >> spotted a consistency error and a needless constraint in the draft, or >> just lack understanding of the involved mechanisms: >>=20 >> * 5.3 Default Mapping states that "[t]he default mapping is for the Targ= et >> CoAP URI to be appended as-is to the HC Proxy URI". Given the HC Proxy >> URI would typically be "http://.../hc", literal appending of a CoAP >> URI gives "http://.../hccoap://..." without a slash after "hc". In 5.5 >> Discovery, there is a "[t]he default template given in Section 5.3, >> i.e., {+tu}", again without a slash before it (similar with 5.5.1). As >> 5.4 states that the URI Mapping Template is concatenated to the HC >> Proxy URI, this would not result in a slash. (I've also checked RFC >> 6570 URI Templates: It does not specify any concatenation operation >> that would insert a slash.) >>=20 >> In another place (5.4.1.1 2.), the template of "/{+tu}" is given as a >> default. >>=20 >> My interpretation of those inconsistencies is that the intention is to >> have a default template of "/{+tu}", and that the 5.3 phrase just >> misses mentioning the slash that comes with the default template. >=20 > I think you are right. >=20 >> * 5.5 Discovery states that when discovered via CoAP, 'the link >> associated to the "core.hc" resource needs an explicit anchor >> referring to the HTTP origin', resulting in a link-format of >>=20 >> ;anchor=3D"http://p.example.com";rt=3D"core.hc" >>=20 >> . While the anchor form is perfectly legal, why is it *needed*? A >>=20 >> ;rt=3D"core.hc" >>=20 >> could at worst be interpreted in a way that it is hosted by the CoAP >> server (because "hosts" is the default rel and is the default >> anchor), but that would go away as soon as any other rel is used by >> the application, and I think the "http://p.example.com hosts >> http://p.example.com/hc" statement is not really valuable. >>=20 >> Is there, apart from the "hosts" rel which an application might set >> to any other value (an ext-rel-type), a reason for the "needs"? >=20 > My reading of RFC 6690 section 2.1: > """ > Each link conveys one target URI as a URI-reference inside angle > brackets ("<>"). The context URI of a link (also called the base URI > in [RFC3986]) is determined by the following rules in this > specification: >=20 > (a) The context URI is set to the anchor parameter, when specified. >=20 > (b) Origin of the target URI, when specified. >=20 > (c) Origin of the link format resource's base URI. >=20 > """ > is that we MUST force (a) because otherwise a client would use (b) which > is clearly wrong since if the query comes from the CoAP side, the > "specified" origin is the coap:// origin -- and we need the http:// one > instead. >=20 >=20 > (Here my assumption is that (a), (b) & (c) are in strict order, otherwise > there would be no way to disambiguate situations where, for example, both > (a) and (b) apply.) >=20 >> I know that it is late in the document process, and that neither of >> these issues (if they are issues at all and not just my >> misinterpretation) is likely to cause actually wrong implementations >> (implementors that followed the letters of '{+tu}' would be likely to >> consider /hccoap:// to be buggy and fix it the obvious way). Is there >> something we should do about this? >=20 > We have to fix the slash-less {+tu} text occurrences. I'm not sure when > -- before or during IESG review? Jaime and Carsten will surely have a > sensible answer for this. >=20 > Cheers, t >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 18 01:55:10 2016 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 3AF8112D09F for ; Mon, 18 Jul 2016 01:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ykxiX3m471wJ for ; Mon, 18 Jul 2016 01:55:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 56EAD12B008 for ; Mon, 18 Jul 2016 01:55:06 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B6902D18CE395; Mon, 18 Jul 2016 08:55:02 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6I8t3fK015787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 08:55:04 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6I8t0GJ020899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 10:55:02 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 10:54:51 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Jaime_Jim=E9nez?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4IzOMziR1rQe0ECS+m3saUK3wqAd2zcA///j8QCAACPQgA== Date: Mon, 18 Jul 2016 08:54:50 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1A58520207C7B64BAA0D258CC1650DD1@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" , =?iso-8859-1?Q?Christian_Ams=FCss?= Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 08:55:09 -0000 Hi Jaime, On 18/07/2016 10:46, "core on behalf of Jaime Jim=E9nez" wrote: >As Thomas pointed out, there is still time to make the changes, you can >submit a new version reflecting the late WGLC comments. OK, will do. >On 5.3. though the text could be made more clear by also pointing to the >three 5.4.1.1 examples and by editing the text on 5.3 to "/{+tu}". Agreed. Cheers, t >Ciao, >- - Jaime Jimenez > >> On 18 Jul 2016, at 10:27, Fossati, Thomas (Nokia - GB) >> wrote: >>=20 >> Hi Christian, >>=20 >> Thanks very much for reviewing the draft. It's never too late for bug >> fixing! >>=20 >> On 18/07/2016 02:38, "core on behalf of Christian Ams=FCss" >> >>wrote: >>> Hello group, >>>=20 >>> I've read through the http-mapping-12 draft, I'm curious whether I've >>> spotted a consistency error and a needless constraint in the draft, or >>> just lack understanding of the involved mechanisms: >>>=20 >>> * 5.3 Default Mapping states that "[t]he default mapping is for the >>>Target >>> CoAP URI to be appended as-is to the HC Proxy URI". Given the HC Proxy >>> URI would typically be "http://.../hc", literal appending of a CoAP >>> URI gives "http://.../hccoap://..." without a slash after "hc". In 5.5 >>> Discovery, there is a "[t]he default template given in Section 5.3, >>> i.e., {+tu}", again without a slash before it (similar with 5.5.1). As >>> 5.4 states that the URI Mapping Template is concatenated to the HC >>> Proxy URI, this would not result in a slash. (I've also checked RFC >>> 6570 URI Templates: It does not specify any concatenation operation >>> that would insert a slash.) >>>=20 >>> In another place (5.4.1.1 2.), the template of "/{+tu}" is given as a >>> default. >>>=20 >>> My interpretation of those inconsistencies is that the intention is to >>> have a default template of "/{+tu}", and that the 5.3 phrase just >>> misses mentioning the slash that comes with the default template. >>=20 >> I think you are right. >>=20 >>> * 5.5 Discovery states that when discovered via CoAP, 'the link >>> associated to the "core.hc" resource needs an explicit anchor >>> referring to the HTTP origin', resulting in a link-format of >>>=20 >>> ;anchor=3D"http://p.example.com";rt=3D"core.hc" >>>=20 >>> . While the anchor form is perfectly legal, why is it *needed*? A >>>=20 >>> ;rt=3D"core.hc" >>>=20 >>> could at worst be interpreted in a way that it is hosted by the CoAP >>> server (because "hosts" is the default rel and is the default >>> anchor), but that would go away as soon as any other rel is used by >>> the application, and I think the "http://p.example.com hosts >>> http://p.example.com/hc" statement is not really valuable. >>>=20 >>> Is there, apart from the "hosts" rel which an application might set >>> to any other value (an ext-rel-type), a reason for the "needs"? >>=20 >> My reading of RFC 6690 section 2.1: >> """ >> Each link conveys one target URI as a URI-reference inside angle >> brackets ("<>"). The context URI of a link (also called the base URI >> in [RFC3986]) is determined by the following rules in this >> specification: >>=20 >> (a) The context URI is set to the anchor parameter, when specified. >>=20 >> (b) Origin of the target URI, when specified. >>=20 >> (c) Origin of the link format resource's base URI. >>=20 >> """ >> is that we MUST force (a) because otherwise a client would use (b) which >> is clearly wrong since if the query comes from the CoAP side, the >> "specified" origin is the coap:// origin -- and we need the http:// one >> instead. >>=20 >>=20 >> (Here my assumption is that (a), (b) & (c) are in strict order, >>otherwise >> there would be no way to disambiguate situations where, for example, >>both >> (a) and (b) apply.) >>=20 >>> I know that it is late in the document process, and that neither of >>> these issues (if they are issues at all and not just my >>> misinterpretation) is likely to cause actually wrong implementations >>> (implementors that followed the letters of '{+tu}' would be likely to >>> consider /hccoap:// to be buggy and fix it the obvious way). Is there >>> something we should do about this? >>=20 >> We have to fix the slash-less {+tu} text occurrences. I'm not sure when >> -- before or during IESG review? Jaime and Carsten will surely have a >> sensible answer for this. >>=20 >> Cheers, t >>=20 >>=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 > From nobody Mon Jul 18 02:10:50 2016 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 160F612D537 for ; Mon, 18 Jul 2016 02:10:49 -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 jWMxZvEPL_6y for ; Mon, 18 Jul 2016 02:10:47 -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 BFCE612D533 for ; Mon, 18 Jul 2016 02:10:46 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id AC42742F51; Mon, 18 Jul 2016 11:10:44 +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 C33364A; Mon, 18 Jul 2016 11:10:42 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5624444; Mon, 18 Jul 2016 11:10:42 +0200 (CEST) Received: (nullmailer pid 11746 invoked by uid 1000); Mon, 18 Jul 2016 09:06:15 -0000 Date: Mon, 18 Jul 2016 11:06:15 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160718090615.GB12256@hephaistos.amsuess.com> References: <20160718003849.GC19248@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 09:10:49 -0000 --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 08:27:03AM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > > ;anchor=3D"http://p.example.com";rt=3D"core.hc" > > [...] > > ;rt=3D"core.hc" >=20 > My reading of RFC 6690 section 2.1: > """ > Each link conveys one target URI as a URI-reference inside angle > brackets ("<>"). The context URI of a link (also called the base URI > in [RFC3986]) is determined by the following rules in this > specification: > [...] > """ > is that we MUST force (a) because otherwise a client would use (b) which > is clearly wrong since if the query comes from the CoAP side, the > "specified" origin is the coap:// origin -- and we need the http:// one > instead. These bullets only give the context in the sense of base URI, which is afaict not used for anything else than relative URI expansion. If an absolute URI is given in the angular brackets, it expanding it based on any base URI always gives the given absolute URI. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjJwEAAoJEDmNERLTpL3hOtwQAI2vSfUlgrnPbSGzAzM+PsQf 1bDI87d0iT7xbqMGT5omgdD3qUPQzB63Wmar7DonrV3zQ1hQpgIbTYlB2p8GkLls RJEpTzSItedbAiXi8GUlnP4JDvI32M/TpZfFuy3qXIsJCDlUG7AoIVGA9mvJt0+S YnUIgtJO6ualJoRdckSCw4QZjpk+dZ4tWuburO2cb4ThwaGChHu1TIXtiEMYEeK9 SCLeWDWyKqbC9T8xX/RYJq54TXqF2QMV4vkQI4JqZCtrWGMMmNufECPwBHdRaAJX oUb1ukOFYrTNJQCiJidseeUk60Zm6wUhIoX2i08b8E26+GWmu+hskJ53Ts4ui+uO FD/jto/Tp6Z+PXhpBhmEAeasnwNp4jIsyCz4RD43RR+gOgr8FVTGHNQQeQT9aZpJ /tMKq+jCA5LsVpfY72eW80o/VYYeculjABcTl4frhFpGyQKy62WHJCVxDBC585Qn FtegMm9VVnefyaU81ec8mJsO5fQrX0WidDjuewLmdcVS03cPk8SjXK30WxHD5kxl 7c/F8156hd7fkCudI4LEBrPLaUfQE0wXBAeOofLSR6ziVtlqzSN3V/pEvvHo8K9L vvm6v1QyOwa24awalZUf/KYMDil+okC89dXW7FzRf507rcZwMPH3AIcFr2ib0Jzz 3+YzrpAmU1greTuqt+YP =S5bK -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From nobody Mon Jul 18 02:47:37 2016 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 C51E612D7E5 for ; Mon, 18 Jul 2016 02:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 Hu4aDZDaoQ7C for ; Mon, 18 Jul 2016 02:47:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8EFD212D629 for ; Mon, 18 Jul 2016 02:43:34 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9CE3D7F52491C; Mon, 18 Jul 2016 09:43:28 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6I9hTK0011163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 09:43:30 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6I9epGU019643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 11:43:22 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 11:39:17 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) Thread-Index: AQHR4NhAO3WSUM7yWUK2lnZ7h2obvw== Date: Mon, 18 Jul 2016 09:39:17 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718090615.GB12256@hephaistos.amsuess.com> In-Reply-To: <20160718090615.GB12256@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 09:47:31 -0000 On 18/07/2016 11:06, "core on behalf of Christian Ams=FCss" wrote: >On Mon, Jul 18, 2016 at 08:27:03AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> > ;anchor=3D"http://p.example.com";rt=3D"core.hc" >> > [...] >> > ;rt=3D"core.hc" >>=20 >> My reading of RFC 6690 section 2.1: >> """ >> Each link conveys one target URI as a URI-reference inside angle >> brackets ("<>"). The context URI of a link (also called the base URI >> in [RFC3986]) is determined by the following rules in this >> specification: >> [...] >> """ >> is that we MUST force (a) because otherwise a client would use (b) which >> is clearly wrong since if the query comes from the CoAP side, the >> "specified" origin is the coap:// origin -- and we need the http:// one >> instead. > >These bullets only give the context in the sense of base URI, which is >afaict not used for anything else than relative URI expansion. If an >absolute URI is given in the angular brackets, it expanding it based on >any base URI always gives the given absolute URI. I agree that this would be a very sensible interpretation if you put together RFC6690 and the definition of URI-Reference from RFC3986. However, RFC6690 Section 2.1 seems to override that, by defining specific rules (a-c) for defining the context URI for CoRE Link Format: "The context URI of a link (also called the base URI in [RFC3986]) is determined by the following rules **in this specification**: [...]" What do other think? Cheers, t From nobody Mon Jul 18 03:29:09 2016 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 1BF0F12D82D for ; Mon, 18 Jul 2016 03:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=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 vPC7hmA9el8T for ; Mon, 18 Jul 2016 03:29:04 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D58B012D7D9 for ; Mon, 18 Jul 2016 03:29:00 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A5F543BCAFDED; Mon, 18 Jul 2016 10:28:55 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6IASvk8016357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 10:28:57 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6IASkIk029094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 12:28:57 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 12:27:09 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Fossati, Thomas (Nokia - GB)" , =?iso-8859-1?Q?Christian_Ams=FCss?= , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4IzOMziR1rQe0ECS+m3saUK3wqAd2zcAgAAhigA= Date: Mon, 18 Jul 2016 10:27:09 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.38] Content-Type: multipart/mixed; boundary="_002_D3B278CD6D066thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 10:29:07 -0000 --_002_D3B278CD6D066thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Christian, On 18/07/2016 10:27, "core on behalf of Fossati, Thomas (Nokia - GB)" wrote: >On 18/07/2016 02:38, "core on behalf of Christian Ams=FCss" > wrote: >>Hello group, >> >>I've read through the http-mapping-12 draft, I'm curious whether I've >>spotted a consistency error and a needless constraint in the draft, or >>just lack understanding of the involved mechanisms: >> >>* 5.3 Default Mapping states that "[t]he default mapping is for the >>Target >> CoAP URI to be appended as-is to the HC Proxy URI". Given the HC Proxy >> URI would typically be "http://.../hc", literal appending of a CoAP >> URI gives "http://.../hccoap://..." without a slash after "hc". In 5.5 >> Discovery, there is a "[t]he default template given in Section 5.3, >> i.e., {+tu}", again without a slash before it (similar with 5.5.1). As >> 5.4 states that the URI Mapping Template is concatenated to the HC >> Proxy URI, this would not result in a slash. (I've also checked RFC >> 6570 URI Templates: It does not specify any concatenation operation >> that would insert a slash.) >> =20 >> In another place (5.4.1.1 2.), the template of "/{+tu}" is given as a >> default. >> >> My interpretation of those inconsistencies is that the intention is to >> have a default template of "/{+tu}", and that the 5.3 phrase just >> misses mentioning the slash that comes with the default template. > >I think you are right On second thought... I still think you are right that there is a slight incongruence in the current text. I guess the way to solve it is not to change the default template to "/{+tu}" though, but rather to append a slash to the the HC Proxy URI when needed -- that is, when the Target CoAP URI is part of the path component of the Hosting HTTP URI, and not of the query part. I have appended a diff to show what I mean. Cheers, t >>* 5.5 Discovery states that when discovered via CoAP, 'the link >> associated to the "core.hc" resource needs an explicit anchor >> referring to the HTTP origin', resulting in a link-format of >> >> ;anchor=3D"http://p.example.com";rt=3D"core.hc" >> =20 >> . While the anchor form is perfectly legal, why is it *needed*? A >> >> ;rt=3D"core.hc" >> >> could at worst be interpreted in a way that it is hosted by the CoAP >> server (because "hosts" is the default rel and is the default >> anchor), but that would go away as soon as any other rel is used by >> the application, and I think the "http://p.example.com hosts >> http://p.example.com/hc" statement is not really valuable. >> >> Is there, apart from the "hosts" rel which an application might set >> to any other value (an ext-rel-type), a reason for the "needs"? > >My reading of RFC 6690 section 2.1: >""" > Each link conveys one target URI as a URI-reference inside angle > brackets ("<>"). The context URI of a link (also called the base URI > in [RFC3986]) is determined by the following rules in this > specification: > > (a) The context URI is set to the anchor parameter, when specified. > > (b) Origin of the target URI, when specified. > > (c) Origin of the link format resource's base URI. > >""" >is that we MUST force (a) because otherwise a client would use (b) which >is clearly wrong since if the query comes from the CoAP side, the >"specified" origin is the coap:// origin -- and we need the http:// one >instead. > > >(Here my assumption is that (a), (b) & (c) are in strict order, otherwise >there would be no way to disambiguate situations where, for example, both >(a) and (b) apply.) > >>I know that it is late in the document process, and that neither of >>these issues (if they are issues at all and not just my >>misinterpretation) is likely to cause actually wrong implementations >>(implementors that followed the letters of '{+tu}' would be likely to >>consider /hccoap:// to be buggy and fix it the obvious way). Is there >>something we should do about this? > >We have to fix the slash-less {+tu} text occurrences. I'm not sure when >-- before or during IESG review? Jaime and Carsten will surely have a >sensible answer for this. > >Cheers, t > > > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core > --_002_D3B278CD6D066thomasfossatialcatellucentcom_ Content-Type: text/html; name="draft-ietf-core-http-mapping-13-from-2.diff.html" Content-Description: draft-ietf-core-http-mapping-13-from-2.diff.html Content-Disposition: attachment; filename="draft-ietf-core-http-mapping-13-from-2.diff.html"; size=34000; creation-date="Mon, 18 Jul 2016 10:27:08 GMT"; modification-date="Mon, 18 Jul 2016 10:27:08 GMT" Content-ID: <92E3217D68135741B3C494AA52B614E0@exchange.lucent.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQyOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogRGFyd2luIGJvbmdvIDE0LjUuMCBEYXJ3aW4gS2VybmVs IFZlcnNpb24gMTQuNS4wOiBNb24gSmFuIDExIDE4OjQ4OjM1IFBTVCAyMDE2OyByb290OnhudS0y NzgyLjUwLjJ+MS9SRUxFQVNFX1g4Nl82NCB4ODZfNjQgLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vz ci9sb2NhbC9iaW4vZ2F3azogR05VIEF3ayA0LjEuMSwgQVBJOiAxLjEgLS0+IAo8IS0tIFVzaW5n IGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDIuOC4xIC0tPiAKPCEt LSBVc2luZyB3ZGlmZjogL3Vzci9sb2NhbC9iaW4vd2RpZmY6IHdkaWZmIChHTlUgd2RpZmYpIDEu Mi4yIC0tPiAKPGh0bWw+IAo8aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSIgLz4gCiAgPG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRp dGxlPkRpZmY6IGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMTIudHh0IC0gZHJhZnQtaWV0 Zi1jb3JlLWh0dHAtbWFwcGluZy0xMy50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9j c3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0g CiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBmb250LWZh bWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAuODZlbTt9 IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7IGZvbnQt c2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RUVFOyB9IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlm ZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0g CiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6 ICNGRkI7IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5s aW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiBy ZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246 IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9y OiAjQUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IAog ICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5sYmxvY2sg LmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJh Y2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFE OyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogIDwvc3R5bGU+IAo8L2hlYWQ+IAo8Ym9keSA+IAog IDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0 ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRmLWNvcmUtaHR0 cC1tYXBwaW5nLTEyLnR4dCZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRm LWNvcmUtaHR0cC1tYXBwaW5nLTEzLnR4dCZuYnNwOzwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMSIg Lz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwgbGluZSAx NjwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjEiIC8+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEsIGxpbmUgMTY8L2VtPjwvdGg+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPkV4cGlyZXM6IEphbnVhcnkgMTksIDIwMTcgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPkV4cGlyZXM6IEphbnVhcnkgMTksIDIwMTcgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBSYWhtYW48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBLiBSYWhtYW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEludGVyRGlnaXRhbCBDb21tdW5pY2F0aW9ucywgTExDPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEludGVyRGlnaXRhbCBDb21tdW5pY2F0aW9ucywgTExDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRm9zc2F0aTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRm9zc2F0aTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9raWE8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFLiBEaWprPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFLiBEaWprPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGhpbGlwcyBMaWdodGlu ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGhpbGlwcyBMaWdodGluZzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMTgs IDIwMTY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMTgsIDIwMTY8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICBHdWlkZWxpbmVzIGZvciBIVFRQLXRv LUNvQVAgTWFwcGluZyBJbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgR3VpZGVsaW5lcyBmb3IgSFRUUC10by1Db0FQIE1hcHBpbmcgSW1wbGVt ZW50YXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZy0xPHNwYW4gY2xh c3M9ImRlbGV0ZSI+Mjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTE8c3BhbiBjbGFz cz0iaW5zZXJ0Ij4zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyByZWZlcmVuY2UgaW5mb3JtYXRp b24gZm9yIGltcGxlbWVudGluZyBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg VGhpcyBkb2N1bWVudCBwcm92aWRlcyByZWZlcmVuY2UgaW5mb3JtYXRpb24gZm9yIGltcGxlbWVu dGluZyBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGNyb3NzLXByb3RvY29sIG5ldHdvcmsgcHJveHkgdGhhdCBwZXJmb3JtcyB0cmFuc2xh dGlvbiBmcm9tIHRoZSBIVFRQPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY3Jv c3MtcHJvdG9jb2wgbmV0d29yayBwcm94eSB0aGF0IHBlcmZvcm1zIHRyYW5zbGF0aW9uIGZyb20g dGhlIEhUVFA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgcHJvdG9jb2wgdG8gdGhlIENvQVAgcHJvdG9jb2wuICBUaGlzIHdpbGwgZW5hYmxl IGEgSFRUUCBjbGllbnQgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm90 b2NvbCB0byB0aGUgQ29BUCBwcm90b2NvbC4gIFRoaXMgd2lsbCBlbmFibGUgYSBIVFRQIGNsaWVu dCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBhY2Nlc3MgcmVzb3VyY2VzIG9uIGEgQ29BUCBzZXJ2ZXIgdGhyb3VnaCB0aGUgcHJveHku ICBUaGlzIGRvY3VtZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWNjZXNz IHJlc291cmNlcyBvbiBhIENvQVAgc2VydmVyIHRocm91Z2ggdGhlIHByb3h5LiAgVGhpcyBkb2N1 bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBkZXNjcmliZXMgaG93IGEgSFRUUCByZXF1ZXN0IGlzIG1hcHBlZCB0byBhIENvQVAgcmVx dWVzdCwgYW5kIHRoZW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmli ZXMgaG93IGEgSFRUUCByZXF1ZXN0IGlzIG1hcHBlZCB0byBhIENvQVAgcmVxdWVzdCwgYW5kIHRo ZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgaG93IGEgQ29BUCByZXNwb25zZSBpcyBtYXBwZWQgYmFjayB0byBhIEhUVFAgcmVzcG9uc2Uu ICBUaGlzIGluY2x1ZGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaG93IGEg Q29BUCByZXNwb25zZSBpcyBtYXBwZWQgYmFjayB0byBhIEhUVFAgcmVzcG9uc2UuICBUaGlzIGlu Y2x1ZGVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGd1aWRlbGluZXMgZm9yIFVSSSBtYXBwaW5nLCBtZWRpYSB0eXBlIG1hcHBpbmcgYW5k IGFkZGl0aW9uYWwgcHJveHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBndWlk ZWxpbmVzIGZvciBVUkkgbWFwcGluZywgbWVkaWEgdHlwZSBtYXBwaW5nIGFuZCBhZGRpdGlvbmFs IHByb3h5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwy IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA5LCBsaW5l IDU8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyIiAvPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA5LCBsaW5lIDU8L2VtPjwvdGg+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdpbGwgZGV0ZXJtaW5lIHRocm91Z2ggaXRzIG93biBwcm9w cmlldGFyeSBhbGdvcml0aG1zIHdoYXQgdGhlIFRhcmdldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHdpbGwgZGV0ZXJtaW5lIHRocm91Z2ggaXRzIG93biBwcm9wcmlldGFyeSBh bGdvcml0aG1zIHdoYXQgdGhlIFRhcmdldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb0FQIFVSSSBzaG91bGQgYmUuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29BUCBVUkkgc2hvdWxkIGJlLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+NS4zLiAgRGVmYXVsdCBNYXBwaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+NS4zLiAgRGVmYXVsdCBNYXBwaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBUaGUgZGVmYXVsdCBtYXBwaW5nIGlzIGZvciB0aGUgVGFyZ2V0IENvQVAgVVJJIHRv IGJlIGFwcGVuZGVkIGFzLWlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhl IGRlZmF1bHQgbWFwcGluZyBpcyBmb3IgdGhlIFRhcmdldCBDb0FQIFVSSSB0byBiZSBhcHBlbmRl ZCBhcy1pczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0byB0aGUgSEMgUHJveHkgVVJJLCB0byBmb3JtIHRoZSBIb3N0aW5nIEhUVFAgVVJJ LiAgVGhpcyBpcyB0aGUgVVJJPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8g dGhlIEhDIFByb3h5IFVSSSwgdG8gZm9ybSB0aGUgSG9zdGluZyBIVFRQIFVSSS4gIFRoaXMgaXMg dGhlIFVSSTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0aGF0IHdpbGwgdGhlbiBiZSBzZW50IGJ5IHRoZSBIVFRQIGNsaWVudCBpbiB0aGUg SFRUUCByZXF1ZXN0IHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRo YXQgd2lsbCB0aGVuIGJlIHNlbnQgYnkgdGhlIEhUVFAgY2xpZW50IGluIHRoZSBIVFRQIHJlcXVl c3QgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEhDIHByb3h5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhD IHByb3h5LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDAyIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgRm9yIGV4YW1wbGU6IGdpdmVuIGEgSEMgUHJv eHkgVVJJIGh0dHA6Ly9wLmV4YW1wbGUuY29tL2hjIGFuZCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIEZvciBleGFtcGxlOiBnaXZlbiBhIEhDIFByb3h5IFVSSSBodHRwOi8v cC5leGFtcGxlLmNvbS9oYzxzcGFuIGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+IGFuZCBhPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhcmdl dCBDb0FQIFVSSSBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodCwgdGhlIHJlc3VsdGluZyBIb3N0 aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGFyZ2V0IENvQVAgVVJJIGNv YXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0LCB0aGUgcmVzdWx0aW5nIEhvc3Rpbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSFRUUCBVUkkg d291bGQgYmUgaHR0cDovL3AuZXhhbXBsZS5jb20vaGMvY29hcDovL3MuZXhhbXBsZS5jb20vbGln aHQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSFRUUCBVUkkgd291bGQgYmUg aHR0cDovL3AuZXhhbXBsZS5jb20vaGMvY29hcDovL3MuZXhhbXBsZS5jb20vbGlnaHQuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm92aWRlZCBhIGNvcnJlY3QgVGFyZ2V0IENvQVAg VVJJLCB0aGUgSG9zdGluZyBIVFRQIFVSSSByZXN1bHRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBQcm92aWRlZCBhIGNvcnJlY3QgVGFyZ2V0IENvQVAgVVJJLCB0aGUgSG9z dGluZyBIVFRQIFVSSSByZXN1bHRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZnJvbSB0aGUgZGVmYXVsdCBtYXBwaW5nIGlzIGFsd2F5 cyBzeW50YWN0aWNhbGx5IGNvcnJlY3QuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZnJvbSB0aGUgZGVmYXVsdCBtYXBwaW5nIGlzIGFsd2F5cyBzeW50YWN0aWNhbGx5IGNvcnJl Y3QuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEZ1cnRoZXJtb3JlLCB0aGUgVGFyZ2V0IENvQVAgVVJJIGNhbiBhbHdheXMgYmUgZXh0cmFj dGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRnVydGhlcm1vcmUsIHRoZSBU YXJnZXQgQ29BUCBVUkkgY2FuIGFsd2F5cyBiZSBleHRyYWN0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdW5hbWJpZ3VvdXNseSBmcm9t IHRoZSBIb3N0aW5nIEhUVFAgVVJJLiAgQWxzbywgaXQgaXMgd29ydGggbm90aW5nPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdW5hbWJpZ3VvdXNseSBmcm9tIHRoZSBIb3N0aW5n IEhUVFAgVVJJLiAgQWxzbywgaXQgaXMgd29ydGggbm90aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoYXQsIHVzaW5nIHRoZSBkZWZh dWx0IG1hcHBpbmcsIGEgcXVlcnkgY29tcG9uZW50IGluIHRoZSB0YXJnZXQgQ29BUDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYXQsIHVzaW5nIHRoZSBkZWZhdWx0IG1hcHBp bmcsIGEgcXVlcnkgY29tcG9uZW50IGluIHRoZSB0YXJnZXQgQ29BUDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXNvdXJjZSBVUkkgaXMg bmF0dXJhbGx5IGVuY29kZWQgaW50byB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlc291cmNlIFVSSSBpcyBuYXR1cmFsbHkgZW5j b2RlZCBpbnRvIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEhvc3RpbmcgVVJJLCBlLmcuOiBj b2FwOi8vcy5leGFtcGxlLmNvbS9saWdodD9kaW09NSBiZWNvbWVzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgSG9zdGluZyBVUkksIGUuZy46IGNvYXA6Ly9zLmV4YW1wbGUuY29t L2xpZ2h0P2RpbT01IGJlY29tZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxh IG5hbWU9InBhcnQtbDMiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVt PiBwYWdlIDE0LCBsaW5lIDEwPC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1y MyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTQsIGxp bmUgMTA8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFRoZSBmaXJzdCBleGFt cGxlIGV4ZXJjaXNlcyB0aGUgQ29BUCBpbnRlcmZhY2UsIGFuZCBhc3N1bWVzIHRoYXQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBUaGUgZmlyc3QgZXhhbXBsZSBleGVyY2lz ZXMgdGhlIENvQVAgaW50ZXJmYWNlLCBhbmQgYXNzdW1lcyB0aGF0PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRoZSBkZWZhdWx0IHRl bXBsYXRlLCB7K3R1fSwgaXMgdXNlZC4gIEZvciBleGFtcGxlLCBpbiB1c2UgY2FzZSAjMzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHRoZSBkZWZhdWx0IHRlbXBsYXRlLCB7 K3R1fSwgaXMgdXNlZC4gIEZvciBleGFtcGxlLCBpbiB1c2UgY2FzZSAjMzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBpbiBzZWN0aW9u IFNlY3Rpb24gNCwgdGhlIHNtYXJ0cGhvbmUgbWF5IGRpc2NvdmVyIHRoZSBwdWJsaWMgSEM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBpbiBzZWN0aW9uIFNlY3Rpb24gNCwg dGhlIHNtYXJ0cGhvbmUgbWF5IGRpc2NvdmVyIHRoZSBwdWJsaWMgSEM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcHJveHkgYmVmb3Jl IGxlYXZpbmcgdGhlIGhvbWUgbmV0d29yay4gIFRoZW4gd2hlbiBvdXRzaWRlIHRoZSBob21lPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgcHJveHkgYmVmb3JlIGxlYXZpbmcg dGhlIGhvbWUgbmV0d29yay4gIFRoZW4gd2hlbiBvdXRzaWRlIHRoZSBob21lPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIG5ldHdvcmss IHRoZSBzbWFydHBob25lIHdpbGwgYmUgYWJsZSB0byBxdWVyeSB0aGUgYXBwcm9wcmlhdGUgaG9t ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIG5ldHdvcmssIHRoZSBzbWFy dHBob25lIHdpbGwgYmUgYWJsZSB0byBxdWVyeSB0aGUgYXBwcm9wcmlhdGUgaG9tZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBzZW5z b3IuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgc2Vuc29yLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlcTogIEdFVCBjb2FwOi8vW2ZmMDI6OjFdLy53 ZWxsLWtub3duL2NvcmU/cnQ9Y29yZS5oYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICBSZXE6ICBHRVQgY29hcDovL1tmZjAyOjoxXS8ud2VsbC1rbm93bi9jb3JlP3J0PWNv cmUuaGM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBSZXM6ICAyLjA1IENvbnRl bnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVzOiAgMi4wNSBDb250 ZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg ICAgICAmbHQ7L2hjJmd0OzthbmNob3I9Imh0dHA6Ly9wLmV4YW1wbGUuY29tIjtydD0iY29yZS5o YyI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICZsdDsvaGM8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4vPC9zcGFuPiZndDs7YW5jaG9yPSJodHRwOi8vcC5leGFtcGxl LmNvbSI7cnQ9ImNvcmUuaGMiPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBUaGUg c2Vjb25kIGV4YW1wbGUgLSBhbHNvIG9uIHRoZSBDb0FQIHNpZGUgb2YgdGhlIEhDIHByb3h5IC0g dXNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIFRoZSBzZWNvbmQgZXhh bXBsZSAtIGFsc28gb24gdGhlIENvQVAgc2lkZSBvZiB0aGUgSEMgcHJveHkgLSB1c2VzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGEg Y3VzdG9tIHRlbXBsYXRlLCBpLmUuLCBvbmUgd2hlcmUgdGhlIENvQVAgVVJJIGlzIGNhcnJpZWQg aW5zaWRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYSBjdXN0b20gdGVt cGxhdGUsIGkuZS4sIG9uZSB3aGVyZSB0aGUgQ29BUCBVUkkgaXMgY2FycmllZCBpbnNpZGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg dGhlIHF1ZXJ5IGNvbXBvbmVudCwgdGh1cyB0aGUgcmV0dXJuZWQgbGluayBjYXJyaWVzIHRoZSBV Ukk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0aGUgcXVlcnkgY29tcG9u ZW50LCB0aHVzIHRoZSByZXR1cm5lZCBsaW5rIGNhcnJpZXMgdGhlIFVSSTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0ZW1wbGF0ZSB0 byBiZSB1c2VkIGluIGFuIGV4cGxpY2l0ICJoY3QiIGF0dHJpYnV0ZTo8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0ZW1wbGF0ZSB0byBiZSB1c2VkIGluIGFuIGV4cGxpY2l0 ICJoY3QiIGF0dHJpYnV0ZTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBSZXE6 ICBHRVQgY29hcDovL1tmZjAyOjoxXS8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUuaGM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVxOiAgR0VUIGNvYXA6Ly9bZmYwMjo6 MV0vLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgUmVzOiAgMi4wNSBDb250ZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgIFJlczogIDIuMDUgQ29udGVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgJmx0Oy9oYyZndDs7YW5jaG9y PSJodHRwOi8vcC5leGFtcGxlLmNvbSI7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICZsdDsvaGMmZ3Q7O2FuY2hvcj0iaHR0cDovL3AuZXhhbXBsZS5jb20iOzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNCIgLz48c21h bGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTQsIGxpbmUgMzU8L2Vt PjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI0IiAvPjxzbWFsbD5za2lwcGluZyB0 byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxNCwgbGluZSAzNTwvZW0+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIHVzaW5n IHRoZSAnYXBwbGljYXRpb24vbGluay1mb3JtYXQnIGNvbnRlbnQgdHlwZTo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICB1c2luZyB0aGUgJ2FwcGxpY2F0aW9uL2xpbmstZm9y bWF0JyBjb250ZW50IHR5cGU6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgUmVx OiAgR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUuaGMgSFRUUC8xLjE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVxOiAgR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0 PWNvcmUuaGMgSFRUUC8xLjE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgIEhvc3Q6IHAuZXhhbXBsZS5jb208L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgSG9zdDogcC5leGFtcGxlLmNvbTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlczogIEhUVFAvMS4xIDIwMCBPSzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBSZXM6ICBIVFRQLzEuMSAyMDAg T0s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vbGluay1mb3JtYXQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi9saW5rLWZvcm1hdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgQ29udGVudC1MZW5ndGg6IDE4PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgIENvbnRlbnQtTGVuZ3RoOiAxODwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA0IiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICZsdDsvaGMmZ3Q7O3J0PSJjb3JlLmhjIjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgJmx0Oy9oYzxzcGFu IGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+Jmd0OztydD0iY29yZS5oYyI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG8gIHVzaW5nIHRoZSAnYXBwbGljYXRpb24vbGluay1mb3JtYXQranNv bicgY29udGVudCB0eXBlIGFzIGRlZmluZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvICB1c2luZyB0aGUgJ2FwcGxpY2F0aW9uL2xpbmstZm9ybWF0K2pzb24nIGNvbnRlbnQg dHlwZSBhcyBkZWZpbmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIGluIFtJLUQuaWV0Zi1jb3JlLWxpbmtzLWpzb25dOjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGluIFtJLUQuaWV0Zi1jb3JlLWxpbmtzLWpz b25dOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlcTogIEdFVCAvLndlbGwt a25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgIFJlcTogIEdFVCAvLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAv MS4xPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICBIb3N0OiBwLmV4YW1wbGUuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgIEhvc3Q6IHAuZXhhbXBsZS5jb208L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICBSZXM6ICBIVFRQLzEuMSAyMDAgT0s8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVzOiAgSFRUUC8xLjEgMjAwIE9LPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2xpbmstZm9ybWF0K2pzb248L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9s aW5rLWZvcm1hdCtqc29uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICBDb250ZW50LUxlbmd0aDogMzE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgQ29udGVudC1MZW5ndGg6IDMxPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDUiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgW3siaHJlZiI6Ii9oYyIsInJ0IjoiY29yZS5oYyJ9 XTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgW3siaHJlZiI6 Ii9oYzxzcGFuIGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+IiwicnQiOiJjb3JlLmhjIn1dPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICB1c2luZyB0aGUgTGluayBoZWFkZXI6PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgdXNpbmcgdGhlIExpbmsgaGVhZGVyOjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlcTogIEdFVCAvLndlbGwta25vd24v Y29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgIFJlcTogIEdFVCAvLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICBIb3N0OiBwLmV4YW1wbGUuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgIEhvc3Q6IHAuZXhhbXBsZS5jb208L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICBSZXM6ICBIVFRQLzEuMSAyMDAgT0s8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgUmVzOiAgSFRUUC8xLjEgMjAwIE9LPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAwNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICBMaW5rOiAmbHQ7L2hjJmd0 OztydD0iY29yZS5oYyI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAg ICAgIExpbms6ICZsdDsvaGM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4vPC9zcGFuPiZndDs7cnQ9ImNv cmUuaGMiPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgTWVkaWEgVHlwZSBNYXBwaW5n PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIE1lZGlhIFR5cGUgTWFwcGluZzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4xLiAgT3ZlcnZpZXc8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij42LjEuICBPdmVydmlldzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQSBIQyBwcm94eSBuZWVkcyB0byB0cmFuc2xhdGUgSFRUUCBtZWRpYSB0eXBlcyAoU2Vj dGlvbiAzLjEuMS4xIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSBIQyBw cm94eSBuZWVkcyB0byB0cmFuc2xhdGUgSFRUUCBtZWRpYSB0eXBlcyAoU2VjdGlvbiAzLjEuMS4x IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtSRkM3MjMxXSkgYW5kIGNvbnRlbnQgZW5jb2RpbmdzIChTZWN0aW9uIDMuMS4yLjIgb2Yg W1JGQzcyMzFdKSBpbnRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzcy MzFdKSBhbmQgY29udGVudCBlbmNvZGluZ3MgKFNlY3Rpb24gMy4xLjIuMiBvZiBbUkZDNzIzMV0p IGludG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQ29BUCBjb250ZW50IGZvcm1hdHMgKFNlY3Rpb24gMTIuMyBvZiBbUkZDNzI1Ml0pIGFu ZCB2aWNlIHZlcnNhLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvQVAgY29u dGVudCBmb3JtYXRzIChTZWN0aW9uIDEyLjMgb2YgW1JGQzcyNTJdKSBhbmQgdmljZSB2ZXJzYS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1lZGlhIHR5cGUgdHJhbnNsYXRpb24gY2Fu IGhhcHBlbiBpbiBHRVQsIFBVVCBvciBQT1NUIHJlcXVlc3RzIGdvaW5nPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgTWVkaWEgdHlwZSB0cmFuc2xhdGlvbiBjYW4gaGFwcGVuIGlu IEdFVCwgUFVUIG9yIFBPU1QgcmVxdWVzdHMgZ29pbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRk PjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDUiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDMyLCBsaW5lIDE0PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEg bmFtZT0icGFydC1yNSIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMzIsIGxpbmUgMTQ8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNzM5MF0gIFJhaG1hbiwgQS4sIEVkLiBhbmQg RS4gRGlqaywgRWQuLCAiR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3I8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBbUkZDNzM5MF0gIFJhaG1hbiwgQS4sIEVkLiBhbmQgRS4gRGlqaywg RWQuLCAiR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICB0aGUgQ29uc3RyYWluZWQg QXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIiwgUkZDIDczOTAsPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24g UHJvdG9jb2wgKENvQVApIiwgUkZDIDczOTAsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzcz OTAsIE9jdG9iZXIgMjAxNCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3MzkwLCBPY3RvYmVyIDIwMTQsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0 O2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MzkwJmd0Oy48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICZsdDtodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2luZm8vcmZjNzM5MCZndDsuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BcHBl bmRpeCBBLiAgQ2hhbmdlIExvZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFwcGVu ZGl4IEEuICBDaGFuZ2UgTG9nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbTm90ZSB0 byBSRkMgRWRpdG9yOiBQbGVhc2UgcmVtb3ZlIHRoaXMgc2VjdGlvbiBiZWZvcmUgcHVibGljYXRp b24uXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtOb3RlIHRvIFJGQyBFZGl0 b3I6IFBsZWFzZSByZW1vdmUgdGhpcyBzZWN0aW9uIGJlZm9yZSBwdWJsaWNhdGlvbi5dPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4g Y2xhc3M9Imluc2VydCI+Q2hhbmdlcyBmcm9tIGlldGYtMTIgdG8gaWV0Zi0xMyAoQ2hyaXN0aWFu IEFtc3VzcycgY29tbWVudHMpOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBvICBNb3JlIG1pc3Npbmcgc2xhc2hlcyBp biBVUkkgbWFwcGluZyB0ZW1wbGF0ZSBleGFtcGxlcy48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2hhbmdlcyBmcm9tIGlldGYtMTEgdG8g aWV0Zi0xMiAoMm5kIFdHTEMpOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENo YW5nZXMgZnJvbSBpZXRmLTExIHRvIGlldGYtMTIgKDJuZCBXR0xDKTo8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG8gIEFkZHJlc3NlZCBhIGZldyBlZGl0b3JpYWwgaXNzdWVzIChpbmNs dWRpbmcgYSBjbGFyaWZpY2F0aW9uIG9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbyAgQWRkcmVzc2VkIGEgZmV3IGVkaXRvcmlhbCBpc3N1ZXMgKGluY2x1ZGluZyBhIGNsYXJp ZmljYXRpb24gb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgd2hlbiB0byB1c2UgcXEgdnMgcSBpbiB0aGUgVVJJIG1hcHBpbmcgdGVt cGxhdGUpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHdoZW4gdG8gdXNl IHFxIHZzIHEgaW4gdGhlIFVSSSBtYXBwaW5nIHRlbXBsYXRlKS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIG8gIEZpeGVkIG1pc3Npbmcgc2xhc2ggaW4gb25lIHRlbXBsYXRlIGV4YW1w bGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgRml4ZWQgbWlzc2luZyBz bGFzaCBpbiBvbmUgdGVtcGxhdGUgZXhhbXBsZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG8gIEFkZGVkIHBhcmEgYWJvdXQgdGhlIG5lZWQgZm9yIGZ1dHVyZSBDb0FQIHByb3RvY29s IGVsZW1lbnRzIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgQWRkZWQg cGFyYSBhYm91dCB0aGUgbmVlZCBmb3IgZnV0dXJlIENvQVAgcHJvdG9jb2wgZWxlbWVudHMgdG88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgZGVmaW5lIHRoZWlyIG93biBIVFRQIG1hcHBpbmdzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIGRlZmluZSB0aGVpciBvd24gSFRUUCBtYXBwaW5ncy48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBiZ2Nv bG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+PGEgbmFtZT0iZW5kIj4m bmJzcDtFbmQgb2YgY2hhbmdlcy4gNyBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvYT48L3RoPjwvdHI+ CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjYgbGluZXMgY2hhbmdlZCBv ciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MTAgbGluZXMgY2hhbmdl ZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1 IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYgd2FzIHBy b2R1Y2VkIGJ5IHJmY2RpZmYgMS40Mi4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBm cm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi8iID5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90 YWJsZT4KICAgPC9ib2R5PgogICA8L2h0bWw+Cg== --_002_D3B278CD6D066thomasfossatialcatellucentcom_-- From nobody Mon Jul 18 06:32:52 2016 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 27E1E12DD73 for ; Mon, 18 Jul 2016 06:32:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718133251.24902.13465.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 06:32:51 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 13:32:51 -0000 Changed milestone "Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG", set due date to July 2016 from January 2014. Changed milestone "Representing CoRE Link Collections in JSON submitted to IESG", set due date to August 2016 from January 2014. Changed milestone "CoRE Interfaces submitted to IESG", set due date to March 2017 from May 2014. URL: https://datatracker.ietf.org/wg/core/charter/ From nobody Mon Jul 18 06:46:00 2016 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 48C9812DE76; Mon, 18 Jul 2016 06:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCHF_ERJ4E7p; Mon, 18 Jul 2016 06:45:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C9F12DABD; Mon, 18 Jul 2016 06:24:12 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-d5-578ccda91d4e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.F2.03614.AADCC875; Mon, 18 Jul 2016 14:38:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 08:39:11 -0400 From: Suresh Krishnan To: Internet Area , "iot-dir@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org>, "core@ietf.org" , "its@ietf.org" , "lpwan@ietf.org" , "roll@ietf.org" Thread-Topic: AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AdHg8WGWoPnMMjhNT2ePkXbsiQk/9Q== Date: Mon, 18 Jul 2016 12:39:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPoO6qsz3hBmveClk0TxGwWHa3j9li 39v1zBY3Zt1ksZj/fB2zxcX571gsZpw7wmrRdFnAgcNjyZKfTAGMUVw2Kak5mWWpRfp2CVwZ ez+9ZS5oY604tHAZYwNjB0sXIyeHhICJxJ99J5ggbDGJC/fWs3UxcnEICRxllNjU0MwO4Sxn lDj57BVYFRtQx4adn5lAEiICLUwS+5qOMYIkhAUMJT6ducoGYosImEmsaH8OZetJzPnZCNbM IqAqMen0LlYQm1fAV6L/2AKwMxiBVn8/tQashllAXOLWk/lQJwlILNlznhnCFpV4+fgfK4St JPHx93x2iHodiQW7P7FB2NoSyxa+ZoaYLyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYuQo LS7IyU03MtzECIyHYxJsjjsY9/Z6HmIU4GBU4uFdcLw7XIg1say4MvcQowQHs5II7+fTPeFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUaGMOOaK/vfJLd f8RErPVOMd/+ee+mJ/wr4dVpT1sc6flq3ebHzeEL76cwNVrmTBFhjDaKu5x7rehuZcni19ZH uvfPWPrq3DUfgYM93MWlrjpyK97UaUw3Nl5b3PHCYvbHvuSfi385iB3mFvV3/r3SL6/LNfd/ bKOxcMMssdSKvh6z1NW/JC/vUWIpzkg01GIuKk4EALDwpz2DAgAA Archived-At: Subject: [core] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 13:45:52 -0000 Hi all,=0A= I am considering AD sponsoring the following draft=0A= =0A= https://tools.ietf.org/html/draft-kivinen-802-15-ie-02=0A= =0A= to request the allocation of an 802.15.4 information element from the IEEE = =0A= for use in the IETF protocols that may need it. If you have any concerns = =0A= either with the content of the draft or about requesting the IE at all plea= se =0A= let me know before 2016/07/29.=0A= =0A= Thanks=0A= Suresh=0A= =0A= NOTE: I have CCed: all the groups that I thought could be potentially =0A= interested in this work. If you think I have missed out some WG(s) please l= et =0A= me know.=0A= From nobody Mon Jul 18 06:59:24 2016 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 CAB0C12E04F for ; Mon, 18 Jul 2016 06:59:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718135923.24917.79405.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 06:59:23 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 13:59:24 -0000 Changed milestone "Patch and Fetch Methods for CoAP submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "CoRE Resource Directory submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "CoAP over TCP, TLS, and WebSockets submitted to IESG for PS", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/core/charter/ From nobody Mon Jul 18 07:03:13 2016 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 6ED0412E0A0 for ; Mon, 18 Jul 2016 07:03:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718140312.24834.14760.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 07:03:12 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 14:03:12 -0000 Changed milestone "WG adoption for Management over CoAP", set state to active from review, accepting new milestone. Changed milestone "CBOR Encoding of Data Modeled with YANG submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Management over CoAP submitted to IESG for PS", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/core/charter/ From nobody Mon Jul 18 08:36:57 2016 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 A617812DBA2 for ; Mon, 18 Jul 2016 08:36:53 -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 ZAGnFL3LNvmV for ; Mon, 18 Jul 2016 08:36:52 -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 8200712DBD6 for ; Mon, 18 Jul 2016 08:23:03 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1BE3342FC9; Mon, 18 Jul 2016 17:23:02 +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 461B81C5; Mon, 18 Jul 2016 17:23:00 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F258C44; Mon, 18 Jul 2016 17:22:59 +0200 (CEST) Received: (nullmailer pid 15012 invoked by uid 1000); Mon, 18 Jul 2016 15:22:57 -0000 Date: Mon, 18 Jul 2016 17:22:57 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160718152257.GB7974@hephaistos.amsuess.com> References: <20160718003849.GC19248@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 15:36:53 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 10:27:09AM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > On second thought... I still think you are right that there is a slight > incongruence in the current text. I guess the way to solve it is not to > change the default template to "/{+tu}" though, but rather to append a > slash to the the HC Proxy URI when needed -- that is, when the Target CoAP > URI is part of the path component of the Hosting HTTP URI, and not of the > query part. Well, both do work, either a slash after the default proxy HC Proxy URI or one before the default URI Mapping template. If we go for the latter (as you suggested the patch), at the very least 5.4.1.1 2. must be changed to say '{+tu}' in the first line. The examples taken literally don't need changing because they give an explicit HC Proxy URI in the introduction, but I think it is a confusing example then to use '/hc' as Proxy URI, either change all examples to the default or take a different name altogether. (In the latter case, not that example 1 becomes '.../hc/?target_uri...'; same for the 5.4.2.1 examples. Further, 5.5.1 needs updating in the first and second examples too in the same spirit. I don't see reasons to not consent to any of the forms, but have a gut feeling that I like '/{+tu}' better. Cheers Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjPRGAAoJEDmNERLTpL3hRfMQAMbUTPNtiAYIJZI9Nx9ZrCZ3 Zm9pfKUVxj/Ad6lc5Fp19F8U2fSn56ojOVSwS4P+qysDMufbhTO33ApA7FexFmCQ +w8lPNHJD38ob/W8QlApX3X+qapEDIfUGGpWKceqLzi0YoIzB1CgPcwTYm4C9OTK Uv0GtgxJV1b104qW3XsYPW8l+gr999zyHnq2vLLx6hrTwQJ2YL1Ku300rThPvGfa kiF1yXU0cBvPPEVy+R/z8+XxJhPKv3lk/fUMagvv5qjDx6DIn28iDme0J6xk63ea SEde6dMlgxz3X7pL2kJJJjDorI/kBEeqTLV614HpRMNy7l5qOZMXstoXCPIUnOJ6 o2+wvsP6iLDajc7TpyrHN2NNrgEOQb431Pcw2aI5+703K5IubdOgqBWzxuoZnzSM BxnCH25jNAgcYKWbZD3rv9fZZc1igHGgGYFR3IVsJc7tTjQnQFnqTX5UYIRpq/HC t1/SsGs9KigMrL1wX67D9mVG9sbChw+C4OQwJQgedbTvCKNhdKq59MEgcub9oFZC g/b3kDfiBtPlrdeJQIUy46Rb0UlnwXIVtwggpfs04j4ibOGDa+NNpwwxOh7vTKlM r0HFl9iqkfhQHrY0LOF4jsI2PXeKMwHjDX7L84d+bkLFKdWTcgdxr2RgAnOrMD8L nCZf4YG0K/L972L/3GUb =x0X0 -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From nobody Mon Jul 18 09:26:13 2016 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 EE59612DA2D for ; Mon, 18 Jul 2016 09:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2YmdFgxudiov for ; Mon, 18 Jul 2016 09:26:09 -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 B3C9B12DA7A for ; Mon, 18 Jul 2016 09:26:08 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DFD0342FD1; Mon, 18 Jul 2016 18:26:06 +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 08EBF4A; Mon, 18 Jul 2016 18:26:06 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id ADFD244; Mon, 18 Jul 2016 18:26:05 +0200 (CEST) Received: (nullmailer pid 25854 invoked by uid 1000); Mon, 18 Jul 2016 16:26:03 -0000 Date: Mon, 18 Jul 2016 18:26:03 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20160718162603.GA8099@hephaistos.amsuess.com> References: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> <20160717232159.GA12256@hephaistos.amsuess.com> <36F8FBDB-E334-4B87-8DAD-634DAD566015@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <36F8FBDB-E334-4B87-8DAD-634DAD566015@gmail.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-lin?= =?utf-8?q?ks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 16:26:11 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Michael, (Context for the rest of the mailing list: We've just spent >2h trying to figure out how to save JSON-LD-ability of the draft, and came up with an almost viable solution that would allow not only semantic interpretation of the link-format but also CURIEs in there.) On Mon, Jul 18, 2016 at 08:51:50AM +0200, Michael Koster wrote: > I don't think it was fully resolved, and would like to continue the discu= ssion. when I was writing up the results of our session, I noticed two possibly critical issues: * If we translate 'core.s' to 'core:s' for currie-ability, the back-conversion is not given. We could attempt something like 'if there is exactly one colon and no slash in the URI' (which is bad by itself), but even that would have at least theoretical non-roundtrippabilities. * In JSON-LD documents that are lists, there can't be a common context without wrapping the whole document in a {"@context":..., "@graph":DATA} container -- otherwise, the @context (in which we'd store any information obtained from a ;rel=3D"curie"; curie=3D"foaf") would need to be duplicated for every entry in the list (see JSON-LD example 51[1]). The only workaround I'd see is to rely entirely on the default context to provide CURIEs for all registered prefixes. To you have thoughts on how we could fix that? I'm all for keeping trying to find a working solution, but if that gets worse, we should consider defining an RDF mapping of link-format that is not coupled to links-json. Until later Christian [1] http://www.w3.org/TR/json-ld/#named-graphs --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjQMYAAoJEDmNERLTpL3hUd4QAMTq0+AxmrG3RigklhF/m/yF 6xY3edN3DDg30KvZWItrdagd/dx6ycY2hZmRJgqIQvSTqwT8VDYhM3tktN5nscxd ZQZJgLqS9qqr33DYUAr9e4RRJ8/D38leXqYPDHCmxiEyla9jOe/0t9uM9ITqlPV1 Nboyq0FEMM3uKH412GAW7pzp2K/zj41lKSYi5dHaJxdNfcWVEFmiZ2mRQejSI9yi yKzvbSVV8QHpxR3YX6yKzM9ewfzDnGvdmy38mdQ3h6vzzxVZlA67PrMBgNz1WEe2 DJXfAPwv1eMkJjVGjL78vTxL5dnJvvPB4XUyPIjsj/ztE9FmjJQQMD/YSZNRWTnu 8myZ5WLCy4yj8ABmIrQPUzwRQLnQdzk91DeAUt72blYa1yYZFVwyIepmWWGn6uMr Y1UOEevfPcDZXfKKjNaetraNshddPU4IRKgK9WMUSRrA1IBF3dJ4hZZowfU/lkql sZ9BZJiBwIf6QNsvFyFmiuug1XiNUt0e7TGGtxT/CxAz2NIvukFJYQkBXZAjdRHi W8GKpQOI0laZWtKZ8OUN+PznraF48m3smBvs1SPZRuDA5i8q4zV+s/I2NiVzEY85 N04hLC7E7vfnLW4MBsDBzRUySWTtxKf4drXA2NkdJ65DsLGBXP6HIpQW4RyBc9jI 7jO1bBmTlscnv19RThX3 =W00T -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From nobody Mon Jul 18 09:52:13 2016 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 2B7BC12B074 for ; Mon, 18 Jul 2016 09:52:12 -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 LM3BLku_np2W for ; Mon, 18 Jul 2016 09:52:10 -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 3E2D41288B8 for ; Mon, 18 Jul 2016 09:52:10 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:880d:2c5e:319d:b948]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1F2501720AC; Mon, 18 Jul 2016 18:52:07 +0200 (CEST) Message-ID: <578D0937.2020104@tzi.org> Date: Mon, 18 Jul 2016 18:52:07 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: =?UTF-8?B?SmFpbWUgSmltw6luZXo=?= References: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> In-Reply-To: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-lin?= =?utf-8?q?ks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 16:52:12 -0000 It may be a bit unusual for an author to send WGLC comments, but I do have three: -- We could use the same three-part CDDL structure that we used in SenML for covering both JSON and CBOR with the same main CDDL spec. (This would also provide an opportunity to fix a bug with the Figure 2 [finding which is left as an exercise to the reader].) -- We need to ask IANA for Content-Format numbers for the two new media types. No idea how this got lost... -- I agree that we should not claim to have solved JSON-LD interworking; maybe we should simply remove some of the material that goes beyond objectives 1 and 2 in section 1.1, because these are really the ones we did focus on. Grüße, Carsten From nobody Mon Jul 18 10:05:04 2016 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 1781A12D53D for ; Mon, 18 Jul 2016 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 7xwSWqyQa_2o for ; Mon, 18 Jul 2016 10:05:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 CC96D1288B8 for ; Mon, 18 Jul 2016 10:05:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A27DFEF2BE9CC; Mon, 18 Jul 2016 17:04:55 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6IH4wmY027522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 17:04:58 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6IH4v8v020651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 19:04:58 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 19:04:57 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4IzOMziR1rQe0ECS+m3saUK3wqAd2zcAgAAhigCAADEkgIAAJBoA Date: Mon, 18 Jul 2016 17:04:57 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718152257.GB7974@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <49B44C0BCAFAB04A986C1285BE35ECA5@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 17:05:03 -0000 On 18/07/2016 17:22, "Christian Ams=FCss" wrote: >On Mon, Jul 18, 2016 at 10:27:09AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> On second thought... I still think you are right that there is a slight >> incongruence in the current text. I guess the way to solve it is not to >> change the default template to "/{+tu}" though, but rather to append a >> slash to the the HC Proxy URI when needed -- that is, when the Target >>CoAP >> URI is part of the path component of the Hosting HTTP URI, and not of >>the >> query part. > >Well, both do work, either a slash after the default proxy HC Proxy URI >or one before the default URI Mapping template. If we go for the latter >(as you suggested the patch), at the very least 5.4.1.1 2. must be >changed to say '{+tu}' in the first line. The examples taken literally >don't need changing because they give an explicit HC Proxy URI in the >introduction, but I think it is a confusing example then to use '/hc' as >Proxy URI, either change all examples to the default or take a different >name altogether. (In the latter case, not that example 1 becomes >'.../hc/?target_uri...'; same for the 5.4.2.1 examples. Further, 5.5.1 >needs updating in the first and second examples too in the same spirit. > >I don't see reasons to not consent to any of the forms, but have a gut >feeling that I like '/{+tu}' better. The problem with hardcoding the slash in the template is that then if your HC Proxy URI is "http://proxy.example.org/hc?coap_uri=3D" then you'd end up with a bizarre "http://proxy.example.org/hc?coap_uri=3D/coap://node/resourc= e" From nobody Mon Jul 18 10:51:52 2016 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 2971512D7E1 for ; Mon, 18 Jul 2016 10:51:49 -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 XggGyO7pl-Gc for ; Mon, 18 Jul 2016 10:51:47 -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 08FCF12D16D for ; Mon, 18 Jul 2016 10:51:47 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 14B7342FD1; Mon, 18 Jul 2016 19:51:45 +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 3C8C94A; Mon, 18 Jul 2016 19:51:44 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DDDE344; Mon, 18 Jul 2016 19:51:43 +0200 (CEST) Received: (nullmailer pid 826 invoked by uid 1000); Mon, 18 Jul 2016 17:51:40 -0000 Date: Mon, 18 Jul 2016 19:51:40 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160718175140.GA26784@hephaistos.amsuess.com> References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718152257.GB7974@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 17:51:49 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 05:04:57PM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > The problem with hardcoding the slash in the template is that then if your > HC Proxy URI is "http://proxy.example.org/hc?coap_uri=3D" then you'd end = up > with a bizarre "http://proxy.example.org/hc?coap_uri=3D/coap://node/resou= rce" Agreed, this is likely to cause fewer confused implementors. Do we have and want to guidelines to offer on which parts of the URI would reasonably go into the HC Proxy URI and which would go into the template? (It wouldn't have occurred to me to have everything and the query string in the proxy URI). Cheers Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjRcpAAoJEDmNERLTpL3hVlwP/25K2IEgpeN3tjMFLl2FrBP4 WtJ95u7yipoORJpdoKWaZODnAn7jMtyjtEEPin19abfJgNK9456IglGZ63l/HJcd ku1Lh2rcfQyicnp5o3w+OtRUuHMozYaRu/lOnm7bRK5Dn9tjxk9xXOtM2cP7P2nd iK1TL/+ZIKEH3Zpkej8ogVC7Pc+RxeU8bjmfGwxRtggPD1PDm8UBZ5FADx1Gpcax GYmsRaQqgnbmvROjYlzUvXRHB0WO8tO9oPP9dbsWurc+3l9Oc2288AHTbsPjjatn GSB8hM3W7tbzB6Iqd0RtZ6sORZnZso9DYA4scTcvfQou0UkRUYMnBuwRDcwvZiOn 4WRZAs7oWFHnwBDvh51V7b+dhkYkFDjoyCrNbSN2ztlVKufepwYd0qLJPmELus0Y Xod8Nz6iLhnHnuCuzhKZfkvlkZKAk/Hz7nLnLt2Jy9JW0zidmT84WCFv9f15nfiw grxcfBCiMqbWmjqS0SqJ09NbyQFNQ0Ociy57/Kwsw/KfBc4HRt06NKRuho4xQGTP FoJ6CaN5fIDODV100YkfFyNuCcYidyvHr0/tVG8HNXHHzPqnjxHrjQ1nrTurnZTE mU+LEUA2HvXlrJjvP1VmuVzBP8bm6l1q579Xzqhu0ut2sLskFhuf9hgslVDWvP3T fgjNOMfT2w4DxjHShIAm =U49b -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From nobody Mon Jul 18 16:37:09 2016 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 7037912DBB1 for ; Mon, 18 Jul 2016 16:37: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] 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 YeKXv6dH7vch for ; Mon, 18 Jul 2016 16:37:05 -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 430E912DBA3 for ; Mon, 18 Jul 2016 16:37:01 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1516D42FC3; Tue, 19 Jul 2016 01:37: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 E9DE94A; Tue, 19 Jul 2016 01:36:58 +0200 (CEST) Received: from hephaistos.amsuess.com (ip5b405da5.dynamic.kabel-deutschland.de [91.64.93.165]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2EBA060; Tue, 19 Jul 2016 01:36:57 +0200 (CEST) Received: (nullmailer pid 10548 invoked by uid 1000); Mon, 18 Jul 2016 23:36:55 -0000 Date: Tue, 19 Jul 2016 01:36:55 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20160718233655.GB26784@hephaistos.amsuess.com> References: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> <20160717232159.GA12256@hephaistos.amsuess.com> <36F8FBDB-E334-4B87-8DAD-634DAD566015@gmail.com> <20160718162603.GA8099@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <20160718162603.GA8099@hephaistos.amsuess.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-lin?= =?utf-8?q?ks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 23:37:07 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael, On Mon, Jul 18, 2016 at 06:26:03PM +0200, Christian Ams=FCss wrote: > To you have thoughts on how we could fix that? >=20 > I'm all for keeping trying to find a working solution, but if that gets > worse, we should consider defining an RDF mapping of link-format that is > not coupled to links-json. I'll only arrive at the venue tomorrow around 1030 / 1100, I think it would be advisable if we could talk this over before or over lunch. Do you have an hour unplanned before the core session? The changes for JSON-LD compatibility would be something that (from my limited understanding of the processes) would hold up the last call, and we should be confident about that to do it. See you tomorrow Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --gatW/ieO32f1wygP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjWgUAAoJEDmNERLTpL3hDmYP/3yI05oVMmkecbul89VXy/92 cQfZER168yNPx4/wfyOsKj4q/Sz15SxaERrYh1DCABXVceDR3Qo22a+EopEk8y4B T/I10WtqluGkZ3mNToKNDiOBTI8iPySxEokipNoOPOpX5GNUacbQo6Z8bUAdQFAO Dk91orzjknvFbkCryVQWZQ+h1fiZqEA961hof3tjTRI6EdyY7q2K2lA4WsO1ASKY dVU8+xqDUtR5fClLopcDnFpj076KbYv0dWcVxpVUva22n7tkoTaDN5Uh6BCT2U4u 2a7cRkO/tzpvBJD7xHp3uQt2zLhwHeGDwj6V/ppcRYQedQ+ZsUK98aK73uWd1BNc DTQT5c7w9EzQZnkdghR/oYl5Qa+fGPs8V/mOXMCvuoyJGnx/ZKc3jCsRJP9DB/HL BDB97K3OClznCSpm+KP1fnftdLAnr32d2PGx0fGZavlyH1GaBNdRHbPWoQxJB39w Kw2tr1k2KFtKK+D8aovMwGbkeLQvIZbVzyFQE8aJ6FlRYnEI1VcTFXxpp/7WIt3o HYuO4k+wFev0d0w55kHQQT4k9+THBrp+klrtpaCzUT964/Fqzm4Ds+NddjjRwHDj MljuEedZnTHEwTwGrZQRLfxhI+E3KobyirLzELr3sqASRZcr23k8Q/qvaeRAO3JB /woNllBW34tjN+hmnj9s =JmhV -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From nobody Tue Jul 19 01:41:23 2016 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 415A212D17B for ; Tue, 19 Jul 2016 01:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 dtGXXV-9WBxG for ; Tue, 19 Jul 2016 01:41:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 F188C12D0A2 for ; Tue, 19 Jul 2016 01:41:12 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9F2E1742FE2F1; Tue, 19 Jul 2016 08:41:08 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6J8fAAP021625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 08:41:10 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6J8f53d002473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 10:41:09 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 10:40:13 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4IzOMziR1rQe0ECS+m3saUK3wqAd2zcAgAAhigCAADEkgIABMpEA Date: Tue, 19 Jul 2016 08:40:12 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718152257.GB7974@hephaistos.amsuess.com> In-Reply-To: <20160718152257.GB7974@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 08:41:21 -0000 Hi Christian, (replying to the rest of your previous email) On 18/07/2016 17:22, "Christian Ams=FCss" wrote: >On Mon, Jul 18, 2016 at 10:27:09AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> On second thought... I still think you are right that there is a slight >> incongruence in the current text. I guess the way to solve it is not to >> change the default template to "/{+tu}" though, but rather to append a >> slash to the the HC Proxy URI when needed -- that is, when the Target >>CoAP >> URI is part of the path component of the Hosting HTTP URI, and not of >>the >> query part. > >Well, both do work, either a slash after the default proxy HC Proxy URI >or one before the default URI Mapping template. If we go for the latter >(as you suggested the patch), at the very least 5.4.1.1 2. must be >changed to say '{+tu}' in the first line. The examples taken literally >don't need changing because they give an explicit HC Proxy URI in the >introduction, but I think it is a confusing example then to use '/hc' as >Proxy URI, The premise we do at the beginning of Section 5.4.1.1 is: "Note that these examples all define mapping templates that **deviate from the default template** of Section 5.3 to be able to illustrate the use of the above template variables." In fact, the "/{+tu}" in the second example is not the default template -- which looks to be pretty coherent with the premise and correct as to the produced Hosting HTTP URI. The alternative (as you suggest below) is to change all the examples in the section, which I'd rather avoid: at this stage we should keep the changes as small as possible. Cheers, t >either change all examples to the default or take a different >name altogether. (In the latter case, not that example 1 becomes >'.../hc/?target_uri...'; same for the 5.4.2.1 examples. Further, 5.5.1 >needs updating in the first and second examples too in the same spirit. > >I don't see reasons to not consent to any of the forms, but have a gut >feeling that I like '/{+tu}' better. > >Cheers >Christian > >--=20 >Christian Ams=FCss | Energy Harvesting Solutions GmbH >founder, system architect | headquarter: >mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr >tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ > | ATU68476614 > From nobody Tue Jul 19 01:54:56 2016 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 3E7E212DC3F for ; Tue, 19 Jul 2016 01:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 Nwws7sxF1AUF for ; Tue, 19 Jul 2016 01:54:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 ECBC112DC37 for ; Tue, 19 Jul 2016 01:54:51 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id F1E8D6AFC9637; Tue, 19 Jul 2016 08:54:47 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6J8snP2002632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 08:54:50 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6J8qvGn000868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 10:54:35 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 10:52:37 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4RcwIchJ9i6EKkafmJ9U3Wo34KAeVl0AgAEMdYA= Date: Tue, 19 Jul 2016 08:52:37 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718152257.GB7974@hephaistos.amsuess.com> <20160718175140.GA26784@hephaistos.amsuess.com> In-Reply-To: <20160718175140.GA26784@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9EEC8DF260F9A74A86C4D6EE515E965A@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 08:54:55 -0000 Hi Christian, On 18/07/2016 18:51, "core on behalf of Christian Ams=FCss" wrote: >Do we have and want to guidelines to offer on which parts of the URI >would reasonably go into the HC Proxy URI and which would go into the >template? (It wouldn't have occurred to me to have everything and the >query string in the proxy URI). IMHO it's not necessary. As long as the default mapping always produces a syntactically valid Hosting HTTP URI (which is the case, modulo IPv6 address brackets escaping) I think we are done with our job. Cheers, t From nobody Tue Jul 19 05:55:53 2016 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 6FCED12D83F for ; Tue, 19 Jul 2016 05:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ol2NYMgV9ceB for ; Tue, 19 Jul 2016 05:55:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A69E812D7F2 for ; Tue, 19 Jul 2016 05:52:13 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B00E9BC77A457; Tue, 19 Jul 2016 12:52:07 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6JCq7lE017284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 12:52:10 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6JCpTDb006849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 14:52:04 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 14:49:47 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Fossati, Thomas (Nokia - GB)" , =?iso-8859-1?Q?Christian_Ams=FCss?= , "core@ietf.org" Thread-Topic: proposed -13 (was: Re: [core] draft-ietf-core-http-mapping-12) Thread-Index: AQHR4bwHe5R57ryWkkS6YMo9tewCKA== Date: Tue, 19 Jul 2016 12:49:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4DEE3EC980DCA44294E3C48A8CDA7D76@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] proposed -13 (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 12:55:51 -0000 Hi Christian, all, We would like to submit http-mapping-13 before the end of the day with the patch attached in [1]. I hope that solves the comments you raised (modulo the need to minimise the changeset). If not, please shout ;-) Cheers, thanks, t [1] https://mailarchive.ietf.org/arch/msg/core/AEtYOFjJZ62GZO116AfamRv7o5k From nobody Tue Jul 19 08:07:35 2016 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 46C8312DC70 for ; Tue, 19 Jul 2016 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6VeyXrpQyAR for ; Tue, 19 Jul 2016 08:07:29 -0700 (PDT) Received: from smtp-in1.interdigital.com (unknown [68.168.94.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36B812D73E for ; Tue, 19 Jul 2016 07:43:34 -0700 (PDT) X-ASG-Debug-ID: 1468939412-06daaa1090343fc0001-aa7cYp Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id nWZcb6v3rX3rXgHM (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2016 10:43:32 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0301.000; Tue, 19 Jul 2016 10:43:32 -0400 From: "Rahman, Akbar" To: "core@ietf.org" Thread-Topic: FYI - Resource Directory article in The Internet Protocol Journal X-ASG-Orig-Subj: FYI - Resource Directory article in The Internet Protocol Journal Thread-Index: AdHhyuK1Umn+fm4XQ6Wjcr51DwCI3Q== Date: Tue, 19 Jul 2016 14:43:32 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5C03FB20@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.176] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: multipart/alternative; boundary="_000_36F5869FE31AB24485E5E3222C288E1F5C03FB20NABESITEInterDi_" MIME-Version: 1.0 X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253] X-Barracuda-Start-Time: 1468939412 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3266 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.31369 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [core] FYI - Resource Directory article in The Internet Protocol Journal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 15:07:34 -0000 --_000_36F5869FE31AB24485E5E3222C288E1F5C03FB20NABESITEInterDi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - Some people suggested I send this info to the list for background rea= ding on the RD (especially as the RD draft is now nearing for WGLC). We wrote a tutorial style article on "Resource Discovery for the IoT" that = was published in the June Internet Protocol Journal. Since it describes th= e work done in CORE WG related to the RD it will hopefully be interesting t= o the members of this list. http://ipj.dreamhosters.com/wp-content/uploads/issues/2016/ipj19-2.pdf Best Regards, Akbar --_000_36F5869FE31AB24485E5E3222C288E1F5C03FB20NABESITEInterDi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI – Some people suggested I send this info t= o the list for background reading on the RD (especially as the RD draft is = now nearing for WGLC). 

 

We wrote a tutorial style article on “Resource= Discovery for the IoT” that was published in the June Internet Proto= col Journal.  Since it describes the work done in CORE WG related to t= he RD it will hopefully be interesting to the members of this list.

 

 

http://ipj.dreamhosters.com/wp-content/uploa= ds/issues/2016/ipj19-2.pdf

 

 

 

Best Regards,

 

 

Akbar

--_000_36F5869FE31AB24485E5E3222C288E1F5C03FB20NABESITEInterDi_-- From nobody Tue Jul 19 08:22:13 2016 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 1BC5412E06B for ; Tue, 19 Jul 2016 08:22:01 -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 exZbbgzedpcD for ; Tue, 19 Jul 2016 08:21:50 -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 511CF12D902 for ; Tue, 19 Jul 2016 08:02:07 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0D89D42FFF; Tue, 19 Jul 2016 17:02:04 +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 AA8ED4A; Tue, 19 Jul 2016 17:01:47 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0143D44; Tue, 19 Jul 2016 17:01:46 +0200 (CEST) Received: (nullmailer pid 3823 invoked by uid 1000); Tue, 19 Jul 2016 14:30:43 -0000 Date: Tue, 19 Jul 2016 16:30:43 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160719143043.GC26784@hephaistos.amsuess.com> References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718090615.GB12256@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 15:22:01 -0000 --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 09:39:17AM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > I agree that this would be a very sensible interpretation if you put > together RFC6690 and the definition of URI-Reference from RFC3986. > However, RFC6690 Section 2.1 seems to override that, by defining specific > rules (a-c) for defining the context URI for CoRE Link Format: "The > context URI of a link (also called the base URI in [RFC3986]) is > determined by the following rules **in this specification**: [...]" >=20 > What do other think? (Not being an other, but still), I think that this is not overriding the basic URI concatenation mechanisms, but only how the context URI is determined (start of your quoted sentence). Best regards Christian PS. Reply on the other topic is in the works and will arrive during the evening. --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAABCAAGBQJXjjmQAAoJEDmNERLTpL3hLp8P+PyvjSpmDAPHMhBl87AXhEtt neHrvo4ZE0LobG4OFCCaD/8K2o6U516BT8TfGMWR+PCfLKvGIlA+f9X3v5wX8xsa 5b4ANaN3eJATk9X0m5SKgtZLFZvMa8+6sNOoiG5KLsO989owywfIsUfrPzC3fc2Z A21swNZOUqMKZTmExGnsMnDMBvCf7H/dv0Z7oKZk6+E8/Tajprsg1OOILuqR/Cld /GsHXhRBP5/hfmnJ0Aznn+KxR5mdl3Cv+vjDyBt0LJTAO9gqijiMmArlxsBEIncE sd/UJVbNFFnF6iVRTMipHV7wUsFpJ41sZ+sPoH737v2KC3/D1wbj0icbslNGwnXK 1epdRhkhmD2c0fJokXiWDBqoMyCjn3ktjSz3IIQT3tgFHjnQrEzFsdg0iCB/LYrZ 64eWEe9hAxlBiApQEu9d/IAuKZMfJ0MHWwccOU643fI2VJd5xHwp5Y02AQOlDHQA xWcW/DfPuvS2zENR+XXV5v33ntRXEcRA3jOFLayaG6hjtbxSEieCW1UVSV9Z+ACi PO6D7MabQsUStc4BVujylgE1gXD7+5pCcH6hNTMjfU/oEh4zClmW8O7Slk2/OTSt u26uKw9FF8N+aIixoZlVhtiq5h8Oz49tEHct82hmiG5OHkMCh3urs+tBp2hhHvhl 2RHUjTVdv954Uc3r8Gw= =1eiB -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- From nobody Tue Jul 19 08:33:51 2016 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 BB79912D98D for ; Tue, 19 Jul 2016 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 NcGVAMooJ30E for ; Tue, 19 Jul 2016 08:33:48 -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 9BA1B12DD29 for ; Tue, 19 Jul 2016 08:17:22 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id E463442FFF; Tue, 19 Jul 2016 17:17:20 +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 3AD894A; Tue, 19 Jul 2016 17:17:20 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D9CD944; Tue, 19 Jul 2016 17:17:19 +0200 (CEST) Received: (nullmailer pid 12985 invoked by uid 1000); Tue, 19 Jul 2016 15:17:18 -0000 Date: Tue, 19 Jul 2016 17:17:18 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160719151717.GD26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="48TaNjbzBVislYPb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 15:33:50 -0000 --48TaNjbzBVislYPb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2016 at 08:40:12AM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > The premise we do at the beginning of Section 5.4.1.1 is: "Note that these > examples all define mapping templates that **deviate from the default > template** of Section 5.3 to be able to illustrate the use of the above > template variables." I was about to point out that they not only deviate from the default template but also from the recommended Proxy URI, but found that unlike core-resource-directory ("An RD SHOULD use the value "rd" for this variable whenever possible."), it does not actually recommend that at any time. > In fact, the "/{+tu}" in the second example is not the default template -- > which looks to be pretty coherent with the premise and correct as to the > produced Hosting HTTP URI. That is correct, but the "i.e., the default URI Mapping template" is not, it should be "could also be achieved with /hc/ as Proxy URI and default template". > The alternative (as you suggest below) is to change all the examples in > the section, which I'd rather avoid: at this stage we should keep the > changes as small as possible. My opinion is that it's better to change them. Slashes at the end of paths are a thing people like to get wrong, and the introductory examples and the later ones using subtly different proxy paths IMO has too much potential for confusion. On Tue, Jul 19, 2016 at 08:52:37AM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > IMHO it's not necessary. As long as the default mapping always produces a > syntactically valid Hosting HTTP URI (which is the case, modulo IPv6 > address brackets escaping) I think we are done with our job. I'm fine with that. Thanks for managing this swiftly Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --48TaNjbzBVislYPb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjkR6AAoJEDmNERLTpL3h38sP/RqEH7++0MGUqeHL4komXni3 eBvDjxPKMHpIQZrE0z7rHxXJJPYp4YkIqR16+8Uiql1YiXN5eMSN+TmBCQF76eka 7wTfJAvjClGp2jB5BW9JbvqiX2EYNqb5neUEs6w13DY9oQQpijkYaJG0s+zRK/JJ 5KGYDQv8C4qtjuLWhB2TiyJde5hHeuc8+O/uyGALG4LeC84X6IVQLIxiWgLTruYI psfrn0BZdTimlCAP3cmSPLgLzy916WABzie1XJcPADxBSRRCuknAZmvpGb3LhOyP ZFkOm8nz1KTpELEWPZElDuuhXDVYLwn1q0bfqyPENel3UC3pL/CA69XDSLJpcslC KCXohRG2b469dyEs29r2Q4FisgJfPP3IAjM8bxjNcQOfTA482n/9MboJvSpeUk1b HcXd5dFb+kh0wu1G7O84mIv4v6KOzkS5XFXVmxjfsc42AjFjz91cZ7hbeuqyEQwg FlHFw5HFhNJuH6MSFK0kLHLo6gEHeEjyAFe2BWKmU8DPK7/pe4eSwsjPYdNfd1dy 5jiFT0rI4XFFkIHIU2oc39TVEqY2m1ikNvJXNToTkSCytz3kX3a6DvR6Rc1esehL UQ2SI8eawjN0TS4zBTJH2sLdSDPng26Ghg+SSf0QfubCyWl1q8fORn8SLvMwofKD MKecdplKFMzAmXcGNbJ6 =Dz/U -----END PGP SIGNATURE----- --48TaNjbzBVislYPb-- From nobody Tue Jul 19 09:23:36 2016 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 AB61212D0E5 for ; Tue, 19 Jul 2016 09:23:27 -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 Vb3JC_TNKu2x for ; Tue, 19 Jul 2016 09:23:23 -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 C8E3D12D0AF for ; Tue, 19 Jul 2016 09:22:58 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DFB5E42FFF; Tue, 19 Jul 2016 18:22:56 +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 EDB384A; Tue, 19 Jul 2016 18:22:55 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AE64044; Tue, 19 Jul 2016 18:22:55 +0200 (CEST) Received: (nullmailer pid 24245 invoked by uid 1000); Tue, 19 Jul 2016 16:22:54 -0000 Date: Tue, 19 Jul 2016 18:22:54 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Message-ID: <20160719162254.GA8019@hephaistos.amsuess.com> References: <4AA7AAD0-7BA7-4CCE-A648-476058DDDFB1@ericsson.com> <578D0937.2020104@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <578D0937.2020104@tzi.org> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-lin?= =?utf-8?q?ks-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 16:23:28 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 06:52:07PM +0200, Carsten Bormann wrote: > -- I agree that we should not claim to have solved JSON-LD interworking; > maybe we should simply remove some of the material that goes beyond > objectives 1 and 2 in section 1.1, because these are really the ones we > did focus on. As pointed out in the WG meeting, I'd like to add a bullet in the 'Consider other work' section to address this issue: * Adaptions to make this suitable for JSON-LD consumption would have conflicted with the above goals (rt/if/ct values would have needed to be made repeatable instead of space-separated and turned into CURIEs, link-format extensions and default values could not be covered). Just to have things documented somewhere (doesn't fit in the draft, but should give the rationale for people who look up the rationale for the above), here are some more details: * Whitespace separated properties like rt/if/rel/rev/ct would need to be split into a JSON array to avoid producing semantically nonsentical statements like ` core:rt "temp outside-temp"`. As the conversion process would need to be comprehensively specified for the RFC, we'd need to recommend link-format extensions to not use the whitespace separation at all and make everything into repetible attributes, compromising the compactness of link-format. * Resource type values and similar would need to be JSON-LD @id properties in order for ext-rel-type URIs to be correctly represented as URIs and not literals. For reg-rel-type (like "core.s"), best thing we could do would be provide a prefix (could be a CURIE) that would need to be prepended to every value in rt etc. For example, rt=3D"core.s core.b" would have for example become "rt":[":core.s",":core.s"] and rely on the @context to provide a central default CURIE in which then all registered types would reside. That'd be very inflexible URI design, and would only work for the few properties we define this beforehand. Worst of all, while the string-splitting could have been argued to be practical for JSON in general too, this would be a change exclusively introduced in order to satisfy this use case. (We did consider that we could start swapping dots and colons around to have core:s style CURIEs, but that would be equally intrusive, non-roundtrippable, and couldn't be done with ad-hoc CURIEs because JSON-LD that's a top-level list can't have a global list of document-defined CURIEs without even more intrusive changes to the document structure). * For some properties, default values are specified (eg. rel=3Dhosts unless specified differently), which could not be inserted by the @context (which at least could be remotely updated for every new registered extension), but need support from the links-json conversion. As having a semantic view on the link format information is still an interesting thing to have, the most promising direction to continue in is to describe the semantics we'd like to obtain from a link-format file, which is something that should be coordinated with the T2T people. The semantic statements should be derivable from any link-format representation, but as opposed to json-link-format, where any intermediate node like a HC proxy could do the conversion, only the consuming client or the origin server (that know which link-format extensions they are interested in or provide, respectively) could do that conversion. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjlPaAAoJEDmNERLTpL3hSeMP/R/7YUz5a5DmsQXDBDwoX5Zr cMVhsWYxSyxzwcsptadIMBTyabB/fTrZj6pi+QUksGLM4ungWPyBTEjThrHXczhW 0ePqkRZifqKmjfzthk3Tug2a8WMPVpwCr++r0s0v8wvS64EwbTcb0NLlQEuHYjJo Dp6G1HOlYCl2eWOHa493QZW1HzYGL1JJN036d2qV6LEZ3BBPZRRx0Z8zE+HtzhaP mJ8W8BPt/pYrk91zG3srvAjC9TvV8kKfCwC8FsyIu21wQ+64/zGb9o8m5UtMQiUw j5eLCXOts34MWKjJy4qTGjUNOawKIcoCZ2une9LXEwGAgJuwbPGcyybAyNzFrp8X Ap4f0GLay6VjKGRIK5ZSjCHPeNsHB3bED71xm8MABXVb6/nrPlEYsdsXabsgwuim +wfvJ2PcrgDMSC+LCUgZlmx48oaRjZYmxmsWME8z6e0ccQhz2f2Zcgk7Tnt5F4Ur 0lbTsd80bNFxngKL8CVX+9IECs0LDyqTVmhdVU1gmvWjai9N5fRkMwe/6+PrnfDz lR5Bnefpw13guCqdKk2ad9DwpgYkj92qZfEA7l/vp4I5bqO5Gdj3kKBn0N7LsLsX LvROmus8iIoG436unXl9nc9JBNKnd/7Lbb5+zoN+78gpDUN2aghRFzVRR0PbW64G fKNBxHZwUfqP2rtNbUDk =BsiR -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From nobody Tue Jul 19 10:24:56 2016 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 744ED12D0F8 for ; Tue, 19 Jul 2016 10:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 5c_aTsSemzFO for ; Tue, 19 Jul 2016 10:24:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2BB3A12B056 for ; Tue, 19 Jul 2016 10:24:52 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6D1B426F56019; Tue, 19 Jul 2016 17:24:46 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6JHOnPJ024096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 17:24:50 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6JHOnn6006091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 19:24:49 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 19:24:46 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= Thread-Topic: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) Thread-Index: AQHR4NhAO3WSUM7yWUK2lnZ7h2obv6AfsQuAgABBZAA= Date: Tue, 19 Jul 2016 17:24:49 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718090615.GB12256@hephaistos.amsuess.com> <20160719143043.GC26784@hephaistos.amsuess.com> In-Reply-To: <20160719143043.GC26784@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1D2D23BC5EC3754FA510B32B625A277A@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 17:24:54 -0000 Hi Christian, On 19/07/2016 15:30, "Christian Ams=FCss" wrote: >On Mon, Jul 18, 2016 at 09:39:17AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> I agree that this would be a very sensible interpretation if you put >> together RFC6690 and the definition of URI-Reference from RFC3986. >> However, RFC6690 Section 2.1 seems to override that, by defining >>specific >> rules (a-c) for defining the context URI for CoRE Link Format: "The >> context URI of a link (also called the base URI in [RFC3986]) is >> determined by the following rules **in this specification**: [...]" >>=20 >> What do other think? > >(Not being an other, but still), I think that this is not overriding the >basic URI concatenation mechanisms, but only how the context URI is >determined (start of your quoted sentence). I've found the missing piece :-) RFC6690 Section 2.2 says the following about the "hosts" relationship: "The target URI MUST be a relative URI of the context URI for this relation type." So, since the one we are specifying is in fact a hosts relation, we just can't have an absolute URI in the link (i.e., something like ;rt=3D"core.hc"). Therefore Section 2.1 applies, therefore we have to use the anchor attribute. Cheers, t From nobody Tue Jul 19 10:31:00 2016 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 61C1212D0F8 for ; Tue, 19 Jul 2016 10:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 5JqEv5OG8R55 for ; Tue, 19 Jul 2016 10:30:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 731B312B010 for ; Tue, 19 Jul 2016 10:30:57 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 8744E44207C2D; Tue, 19 Jul 2016 17:30:51 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6JHUsUf030771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 17:30:55 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6JHUpCX031131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 19:30:54 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 19:30:51 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4dCjIchJ9i6EKkafmJ9U3Wo34KAf8i4A Date: Tue, 19 Jul 2016 17:30:51 +0000 Message-ID: References: <20160719151717.GD26784@hephaistos.amsuess.com> In-Reply-To: <20160719151717.GD26784@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 17:30:59 -0000 Hi Christian, On 19/07/2016 16:17, "Christian Ams=FCss" wrote: >On Tue, Jul 19, 2016 at 08:40:12AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> The premise we do at the beginning of Section 5.4.1.1 is: "Note that >>these >> examples all define mapping templates that **deviate from the default >> template** of Section 5.3 to be able to illustrate the use of the above >> template variables." > >I was about to point out that they not only deviate from the default >template but also from the recommended Proxy URI, but found that unlike >core-resource-directory ("An RD SHOULD use the value "rd" for this >variable whenever possible."), it does not actually recommend that at >any time. Yes, we don't do that. And the reason is RFC 7320. >> In fact, the "/{+tu}" in the second example is not the default template >>-- >> which looks to be pretty coherent with the premise and correct as to the >> produced Hosting HTTP URI. > >That is correct, but the "i.e., the default URI Mapping template" is >not, it should be "could also be achieved with /hc/ as Proxy URI and >default template". Yes, you are right (and I've fixed it in my working copy). >> The alternative (as you suggest below) is to change all the examples in >> the section, which I'd rather avoid: at this stage we should keep the >> changes as small as possible. > >My opinion is that it's better to change them. Slashes at the end of >paths are a thing people like to get wrong, and the introductory >examples and the later ones using subtly different proxy paths IMO has >too much potential for confusion. Do you have an outline already in mind? Would you be able to provide replacement text by the end of this week? >On Tue, Jul 19, 2016 at 08:52:37AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> IMHO it's not necessary. As long as the default mapping always >>produces a >> syntactically valid Hosting HTTP URI (which is the case, modulo IPv6 >> address brackets escaping) I think we are done with our job. > >I'm fine with that. Good. Cheers, thanks very much, t From nobody Tue Jul 19 15:15:17 2016 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 B4D3012D91A for ; Tue, 19 Jul 2016 15:15:14 -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 mebnZxMNCFMP for ; Tue, 19 Jul 2016 15:15:12 -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 E60A612D936 for ; Tue, 19 Jul 2016 15:15:11 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D6BE142FAF; Wed, 20 Jul 2016 00:15:09 +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 ABE251CF; Wed, 20 Jul 2016 00:15:08 +0200 (CEST) Received: from hephaistos.amsuess.com (ip5b405da5.dynamic.kabel-deutschland.de [91.64.93.165]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 522EA60; Wed, 20 Jul 2016 00:15:08 +0200 (CEST) Received: (nullmailer pid 3591 invoked by uid 1000); Tue, 19 Jul 2016 21:50:27 -0000 Date: Tue, 19 Jul 2016 23:50:27 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160719215027.GE26784@hephaistos.amsuess.com> References: <20160719151717.GD26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nHwqXXcoX0o6fKCv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 22:15:15 -0000 --nHwqXXcoX0o6fKCv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2016 at 05:30:51PM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > Do you have an outline already in mind? Would you be able to provide > replacement text by the end of this week? I do and would; either the source file to edit and return as a patch or a vcs clone to create a pull request would work most easily for me. We can then still ask for opinions of whether the delta is small enough to apply at that stage. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --nHwqXXcoX0o6fKCv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjqCgAAoJEDmNERLTpL3hOk8P/2qJWe4iUM3k1PhuchXvVmu6 rcQto1F9v6HqezhkItjyevhksttKjhhvbLcmzQ1HFlcRnqy3kkM5g7p/o6+3GaFR 7HjAkBxWcYjSkgJtEJOXiQK4UnjUC9zsQfSWDGqm9b3cpyISOdIPND02Orh4QD7n LRo7OkUL3SRP2uuxmDe/MQaKw/KgHraCljCodaapMLLWzd/F2FVBc+6gQlRtpgyP w7AAxxH/68Jo722Gkesz8JaIRNTD/eF6WLBjTMsMFJUQIYp1882aaa06sMVBDxml AGYZbQjiJ5BcZ/3ldGH5cNiHQ/BKoeTM6Ebyew7jv2YQA83oO/k2U3ZugVGwBent eeV6xUYef8gA+SzJokoC+20/VZjreoW4JsdTAjztGKciuG8eaLChASc9UrDtVKjF 6ZxbB6wMK1Qb7bPse8usbTRjTsW4sISTTjLdnG2fnWLqoTeq7ihCd8JtD2imyfvp FKWIXyHRLUYRcxdQ+1oCFZITKXtJA/qG4xQBR5gAEfJpB/veY9Dh75tCpMR818Ni qQUzxarAbeEiNLdRL7wsstEgYvNsP3TiKUIvZ6qFPdNg2f1E4B+9ZlS9Smr/suDF nG2HPzPUmIL0T5HlbQ2MVNtK76j+mI9OH/Bjg3c4ItWSEG80GrO/qVsfrG7CcxPR MKKQgV14qFzzQH4kwuxb =45Wf -----END PGP SIGNATURE----- --nHwqXXcoX0o6fKCv-- From nobody Tue Jul 19 15:15:31 2016 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 144F812D98D for ; Tue, 19 Jul 2016 15:15:18 -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 LaI9vekNp3VC for ; Tue, 19 Jul 2016 15:15:16 -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 A208812D95C for ; Tue, 19 Jul 2016 15:15:15 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 34AB242FAF; Wed, 20 Jul 2016 00:15:14 +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 B42C31CF; Wed, 20 Jul 2016 00:15:10 +0200 (CEST) Received: from hephaistos.amsuess.com (p4FD4C980.dip0.t-ipconnect.de [79.212.201.128]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7B39E60; Wed, 20 Jul 2016 00:15:09 +0200 (CEST) Received: (nullmailer pid 3825 invoked by uid 1000); Tue, 19 Jul 2016 22:00:24 -0000 Date: Wed, 20 Jul 2016 00:00:24 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160719220024.GD7974@hephaistos.amsuess.com> References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718090615.GB12256@hephaistos.amsuess.com> <20160719143043.GC26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4zI0WCX1RcnW9Hbu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 22:15:18 -0000 --4zI0WCX1RcnW9Hbu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2016 at 05:24:49PM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > I've found the missing piece :-) >=20 > RFC6690 Section 2.2 says the following about the "hosts" relationship: > "The target URI MUST be a relative URI of the context URI for this > relation type." Good catch, I would have missed that. As the language in the section is not strong ("the link [...] needs an explicit anchor" instead of "MUST be anchored"), I think this issue is closed. Thanks for your consideration Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --4zI0WCX1RcnW9Hbu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXjqL4AAoJEDmNERLTpL3hoqUP/AyC3fmGdRDGoFm8zmsNlYSi oC/eIKPqp//M8wsnp0ujeuCVP2cANoaeCoZEmfzOUqrC9X9aGq5jVIhVP6zDzIEV 6V5WbHisO5ymzv6kC71Phrk/NA53dP5DwlKK9ZGxF253i2mk4puVXa82vgi2cP9r QQe6Ug1HUxwzM5iqc9P9m3Ih0F5d3KB0lfwyVrVdAFmvlgIw3eCcJ1KrnPsMuGn8 PQKC1PW8etQWms8becLdwonvYvXdUzODjW6KrXqYtpk18E9H0ZL5s+9/CkGDBTBs sFXZWHZTmm7cjreJVXlsZkUryw5+Kn6cveOXCNYl4e65UV3/GV+yP9ODW9idfzig TyEcxzl4LX1MAk/MyPa8IIemKSPLGVpyg/TYaYHwfxiqvHoFTL33tIOfugjdY/J8 CiUDblrYtPekNI6JspkRdIkxcIgbwtQ8F0/3HcK1BFCmICVh1NUnOPyVxTM1Gm4m 0XBZjUmze9QvFge5+NS0nmOaAxMtK+Mf9bIFWH2aEvnCIgfA/Y+brktnYGJuUJnl 0nRwKd3hw8yhHi/lFcEv21FpUyq2PoOi/D9uD3l0Y9qlokoJ98PYT73jieRnetot aYRonYggSfsv6C9HaPJI83hpJxVRy/Q3WKc9eDsYHQzBiq+S1U0snga0fqGshWwE hWQALsnBtRpTSrmv7APE =G7PZ -----END PGP SIGNATURE----- --4zI0WCX1RcnW9Hbu-- From nobody Wed Jul 20 01:54:43 2016 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 0507412B037 for ; Wed, 20 Jul 2016 01:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 yBNLxNA8gdXr for ; Wed, 20 Jul 2016 01:54:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8642512D0B8 for ; Wed, 20 Jul 2016 01:54:39 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DF551D7171139; Wed, 20 Jul 2016 08:54:35 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6K8sbOm022849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2016 08:54:37 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6K8sX0b005759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Jul 2016 10:54:37 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 20 Jul 2016 10:54:35 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4dCjIchJ9i6EKkafmJ9U3Wo34KAf8i4AgAA3yICAAMpPAA== Date: Wed, 20 Jul 2016 08:54:34 +0000 Message-ID: References: <20160719151717.GD26784@hephaistos.amsuess.com> <20160719215027.GE26784@hephaistos.amsuess.com> In-Reply-To: <20160719215027.GE26784@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: multipart/mixed; boundary="_002_D3B4FA5B6E2D1thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 08:54:42 -0000 --_002_D3B4FA5B6E2D1thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8193F954DC3F5248A84B6740018975D0@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable Hi Christian, On 19/07/2016 22:50, "core on behalf of Christian Ams=FCss" wrote: >On Tue, Jul 19, 2016 at 05:30:51PM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> Do you have an outline already in mind? Would you be able to provide >> replacement text by the end of this week? > >I do and would; either the source file to edit and return as a patch or >a vcs clone to create a pull request would work most easily for me. We >can then still ask for opinions of whether the delta is small enough to >apply at that stage. Excellent. I've attached my working copy. You hold the edit lock now. Thanks, t --_002_D3B4FA5B6E2D1thomasfossatialcatellucentcom_ Content-Type: application/xml; name="draft-ietf-core-http-mapping-13.xml" Content-Description: draft-ietf-core-http-mapping-13.xml Content-Disposition: attachment; filename="draft-ietf-core-http-mapping-13.xml"; size=76345; creation-date="Wed, 20 Jul 2016 08:54:34 GMT"; modification-date="Wed, 20 Jul 2016 08:54:34 GMT" Content-ID: Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXMtYXNjaWkiPz4KPCFET0NUWVBFIHJmYyBT WVNURU0gInJmYzI2MjkuZHRkIiBbCjwhRU5USVRZIFJGQzIxMTkgU1lTVEVNICJodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIxMTkueG1sIj4K PCFFTlRJVFkgUkZDMjYxNiBTWVNURU0gImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9y ZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjYxNi54bWwiPgo8IUVOVElUWSBSRkMzMDQwIFNZU1RF TSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJG Qy4zMDQwLnhtbCI+CjwhRU5USVRZIFJGQzM5ODYgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNl Lm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjM5ODYueG1sIj4KPCFFTlRJVFkg UkZDNDczMiBTWVNURU0gImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1s L3JlZmVyZW5jZS5SRkMuNDczMi54bWwiPgo8IUVOVElUWSBSRkM1MjM0IFNZU1RFTSAiaHR0cDov L3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41MjM0Lnht bCI+CjwhRU5USVRZIFJGQzY1NzAgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjY1NzAueG1sIj4KPCFFTlRJVFkgUkZDNjY5MCBT WVNURU0gImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5j ZS5SRkMuNjY5MC54bWwiPgo8IUVOVElUWSBSRkM3MDQ5IFNZU1RFTSAiaHR0cDovL3htbC5yZXNv dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy43MDQ5LnhtbCI+CjwhRU5U SVRZIFJGQzcyMzAgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2Jp YnhtbC9yZWZlcmVuY2UuUkZDLjcyMzAueG1sIj4KPCFFTlRJVFkgUkZDNzIzMSBTWVNURU0gImh0 dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNzIz MS54bWwiPgo8IUVOVElUWSBSRkM3MjMyIFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy43MjMyLnhtbCI+CjwhRU5USVRZIFJGQzcy MzUgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZl cmVuY2UuUkZDLjcyMzUueG1sIj4KPCFFTlRJVFkgUkZDNzI1MiBTWVNURU0gImh0dHA6Ly94bWwu cmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNzI1Mi54bWwiPgo8 IUVOVElUWSBSRkM3MzkwIFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy43MzkwLnhtbCI+CjwhRU5USVRZIFJGQzc2NDEgU1lTVEVN ICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZD Ljc2NDEueG1sIj4KPCFFTlRJVFkgSS1ELmlldGYtY29yZS1ibG9jayBTWVNURU0gImh0dHA6Ly94 bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmlldGYtY29y ZS1ibG9jay54bWwiPgo8IUVOVElUWSBJLUQuaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeSBT WVNURU0gImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVu Y2UuSS1ELmlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnkueG1sIj4KPCFFTlRJVFkgSS1ELmll dGYtY29yZS1saW5rcy1qc29uIFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQuaWV0Zi1jb3JlLWxpbmtzLWpzb24ueG1sIj4KXT4K PD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0icmZjMjYyOS54c2x0Ij8+Cjw/ cmZjIHN0cmljdD0ibm8iPz4KPD9yZmMgdG9jPSJ5ZXMiPz4KPD9yZmMgdG9jZGVwdGg9IjMiPz4K PD9yZmMgc3ltcmVmcz0ieWVzIj8+Cjw/cmZjIHNvcnRyZWZzPSJ5ZXMiPz4KPD9yZmMgY29tcGFj dD0ieWVzIj8+Cjw/cmZjIHN1YmNvbXBhY3Q9Im5vIj8+CjxyZmMgaXByPSJ0cnVzdDIwMDkwMiIg ZG9jTmFtZT0iZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZy0xMyIgY2F0ZWdvcnk9ImluZm8i PgogIDxmcm9udD4KICAgIDx0aXRsZSBhYmJyZXY9IkhUVFAtdG8tQ29BUCBNYXBwaW5nIj4KICAg ICBHdWlkZWxpbmVzIGZvciBIVFRQLXRvLUNvQVAgTWFwcGluZyBJbXBsZW1lbnRhdGlvbnMKICAg IDwvdGl0bGU+CiAgICA8YXV0aG9yIGluaXRpYWxzPSJBLlAuIiBzdXJuYW1lPSJDYXN0ZWxsYW5p IiBmdWxsbmFtZT0iQW5nZWxvIFAuIENhc3RlbGxhbmkiPgogICAgICA8b3JnYW5pemF0aW9uPlVu aXZlcnNpdHkgb2YgUGFkb3ZhPC9vcmdhbml6YXRpb24+CiAgICAgIDxhZGRyZXNzPgogICAgICAg IDxwb3N0YWw+CiAgICAgICAgICA8c3RyZWV0PlZpYSBHcmFkZW5pZ28gNi9CPC9zdHJlZXQ+CiAg ICAgICAgICA8Y29kZT4zNTEzMTwvY29kZT4KICAgICAgICAgIDxjaXR5PlBhZG92YTwvY2l0eT4K ICAgICAgICAgIDxjb3VudHJ5Pkl0YWx5PC9jb3VudHJ5PgogICAgICAgIDwvcG9zdGFsPgogICAg ICAgIDxlbWFpbD5hbmdlbG9AY2FzdGVsbGFuaS5uZXQ8L2VtYWlsPgogICAgICA8L2FkZHJlc3M+ CiAgICA8L2F1dGhvcj4KICAgIDxhdXRob3IgaW5pdGlhbHM9IlMuIiBzdXJuYW1lPSJMb3JldG8i IGZ1bGxuYW1lPSJTYWx2YXRvcmUgTG9yZXRvIj4KICAgICAgPG9yZ2FuaXphdGlvbj5Fcmljc3Nv bjwvb3JnYW5pemF0aW9uPgogICAgICA8YWRkcmVzcz4KICAgICAgICA8cG9zdGFsPgogICAgICAg ICAgPHN0cmVldD5IaXJzYWxhbnRpZSAxMTwvc3RyZWV0PgogICAgICAgICAgPGNvZGU+MDI0MjA8 L2NvZGU+CiAgICAgICAgICA8Y2l0eT5Kb3J2YXM8L2NpdHk+CiAgICAgICAgICA8Y291bnRyeT5G aW5sYW5kPC9jb3VudHJ5PgogICAgICAgIDwvcG9zdGFsPgogICAgICAgIDxlbWFpbD5zYWx2YXRv cmUubG9yZXRvQGVyaWNzc29uLmNvbTwvZW1haWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0 aG9yPgogICAgPGF1dGhvciBpbml0aWFscz0iQS4iIHN1cm5hbWU9IlJhaG1hbiIgZnVsbG5hbWU9 IkFrYmFyIFJhaG1hbiI+CiAgICAgIDxvcmdhbml6YXRpb24+SW50ZXJEaWdpdGFsIENvbW11bmlj YXRpb25zLCBMTEM8L29yZ2FuaXphdGlvbj4KICAgICAgPGFkZHJlc3M+CiAgICAgICAgPHBvc3Rh bD4KICAgICAgICAgIDxzdHJlZXQ+MTAwMCBTaGVyYnJvb2tlIFN0cmVldCBXZXN0PC9zdHJlZXQ+ CiAgICAgICAgICA8Y2l0eT5Nb250cmVhbDwvY2l0eT4KICAgICAgICAgIDxjb2RlPkgzQSAzRzQ8 L2NvZGU+CiAgICAgICAgICA8Y291bnRyeT5DYW5hZGE8L2NvdW50cnk+CiAgICAgICAgPC9wb3N0 YWw+CiAgICAgICAgPHBob25lPisxIDUxNCA1ODUgMDc2MTwvcGhvbmU+CiAgICAgICAgPGVtYWls PkFrYmFyLlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tPC9lbWFpbD4KICAgICAgPC9hZGRyZXNzPgog ICAgPC9hdXRob3I+CiAgICA8YXV0aG9yIGluaXRpYWxzPSJULiIgc3VybmFtZT0iRm9zc2F0aSIg ZnVsbG5hbWU9IlRob21hcyBGb3NzYXRpIj4KICAgICAgPG9yZ2FuaXphdGlvbj5Ob2tpYTwvb3Jn YW5pemF0aW9uPgogICAgICA8YWRkcmVzcz4KICAgICAgICA8cG9zdGFsPgogICAgICAgICAgPHN0 cmVldD4zIEVseSBSb2FkPC9zdHJlZXQ+CiAgICAgICAgICA8Y2l0eT5NaWx0b24sIENhbWJyaWRn ZTwvY2l0eT4KICAgICAgICAgIDxjb2RlPkNCMjQgNkREPC9jb2RlPgogICAgICAgICAgPGNvdW50 cnk+VUs8L2NvdW50cnk+CiAgICAgICAgPC9wb3N0YWw+CiAgICAgICAgPGVtYWlsPnRob21hcy5m b3NzYXRpQG5va2lhLmNvbTwvZW1haWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgog ICAgPGF1dGhvciBpbml0aWFscz0iRS4iIHN1cm5hbWU9IkRpamsiIGZ1bGxuYW1lPSJFc2tvIERp amsiPgogICAgICA8b3JnYW5pemF0aW9uPlBoaWxpcHMgTGlnaHRpbmc8L29yZ2FuaXphdGlvbj4K ICAgICAgPGFkZHJlc3M+CiAgICAgICAgPHBvc3RhbD4KICAgICAgICAgIDxzdHJlZXQ+SGlnaCBU ZWNoIENhbXB1cyAzNDwvc3RyZWV0PgogICAgICAgICAgPGNpdHk+RWluZGhvdmVuPC9jaXR5Pgog ICAgICAgICAgPGNvZGU+NTY1NiBBRTwvY29kZT4KICAgICAgICAgIDxjb3VudHJ5PlRoZSBOZXRo ZXJsYW5kczwvY291bnRyeT4KICAgICAgICA8L3Bvc3RhbD4KICAgICAgICA8ZW1haWw+ZXNrby5k aWprQHBoaWxpcHMuY29tPC9lbWFpbD4KICAgICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CiAg ICA8ZGF0ZSB5ZWFyPSIyMDE2Ii8+CiAgICA8YXJlYT5BUFA8L2FyZWE+CiAgICA8d29ya2dyb3Vw PkNvUkUgV29ya2luZyBHcm91cDwvd29ya2dyb3VwPgogICAgPGtleXdvcmQ+Q29BUDwva2V5d29y ZD4KICAgIDxrZXl3b3JkPkhUVFAtQ29BUCBtYXBwaW5nPC9rZXl3b3JkPgogICAgPGtleXdvcmQ+ SFRUUC1Db0FQIHRyYW5zbGF0aW9uPC9rZXl3b3JkPgogICAgPGtleXdvcmQ+cHJveHkgaW1wbGVt ZW50YXRpb248L2tleXdvcmQ+CiAgICA8YWJzdHJhY3Q+CiAgICAgIDx0PlRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgcmVmZXJlbmNlIGluZm9ybWF0aW9uIGZvciBpbXBsZW1lbnRpbmcgYSBjcm9zcy1w cm90b2NvbCBuZXR3b3JrIHByb3h5IHRoYXQgcGVyZm9ybXMgdHJhbnNsYXRpb24gZnJvbSB0aGUg SFRUUCBwcm90b2NvbCB0byB0aGUgQ29BUCBwcm90b2NvbC4gIFRoaXMgd2lsbCBlbmFibGUgYSBI VFRQIGNsaWVudCB0byBhY2Nlc3MgcmVzb3VyY2VzIG9uIGEgQ29BUCBzZXJ2ZXIgdGhyb3VnaCB0 aGUgcHJveHkuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBIVFRQIHJlcXVlc3QgaXMg bWFwcGVkIHRvIGEgQ29BUCByZXF1ZXN0LCBhbmQgdGhlbiBob3cgYSBDb0FQIHJlc3BvbnNlIGlz IG1hcHBlZCBiYWNrIHRvIGEgSFRUUCByZXNwb25zZS4gIFRoaXMgaW5jbHVkZXMgZ3VpZGVsaW5l cyBmb3IgVVJJIG1hcHBpbmcsIG1lZGlhIHR5cGUgbWFwcGluZyBhbmQgYWRkaXRpb25hbCBwcm94 eSBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMuICBUaGlzIGRvY3VtZW50IGNvdmVycyB0aGUgUmV2ZXJz ZSwgRm9yd2FyZCBhbmQgSW50ZXJjZXB0aW9uIGNyb3NzLXByb3RvY29sIHByb3h5IGNhc2VzLjwv dD4KICAgIDwvYWJzdHJhY3Q+CiAgPC9mcm9udD4KICA8bWlkZGxlPgogICAgPHNlY3Rpb24gdGl0 bGU9IkludHJvZHVjdGlvbiI+CiAgICAgIDx0PkNvQVAgPHhyZWYgdGFyZ2V0PSJSRkM3MjUyIi8+ IGhhcyBiZWVuIGRlc2lnbmVkIHdpdGggdGhlIHR3b2ZvbGQgYWltIHRvIGJlIGFuIGFwcGxpY2F0 aW9uIHByb3RvY29sIHNwZWNpYWxpemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgYW5k IHRvIGJlIGVhc2lseSB1c2VkIGluIFJlcHJlc2VudGF0aW9uYWwgU3RhdGUgVHJhbnNmZXIgKFJF U1QpIGJhc2VkIGFyY2hpdGVjdHVyZXMgc3VjaCBhcyB0aGUgV2ViLiAgVGhlIGxhdHRlciBnb2Fs IGhhcyBsZWQgdG8gZGVmaW5pbmcgQ29BUCB0byBlYXNpbHkgaW50ZXJvcGVyYXRlIHdpdGggSFRU UCA8eHJlZiB0YXJnZXQ9IlJGQzcyMzAiLz4gdGhyb3VnaCBhbiBpbnRlcm1lZGlhcnkgcHJveHkg d2hpY2ggcGVyZm9ybXMgY3Jvc3MtcHJvdG9jb2wgY29udmVyc2lvbi48L3Q+CgogICAgICA8dD5T ZWN0aW9uIDEwIG9mIDx4cmVmIHRhcmdldD0iUkZDNzI1MiIvPiBkZXNjcmliZXMgdGhlIGZ1bmRh bWVudGFscyBvZiB0aGUgQ29BUC10by1IVFRQIGFuZCB0aGUgSFRUUC10by1Db0FQIGNyb3NzLXBy b3RvY29sIG1hcHBpbmcgcHJvY2Vzcy4gIEhvd2V2ZXIsIDx4cmVmIHRhcmdldD0iUkZDNzI1MiIv PiBmb2N1c2VzIG9uIHRoZSBiYXNpYyBtYXBwaW5nIG9mIHJlcXVlc3QgbWV0aG9kcyBhbmQgc2lt cGxlIHJlc3BvbnNlIGNvZGUgbWFwcGluZyBiZXR3ZWVuIEhUVFAgYW5kIENvQVAsIGFuZCBpdCBs ZWF2ZXMgbWFueSBkZXRhaWxzIG9mIHRoZSBjcm9zcy1wcm90b2NvbCBwcm94eSBmb3IgZnV0dXJl IGRlZmluaXRpb24uICBUaGVyZWZvcmUsIGEgcHJpbWFyeSBnb2FsIG9mIHRoaXMgaW5mb3JtYXRp b25hbCBkb2N1bWVudCBpcyB0byBkZWZpbmUgYSBjb25zaXN0ZW50IHNldCBvZiBndWlkZWxpbmVz IHRoYXQgYW4gSFRUUC10by1Db0FQIHByb3h5IGltcGxlbWVudGF0aW9uIHNob3VsZCBhZGhlcmUg dG8uIFRoZSBrZXkgYmVuZWZpdCB0byBhZGhlcmluZyB0byBzdWNoIGd1aWRlbGluZXMgaXMgdG8g cmVkdWNlIHZhcmlhdGlvbiBiZXR3ZWVuIHByb3h5IGltcGxlbWVudGF0aW9ucywgdGhlcmVieSBp bmNyZWFzaW5nIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBhbiBIVFRQIGNsaWVudCBhbmQgYSBD b0FQIHNlcnZlciBpbmRlcGVuZGVudCBvZiB0aGUgcHJveHkgdGhhdCBpbXBsZW1lbnRzIHRoZSBj cm9zcy1wcm90b2NvbCBtYXBwaW5nLiAoRm9yIGV4YW1wbGUsIGEgcHJveHkgY29uZm9ybWluZyB0 byB0aGVzZSBndWlkZWxpbmVzIG1hZGUgYnkgdmVuZG9yIEEgY2FuIGJlIGVhc2lseSByZXBsYWNl ZCBieSBhIHByb3h5IGZyb20gdmVuZG9yIEIgdGhhdCBhbHNvIGNvbmZvcm1zIHRvIHRoZSBndWlk ZWxpbmVzLik8L3Q+IAoKICAgICAgPHQ+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgSFRUUCBtYXBw aW5ncyB0aGF0IGFwcGx5IHRvIHByb3RvY29sIGVsZW1lbnRzIGRlZmluZWQgaW4gdGhlIGJhc2Ug Q29BUCBzcGVjaWZpY2F0aW9uIDx4cmVmIHRhcmdldD0iUkZDNzI1MiIvPi4gIEl0IGlzIHVwIHRv IENvQVAgcHJvdG9jb2wgZXh0ZW5zaW9ucyAobmV3IG1ldGhvZHMsIHJlc3BvbnNlIGNvZGVzLCBv cHRpb25zLCBjb250ZW50LWZvcm1hdHMpIHRvIGRlc2NyaWJlIHRoZWlyIG93biBIVFRQIG1hcHBp bmdzLCBpZiBhcHBsaWNhYmxlLjwvdD4KCiAgICAgIDx0PlRoaXMgZG9jdW1lbnQgaXMgb3JnYW5p emVkIGFzIGZvbGxvd3M6CiAgICAgICAgPGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAg PHQ+PHhyZWYgdGFyZ2V0PSJ0ZXJtaW5vbG9neSIvPiBkZWZpbmVzIHByb3h5IHRlcm1pbm9sb2d5 OzwvdD4KICAgICAgICAgIDx0Pjx4cmVmIHRhcmdldD0iaGMiLz4gaW50cm9kdWNlcyB0aGUgSFRU UC10by1Db0FQIHByb3h5OzwvdD4KICAgICAgICAgIDx0Pjx4cmVmIHRhcmdldD0idXNlY2FzZXMi Lz4gbGlzdHMgdXNlIGNhc2VzIGluIHdoaWNoIEhUVFAgY2xpZW50cyBuZWVkIHRvIGNvbnRhY3Qg Q29BUCBzZXJ2ZXJzOzwvdD4KICAgICAgICAgIDx0Pjx4cmVmIHRhcmdldD0iVVJJLW1hcHBpbmci Lz4gaW50cm9kdWNlcyBhIG51bGwsIGRlZmF1bHQgYW5kIGFkdmFuY2VkIEhUVFAtdG8tQ29BUCBV UkkgbWFwcGluZyBzeW50YXg7PC90PgogICAgICAgICAgPHQ+PHhyZWYgdGFyZ2V0PSJoYy1tZWRp YSIvPiBkZXNjcmliZXMgaG93IHRvIG1hcCBIVFRQIG1lZGlhIHR5cGVzIHRvIENvQVAgY29udGVu dCBmb3JtYXRzIGFuZCB2aWNlIHZlcnNhOzwvdD4KICAgICAgICAgIDx0Pjx4cmVmIHRhcmdldD0i aGMtcmVzcCIvPiBkZXNjcmliZXMgaG93IHRvIG1hcCBDb0FQIHJlc3BvbnNlcyB0byBIVFRQIHJl c3BvbnNlczs8L3Q+CiAgICAgICAgICA8dD48eHJlZiB0YXJnZXQ9ImhjLWFkZGl0aW9uYWwiLz4g ZGVzY3JpYmVzIGFkZGl0aW9uYWwgbWFwcGluZyBndWlkZWxpbmVzIHJlbGF0ZWQgdG8gY2FjaGlu ZywgY29uZ2VzdGlvbiwgdGltZW91dHMsIGV0Yy47PC90PgogICAgICAgICAgPHQ+PHhyZWYgdGFy Z2V0PSJzZWMiLz4gZGlzY3Vzc2VzIHBvc3NpYmxlIHNlY3VyaXR5IGltcGFjdCBvZiBIVFRQLXRv LUNvQVAgcHJvdG9jb2wgbWFwcGluZy48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CiAg ICA8L3NlY3Rpb24+CgogICAgPCEtLSBNQUlOIFNFQ1RJT04gKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiog LS0+CiAgICA8IS0tIG5vdGUgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gdXNlcyBjYXBpdGFsaXph dGlvbiBvZiBhbGwgdGVybXMsIHdoaWxlIGNhcGl0YWxzIG5vdCB1c2VkIGluIG90aGVyIHNlY3Rp b25zOyBzaW1pbGFyIGluIHN0eWxlIHRvIFJGQzcyNTIuIC0tPgogICAgPHNlY3Rpb24gdGl0bGU9 IlRlcm1pbm9sb2d5IiBhbmNob3I9InRlcm1pbm9sb2d5Ij4KICAgICAgPHQ+VGhlIGtleXdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMjExOSIvPi48L3Q+CgogICAgICA8 dD5IQyBQcm94eTogYSBwcm94eSBwZXJmb3JtaW5nIGEgY3Jvc3MtcHJvdG9jb2wgbWFwcGluZywg aW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudCBhbiBIVFRQLXRvLUNvQVAgKEhDKSBtYXBw aW5nLiBTcGVjaWZpY2FsbHksIHRoZSBIQyBwcm94eSBhY3RzIGFzIGFuIEhUVFAgc2VydmVyIGFu ZCBhIENvQVAgY2xpZW50LiAgVGhlIEhDIFByb3h5IGNhbiB0YWtlIG9uIHRoZSByb2xlIG9mIGEg Rm9yd2FyZCwgUmV2ZXJzZSBvciBJbnRlcmNlcHRpb24gUHJveHkuPC90PgoKICAgICAgPHQ+Rm9y d2FyZCBQcm94eSAob3IgRm9yd2FyZCBIQyBQcm94eSk6IGEgbWVzc2FnZSBmb3J3YXJkaW5nIGFn ZW50IHRoYXQgaXMgc2VsZWN0ZWQgYnkgdGhlIEhUVFAgY2xpZW50LCB1c3VhbGx5IHZpYSBsb2Nh bCBjb25maWd1cmF0aW9uIHJ1bGVzLCB0byByZWNlaXZlIHJlcXVlc3RzIGZvciBzb21lIHR5cGUo cykgb2YgYWJzb2x1dGUgVVJJIGFuZCB0byBhdHRlbXB0IHRvIHNhdGlzZnkgdGhvc2UgcmVxdWVz dHMgdmlhIHRyYW5zbGF0aW9uIHRvIHRoZSBwcm90b2NvbCBpbmRpY2F0ZWQgYnkgdGhlIGFic29s dXRlIFVSSS4gIFRoZSB1c2VyIGRlY2lkZXMgKGlzIHdpbGxpbmcpIHRvIHVzZSB0aGUgcHJveHkg YXMgdGhlIGZvcndhcmRpbmcvZGUtcmVmZXJlbmNpbmcgYWdlbnQgZm9yIGEgcHJlZGVmaW5lZCBz dWJzZXQgb2YgdGhlIFVSSSBzcGFjZS4gSW4gPHhyZWYgdGFyZ2V0PSJSRkM3MjMwIi8+IHRoaXMg aXMgY2FsbGVkIGEgUHJveHkuICA8eHJlZiB0YXJnZXQ9IlJGQzcyNTIiLz4gZGVmaW5lcyBGb3J3 YXJkLVByb3h5IHNpbWlsYXJseS48L3Q+CgogICAgICA8dD5SZXZlcnNlIFByb3h5IChvciBSZXZl cnNlIEhDIFByb3h5KTogYXMgaW4gPHhyZWYgdGFyZ2V0PSJSRkM3MjMwIi8+LCBhIHJlY2Vpdmlu ZyBhZ2VudCB0aGF0IGFjdHMgYXMgYSBsYXllciBhYm92ZSBzb21lIG90aGVyIHNlcnZlcihzKSBh bmQgdHJhbnNsYXRlcyB0aGUgcmVjZWl2ZWQgcmVxdWVzdHMgdG8gdGhlIHVuZGVybHlpbmcgc2Vy dmVyJ3MgcHJvdG9jb2wuICBBIFJldmVyc2UgSEMgUHJveHkgYmVoYXZlcyBhcyBhbiBvcmlnaW4g KEhUVFApIHNlcnZlciBvbiBpdHMgY29ubmVjdGlvbiBmcm9tIHRoZSBIVFRQIGNsaWVudC4gIFRo ZSBIVFRQIGNsaWVudCB1c2VzIHRoZSAib3JpZ2luLWZvcm0iIChTZWN0aW9uIDUuMy4xIG9mIDx4 cmVmIHRhcmdldD0iUkZDNzIzMCIvPikgYXMgYSByZXF1ZXN0LXRhcmdldCBVUkkuPC90PgoKICAg ICAgPHQ+SW50ZXJjZXB0aW9uIFByb3h5IChvciBJbnRlcmNlcHRpb24gSEMgUHJveHkpIDx4cmVm IHRhcmdldD0iUkZDMzA0MCIvPjogYSBwcm94eSB0aGF0IHJlY2VpdmVzIGluYm91bmQgSFRUUCB0 cmFmZmljIGZsb3dzIHRocm91Z2ggdGhlIHByb2Nlc3Mgb2YgdHJhZmZpYyByZWRpcmVjdGlvbjsg dHJhbnNwYXJlbnQgdG8gdGhlIEhUVFAgY2xpZW50LjwvdD4KCiAgICAgIDx0Pk5vdGUgdGhhdCBh IFJldmVyc2UgUHJveHkgYXBwZWFycyB0byBhbiBIVFRQIGNsaWVudCBhcyBhbiBvcmlnaW4gc2Vy dmVyIHdoaWxlIGEgRm9yd2FyZCBQcm94eSBkb2VzIG5vdC4gU28sIHdoZW4gY29tbXVuaWNhdGlu ZyB3aXRoIGEgUmV2ZXJzZSBQcm94eSBhIGNsaWVudCBtYXkgYmUgdW5hd2FyZSBpdCBpcyBjb21t dW5pY2F0aW5nIHdpdGggYSBwcm94eSBhdCBhbGwuPC90PgogICAgPC9zZWN0aW9uPgoKICAgIDwh LS0gTUFJTiBTRUNUSU9OICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIC0tPgogICAgPHNlY3Rpb24gdGl0 bGU9IkhUVFAtdG8tQ29BUCBQcm94eSIgYW5jaG9yPSJoYyI+CiAgICAgIDx0PkEgSEMgcHJveHkg aXMgYWNjZXNzZWQgYnkgYW4gSFRUUCBjbGllbnQgd2hpY2ggd2FudHMgdG8gYWNjZXNzIGEgcmVz b3VyY2Ugb24gYSBDb0FQIHNlcnZlci4gIFRoZSBIQyBwcm94eSBoYW5kbGVzIHRoZSBIVFRQIHJl cXVlc3QgYnkgbWFwcGluZyBpdCB0byB0aGUgZXF1aXZhbGVudCBDb0FQIHJlcXVlc3QsIHdoaWNo IGlzIHRoZW4gZm9yd2FyZGVkIHRvIHRoZSBhcHByb3ByaWF0ZSBDb0FQIHNlcnZlci4gIFRoZSBy ZWNlaXZlZCBDb0FQIHJlc3BvbnNlIGlzIHRoZW4gbWFwcGVkIHRvIGFuIGFwcHJvcHJpYXRlIEhU VFAgcmVzcG9uc2UgYW5kIGZpbmFsbHkgc2VudCBiYWNrIHRvIHRoZSBvcmlnaW5hdGluZyBIVFRQ IGNsaWVudC48L3Q+CgogICAgICA8IS0tIG5vdGUgYW55IHJlZmVyZW5jZXMgdG8gZmlndXJlIGVu dGl0aWVzIHdpbGwgdXNlIGNhcGl0YWxpemF0aW9uIGJlY2F1c2UgdGhleSBhcmUgbmFtZWQgaW5z dGFuY2VzIG9mIHRoZSBnZW5lcmljIGVudGl0aWVzLiAgVGhlIGluc3RhbmNlIG5hbWUgaGFwcGVu cyB0byBiZSBlcXVhbCB0byB0aGUgZ2VuZXJpYyBuYW1lLiAgLS0+CgogICAgICA8dD5TZWUgPHhy ZWYgdGFyZ2V0PSJmaWctaHR0cC1jb2FwLWRlcGxveW1lbnQiLz4gZm9yIGFuIGV4YW1wbGUgZGVw bG95bWVudCBzY2VuYXJpby4gSGVyZSBhIEhDIHByb3h5IGlzIGxvY2F0ZWQgYXQgdGhlIGJvdW5k YXJ5IG9mIHRoZSBDb25zdHJhaW5lZCBOZXR3b3JrIGRvbWFpbiwgdG8gYXZvaWQgc2VuZGluZyBh bnkgSFRUUCB0cmFmZmljIGludG8gdGhlIENvbnN0cmFpbmVkIE5ldHdvcmsgYW5kIHRvIGF2b2lk IGFueSAodW5zZWN1cmVkKSBDb0FQIG11bHRpY2FzdCB0cmFmZmljIG91dHNpZGUgdGhlIENvbnN0 cmFpbmVkIE5ldHdvcmsuICBBIEROUyBzZXJ2ZXIgKG5vdCBzaG93bikgaXMgdXNlZCBieSB0aGUg SFRUUCBDbGllbnQgdG8gcmVzb2x2ZSB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgSEMgcHJveHkgYW5k IG9wdGlvbmFsbHkgYWxzbyB1c2VkIGJ5IHRoZSBIQyBwcm94eSB0byByZXNvbHZlIElQIGFkZHJl c3NlcyBvZiBDb0FQIHNlcnZlcnMuPC90PgoKICAgICAgICA8ZmlndXJlIHRpdGxlPSJIVFRQLVRv LUNvQVAgUHJveHkgRGVwbG95bWVudCBTY2VuYXJpbyIgYW5jaG9yPSJmaWctaHR0cC1jb2FwLWRl cGxveW1lbnQiPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbnN0cmFpbmVkIE5ldHdv cmsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4tLS0tLS0tLS0t LS0tLS0tLS0tLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvICAg ICAgLi0tLS0tLS4gICAgICAgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8gICAgICAgfCBDb0FQIHwgICAgICAgIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8gICAgICAgIHxzZXJ2ZXJ8ICAgICAgICAgXAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgJy0tLS0tLScgICAgICAgICB8fAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAg ICAgICB8fAogIC4tLS0tLS0tLS4gIEhUVFAgUmVxdWVzdCAgIC4tLS0tLS0tLS0tLS0uICBDb0FQ IFJlcSAgLi0tLS0tLS4gICB8fAogIHwgIEhUVFAgIHwtLS0tLS0tLS0tLS0tLS0tPnxIVFRQLXRv LUNvQVB8LS0tLS0tLS0tLS0+fCBDb0FQIHwgICB8fAogIHwgQ2xpZW50IHw8LS0tLS0tLS0tLS0t LS0tLXwgICBQcm94eSAgICB8PC0tLS0tLS0tLS0tfFNlcnZlcnwgICB8fAogICctLS0tLS0tLScg IEhUVFAgUmVzcG9uc2UgICctLS0tLS0tLS0tLS0nICBDb0FQIFJlc3AgJy0tLS0tLScgICB8fAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAg ICAgICAgICB8fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fCAgIC4t LS0tLS0uICAgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8fCAgIHwgQ29BUCB8ICAgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXCAgIHxzZXJ2ZXJ8ICAuLS0tLS0tLiAgICAvCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgJy0tLS0tLScgIHwgQ29BUCB8ICAgLwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICB8c2Vy dmVyfCAgLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAg ICAgICAnLS0tLS0tJyAvCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJy0tLS0tLS0tLS0tLS0tLS0tJwogICAgICAgICAgICBdXT4KICAgICAgICAgIDwvYXJ0d29y az4KICAgICAgICA8L2ZpZ3VyZT4KCgogICAgICA8dD5Ob3JtYXRpdmUgcmVxdWlyZW1lbnRzIG9u IHRoZSB0cmFuc2xhdGlvbiBvZiBIVFRQIHJlcXVlc3RzIHRvIENvQVAgcmVxdWVzdHMgYW5kIG9m IHRoZSBDb0FQIHJlc3BvbnNlcyBiYWNrIHRvIEhUVFAgcmVzcG9uc2VzIGFyZSBkZWZpbmVkIGlu IFNlY3Rpb24gMTAuMiBvZiA8eHJlZiB0YXJnZXQ9IlJGQzcyNTIiLz4uICBIb3dldmVyLCA8eHJl ZiB0YXJnZXQ9IlJGQzcyNTIiLz4gZm9jdXNlcyBvbiB0aGUgYmFzaWMgbWFwcGluZyBvZiByZXF1 ZXN0IG1ldGhvZHMgYW5kIHNpbXBsZSByZXNwb25zZSBjb2RlIG1hcHBpbmcgYmV0d2VlbiBIVFRQ IGFuZCBDb0FQLCBhbmQgbGVhdmVzIG1hbnkgZGV0YWlscyBvZiB0aGUgY3Jvc3MtcHJvdG9jb2wg SEMgcHJveHkgZm9yIGZ1dHVyZSBkZWZpbml0aW9uLiAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBh ZGRpdGlvbmFsIGd1aWRlbGluZXMgYW5kIG1vcmUgZGV0YWlscyBmb3IgdGhlIGltcGxlbWVudGF0 aW9uIG9mIGEgSEMgUHJveHksIHdoaWNoIHNob3VsZCBiZSBmb2xsb3dlZCBpbiBhZGRpdGlvbiB0 byB0aGUgbm9ybWF0aXZlIHJlcXVpcmVtZW50cy4gTm90ZSB0aGF0IHRoZSBndWlkZWxpbmVzIGFw cGx5IHRvIGFsbCBmb3JtcyBvZiBhbiBIQyBwcm94eSAoaS5lLiBSZXZlcnNlLCBGb3J3YXJkLCBJ bnRlcmNlcHRpbmcpIHVubGVzcyBleHBsaWNpdGx5IG90aGVyd2lzZSBub3RlZC48L3Q+CiAgICA8 L3NlY3Rpb24+CgoKICAgIDwhLS0gKioqKioqKioqKioqKioqKioqKiBNQUlOIFNFQ1RJT04gKioq KioqKioqKioqKioqKioqKiogLS0+CiAgICA8c2VjdGlvbiBhbmNob3I9InVzZWNhc2VzIiB0aXRs ZT0iVXNlIENhc2VzIj4KICAgICAgPHQ+VG8gaWxsdXN0cmF0ZSB0aGUgc2l0dWF0aW9ucyBIVFRQ IHRvIENvQVAgcHJvdG9jb2wgdHJhbnNsYXRpb24gbWF5IGJlIHVzZWQsIHRocmVlIHVzZSBjYXNl cyBhcmUgZGVzY3JpYmVkIGJlbG93LjwvdD4KCiAgICAgIDx0PjEuIExlZ2FjeSBidWlsZGluZyBj b250cm9sIGFwcGxpY2F0aW9uIHdpdGhvdXQgQ29BUDogQSBidWlsZGluZyBjb250cm9sIGFwcGxp Y2F0aW9uIHRoYXQgdXNlcyBIVFRQIGJ1dCBub3QgQ29BUCBjYW4gY2hlY2sgdGhlIHN0YXR1cyBv ZiBDb0FQIHNlbnNvcnMgYW5kL29yIGNvbnRyb2wgYWN0dWF0b3JzIHZpYSBhIEhDIHByb3h5Ljwv dD4KCiAgICAgIDx0PjIuIE1ha2luZyBzZW5zb3IgZGF0YSBhdmFpbGFibGUgdG8gM3JkIHBhcnRp ZXMgb24gdGhlIFdlYjogRm9yIGRlbW9uc3RyYXRpb24gb3IgcHVibGljIGludGVyZXN0IHB1cnBv c2VzLCBhIEhDIHByb3h5IG1heSBiZSBjb25maWd1cmVkIHRvIGV4cG9zZSB0aGUgY29udGVudHMg b2YgYSBDb0FQIHNlbnNvciB0byB0aGUgd29ybGQgdmlhIHRoZSB3ZWIgKEhUVFAgYW5kL29yIEhU VFBTKS4gIFNvbWUgc2Vuc29ycyBtYXkgb25seSBhY2NlcHQgc2VjdXJlICdjb2FwcycgcmVxdWVz dHMsIHRoZXJlZm9yZSB0aGUgcHJveHkgaXMgY29uZmlndXJlZCB0byB0cmFuc2xhdGUgcmVxdWVz dCB0byB0aG9zZSBkZXZpY2VzIGFjY29yZGluZ2x5LiAgVGhlIEhDIHByb3h5IGlzIGZ1cnRoZXJt b3JlIGNvbmZpZ3VyZWQgdG8gb25seSBwYXNzIHRocm91Z2ggR0VUIHJlcXVlc3RzIGluIG9yZGVy IHRvIHByb3RlY3QgdGhlIGNvbnN0cmFpbmVkIG5ldHdvcmsuPC90PgoKCSAgPHQ+My4gU21hcnRw aG9uZSBhbmQgaG9tZSBzZW5zb3I6IEEgc21hcnRwaG9uZSBjYW4gYWNjZXNzIGRpcmVjdGx5IGEg Q29BUCBob21lIHNlbnNvciB1c2luZyBhIG11dHVhbGx5IGF1dGhlbnRpY2F0ZWQgJ2h0dHBzJyBy ZXF1ZXN0LCBwcm92aWRlZCBpdHMgaG9tZSByb3V0ZXIgcnVucyBhIEhDIHByb3h5IGFuZCBpcyBj b25maWd1cmVkIHdpdGggdGhlIGFwcHJvcHJpYXRlIGNlcnRpZmljYXRlLiAgQW4gSFRNTDUgYXBw bGljYXRpb24gb24gdGhlIHNtYXJ0cGhvbmUgY2FuIHByb3ZpZGUgYSBmcmllbmRseSBVSSB1c2lu ZyB0aGUgc3RhbmRhcmQgKEhUVFApIG5ldHdvcmtpbmcgZnVuY3Rpb25zIG9mIEhUTUw1LjwvdD4K CgkgIDx0PkEga2V5IHBvaW50IGluIHRoZSBhYm92ZSB1c2UgY2FzZXMgaXMgdGhlIGV4cGVjdGVk IG5hdHVyZSBvZiB0aGUgVVJJIHRvIGJlIHVzZWQgYnkgdGhlIEhUVFAgY2xpZW50IGluaXRpYXRp bmcgdGhlIEhUVFAgcmVxdWVzdCB0byB0aGUgSEMgcHJveHkuICBTcGVjaWZpY2FsbHksIGluIHVz ZSBjYXNlICMxLCB0aGVyZSB3aWxsIGJlIG5vICJjb2FwIiBvciAiY29hcHMiIHJlbGF0ZWQgaW5m b3JtYXRpb24gZW1iZWRkZWQgaW4gdGhlIEhUVFAgVVJJIGFzIGl0IGlzIGEgbGVnYWN5IEhUVFAg Y2xpZW50IHNlbmRpbmcgdGhlIHJlcXVlc3QuIFVzZSBjYXNlICMyIGlzIGFsc28gZXhwZWN0ZWQg dG8gYmUgc2ltaWxhci4gIEluIGNvbnRyYXN0LCBpbiB1c2UgY2FzZSAjMywgaXQgaXMgZXhwZWN0 ZWQgdGhhdCB0aGUgSFRUUCBjbGllbnQgd2lsbCBzcGVjaWZpY2FsbHkgZW1iZWQgImNvYXAiIG9y ICJjb2FwcyIgcmVsYXRlZCBpbmZvcm1hdGlvbiBpbiB0aGUgSFRUUCBVUkkgb2YgdGhlIEhUVFAg cmVxdWVzdCB0byB0aGUgSEMgcHJveHkuPC90PgoKICAgIDwvc2VjdGlvbj4KCiAgICA8IS0tICoq KioqKioqKioqKioqKioqKiogTUFJTiBTRUNUSU9OICoqKioqKioqKioqKioqKioqKioqIC0tPgog ICAgPHNlY3Rpb24gYW5jaG9yPSJVUkktbWFwcGluZyIgdGl0bGU9IlVSSSBNYXBwaW5nIj4KICAg ICAgPHQ+VGhvdWdoLCBpbiBwcmluY2lwbGUsIGEgQ29BUCBVUkkgY291bGQgYmUgZGlyZWN0bHkg dXNlZCBieSBhIEhUVFAgY2xpZW50IHRvIGRlLXJlZmVyZW5jZSBhIENvQVAgcmVzb3VyY2UgdGhy b3VnaCBhIEhDIHByb3h5LCB0aGUgcmVhbGl0eSBpcyB0aGF0IGFsbCBtYWpvciB3ZWIgYnJvd3Nl cnMsIG5ldHdvcmtpbmcgbGlicmFyaWVzIGFuZCBjb21tYW5kIGxpbmUgdG9vbHMgZG8gbm90IGFs bG93IG1ha2luZyBIVFRQIHJlcXVlc3RzIHVzaW5nIFVSSXMgd2l0aCBhIHNjaGVtZSAiY29hcCIg b3IgImNvYXBzIi48L3Q+CgogICAgICA8dD5UaHVzLCB0aGVyZSBpcyBhIG5lZWQgZm9yIHdlYiBh cHBsaWNhdGlvbnMgdG8gZW1iZWQgb3IgInBhY2siIGEgQ29BUCBVUkkgaW50byBhIEhUVFAgVVJJ IHNvIHRoYXQgaXQgY2FuIGJlIChub24tZGVzdHJ1Y3RpdmVseSkgdHJhbnNwb3J0ZWQgZnJvbSB0 aGUgSFRUUCBjbGllbnQgdG8gdGhlIEhDIHByb3h5LiAgVGhlIEhDIHByb3h5IGNhbiB0aGVuICJ1 bnBhY2siIHRoZSBDb0FQIFVSSSBhbmQgZmluYWxseSBkZS1yZWZlcmVuY2UgaXQgdmlhIGEgQ29B UCByZXF1ZXN0IHRvIHRoZSB0YXJnZXQgU2VydmVyLjwvdD4KCiAgICAgIDx0PlVSSSBNYXBwaW5n IGlzIHRoZSB0ZXJtIHVzZWQgaW4gdGhlIGRvY3VtZW50IHRvIGRlc2NyaWJlIHRoZSBwcm9jZXNz IHRocm91Z2ggd2hpY2ggdGhlIFVSSSBvZiBhIENvQVAgcmVzb3VyY2UgaXMgdHJhbnNmb3JtZWQg aW50byBhbiBIVFRQIFVSSSBzbyB0aGF0OgogICAgICAgIDxsaXN0IHN0eWxlPSJzeW1ib2xzIj4K ICAgICAgICAgIDx0PnRoZSByZXF1ZXN0aW5nIEhUVFAgY2xpZW50IGNhbiBoYW5kbGUgaXQ7PC90 PgogICAgICAgICAgPHQ+dGhlIHJlY2VpdmluZyBIQyBwcm94eSBjYW4gZXh0cmFjdCB0aGUgaW50 ZW5kZWQgQ29BUCBVUkkgdW5hbWJpZ3VvdXNseS48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8 L3Q+CgogICAgICA8dD5UbyB0aGlzIGVuZCwgdGhlIHJlbWFpbmRlciBvZiB0aGlzIHNlY3Rpb24g d2lsbCBpZGVudGlmeToKICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICA8 dD50aGUgZGVmYXVsdCBtZWNoYW5pc20gdG8gbWFwIGEgQ29BUCBVUkkgaW50byBhIEhUVFAgVVJJ OzwvdD4KICAgICAgICAgIDx0PnRoZSBVUkkgdGVtcGxhdGUgZm9ybWF0IHRvIGV4cHJlc3MgYSBj bGFzcyBvZiBDb0FQLUhUVFAgVVJJIG1hcHBpbmcgZnVuY3Rpb25zOzwvdD4KICAgICAgICAgIDx0 PnRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIGJhc2VkIG9uIENvUkUgTGluayBGb3JtYXQgPHhyZWYg dGFyZ2V0PSJSRkM2NjkwIi8+IHRocm91Z2ggd2hpY2ggY2xpZW50cyBvZiBhIEhDIHByb3h5IGNh biBkeW5hbWljYWxseSBkaXNjb3ZlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc3VwcG9ydGVkIFVS SSBNYXBwaW5nIFRlbXBsYXRlKHMpLCBhcyB3ZWxsIGFzIHRoZSBVUkkgd2hlcmUgdGhlIEhDIHBy b3h5IGZ1bmN0aW9uIGlzIGFuY2hvcmVkLjwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4K CiAgICAgIDxzZWN0aW9uIHRpdGxlPSJVUkkgVGVybWlub2xvZ3kiPgogICAgICAgIDx0PkluIHRo ZSByZW1haW5kZXIgb2YgdGhpcyBzZWN0aW9uLCB0aGUgZm9sbG93aW5nIHRlcm1zIHdpbGwgYmUg dXNlZCB3aXRoIGEgZGlzdGluY3RpdmUgbWVhbmluZzoKICAgICAgICAgIDxsaXN0IHN0eWxlPSJo YW5naW5nIiBoYW5nSW5kZW50PSI4Ij4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IkhDIFByb3h5 IFVSSToiPjx2c3BhY2UvPlVSSSB3aGljaCByZWZlcnMgdG8gdGhlIEhDIHByb3h5IGZ1bmN0aW9u LiAgSXQgY29uZm9ybXMgdG8gc3ludGF4IGRlZmluZWQgaW4gU2VjdGlvbiAyLjcgb2YgPHhyZWYg dGFyZ2V0PSJSRkM3MjMwIi8+LjwvdD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlRhcmdldCBD b0FQIFVSSToiPjx2c3BhY2UvPlVSSSB3aGljaCByZWZlcnMgdG8gdGhlIChmaW5hbCkgQ29BUCBy ZXNvdXJjZSB0aGF0IGhhcyB0byBiZSBkZS1yZWZlcmVuY2VkLiAgSXQgY29uZm9ybXMgdG8gc3lu dGF4IGRlZmluZWQgaW4gU2VjdGlvbiA2IG9mIDx4cmVmIHRhcmdldD0iUkZDNzI1MiIvPi4gIFNw ZWNpZmljYWxseSwgaXRzIHNjaGVtZSBpcyBlaXRoZXIgImNvYXAiIG9yICJjb2FwcyIuPC90Pgog ICAgICAgICAgICA8dCBoYW5nVGV4dD0iSG9zdGluZyBIVFRQIFVSSToiPjx2c3BhY2UvPlVSSSB0 aGF0IGNvbmZvcm1zIHRvIHN5bnRheCBpbiBTZWN0aW9uIDIuNyBvZiA8eHJlZiB0YXJnZXQ9IlJG QzcyMzAiLz4uICBJdHMgYXV0aG9yaXR5IGNvbXBvbmVudCByZWZlcnMgdG8gYSBIQyBwcm94eSwg d2hlcmVhcyBwYXRoIChhbmQgcXVlcnkpIGNvbXBvbmVudChzKSBlbWJlZCB0aGUgaW5mb3JtYXRp b24gdXNlZCBieSBhIEhDIHByb3h5IHRvIGV4dHJhY3QgdGhlIFRhcmdldCBDb0FQIFVSSS48L3Q+ CiAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8 c2VjdGlvbiB0aXRsZT0iTnVsbCBNYXBwaW5nIiBhbmNob3I9InNlY3Rpb24ubnVsbC1tYXBwaW5n Ij4KICAgICAgICA8dD5UaGUgbnVsbCBtYXBwaW5nIGlzIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGlz IG5vIFRhcmdldCBDb0FQIFVSSSBhcHBlbmRlZCB0byB0aGUgSEMgUHJveHkgVVJJLiAgSW4gb3Ro ZXIgd29yZHMsIGl0IGlzIGEgInB1cmUiIEhUVFAgVVJJIHRoYXQgaXMgc2VudCB0byB0aGUgSEMg UHJveHkuICBUaGlzIHdvdWxkIHR5cGljYWxseSBvY2N1ciBpbiBzaXR1YXRpb25zIGxpa2UgVXNl IENhc2UgIzEgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0idXNlY2FzZXMiLz4sIGFuZCB0aGUg UHJveHkgd291bGQgdHlwaWNhbGx5IGJlIGEgUmV2ZXJzZSBQcm94eS4gSW4gdGhpcyBzY2VuYXJp bywgdGhlIEhDIFByb3h5IHdpbGwgZGV0ZXJtaW5lIHRocm91Z2ggaXRzIG93biBwcm9wcmlldGFy eSBhbGdvcml0aG1zIHdoYXQgdGhlIFRhcmdldCBDb0FQIFVSSSBzaG91bGQgYmUuPC90PgogICAg ICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iRGVmYXVsdCBNYXBwaW5nIiBhbmNo b3I9InNlY3Rpb24uZGVmYXVsdC1tYXBwaW5nIj4KICAgICAgICA8dD5UaGUgZGVmYXVsdCBtYXBw aW5nIGlzIGZvciB0aGUgVGFyZ2V0IENvQVAgVVJJIHRvIGJlIGFwcGVuZGVkIGFzLWlzIHRvIHRo ZSBIQyBQcm94eSBVUkksIHRvIGZvcm0gdGhlIEhvc3RpbmcgSFRUUCBVUkkuICBUaGlzIGlzIHRo ZSBVUkkgdGhhdCB3aWxsIHRoZW4gYmUgc2VudCBieSB0aGUgSFRUUCBjbGllbnQgaW4gdGhlIEhU VFAgcmVxdWVzdCB0byB0aGUgSEMgcHJveHkuPC90PgoKICAgICAgICA8dD5Gb3IgZXhhbXBsZTog Z2l2ZW4gYSBIQyBQcm94eSBVUkkgaHR0cDovL3AuZXhhbXBsZS5jb20vaGMvIGFuZCBhIFRhcmdl dCBDb0FQIFVSSSBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodCwgdGhlIHJlc3VsdGluZyBIb3N0 aW5nIEhUVFAgVVJJIHdvdWxkIGJlIGh0dHA6Ly9wLmV4YW1wbGUuY29tL2hjL2NvYXA6Ly9zLmV4 YW1wbGUuY29tL2xpZ2h0LjwvdD4KCiAgICAgICAgPHQ+UHJvdmlkZWQgYSBjb3JyZWN0IFRhcmdl dCBDb0FQIFVSSSwgdGhlIEhvc3RpbmcgSFRUUCBVUkkgcmVzdWx0aW5nIGZyb20gdGhlIGRlZmF1 bHQgbWFwcGluZyBpcyBhbHdheXMgc3ludGFjdGljYWxseSBjb3JyZWN0LiAgRnVydGhlcm1vcmUs IHRoZSBUYXJnZXQgQ29BUCBVUkkgY2FuIGFsd2F5cyBiZSBleHRyYWN0ZWQgdW5hbWJpZ3VvdXNs eSBmcm9tIHRoZSBIb3N0aW5nIEhUVFAgVVJJLiAgQWxzbywgaXQgaXMgd29ydGggbm90aW5nIHRo YXQsIHVzaW5nIHRoZSBkZWZhdWx0IG1hcHBpbmcsIGEgcXVlcnkgY29tcG9uZW50IGluIHRoZSB0 YXJnZXQgQ29BUCByZXNvdXJjZSBVUkkgaXMgbmF0dXJhbGx5IGVuY29kZWQgaW50byB0aGUgcXVl cnkgY29tcG9uZW50IG9mIHRoZSBIb3N0aW5nIFVSSSwgZS5nLjogY29hcDovL3MuZXhhbXBsZS5j b20vbGlnaHQ/ZGltPTUgYmVjb21lcyBodHRwOi8vcC5leGFtcGxlLmNvbS9oYy9jb2FwOi8vcy5l eGFtcGxlLmNvbS9saWdodD9kaW09NS48L3Q+CgogICAgICAgIDx0PlRoZXJlIGlzIG5vIGRlZmF1 bHQgZm9yIHRoZSBIQyBQcm94eSBVUkkuICBUaGVyZWZvcmUsIGl0IGlzIGVpdGhlciBrbm93biBp biBhZHZhbmNlLCBlLmcuIGFzIGEgY29uZmlndXJhdGlvbiBwcmVzZXQsIG9yIGR5bmFtaWNhbGx5 IGRpc2NvdmVyZWQgdXNpbmcgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0 PSJzZWN0aW9uLmRpc2NvdmVyeSIvPi48L3Q+CgogICAgICAgIDx0PlRoZSBkZWZhdWx0IFVSSSBt YXBwaW5nIGZ1bmN0aW9uIFNIT1VMRCBiZSBpbXBsZW1lbnRlZCBhbmQgYWN0aXZhdGVkIGJ5IGRl ZmF1bHQgaW4gYSBIQyBwcm94eSwgdW5sZXNzIHRoZXJlIGFyZSB2YWxpZCByZWFzb25zLCBlLmcu IGFwcGxpY2F0aW9uIHNwZWNpZmljLCB0byB1c2UgYSBkaWZmZXJlbnQgbWFwcGluZyBmdW5jdGlv bi48L3Q+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJPcHRpb25hbCBTY2hlbWUgT21pc3Npb24i IGFuY2hvcj0ic2VjdGlvbi5vcHRpb25hbC1zY2hlbWUiPgogICAgICAgICAgPHQ+V2hlbiBmb3Vu ZCBpbiBhIEhvc3RpbmcgSFRUUCBVUkksIHRoZSBzY2hlbWUgKGkuZS4sICJjb2FwIiBvciAiY29h cHMiKSwgdGhlIHNjaGVtZSBjb21wb25lbnQgZGVsaW1pdGVyICgiOiIpLCBhbmQgdGhlIGRvdWJs ZSBzbGFzaCAoIi8vIikgcHJlY2VkaW5nIHRoZSBhdXRob3JpdHkgTUFZIGJlIG9taXR0ZWQuICBJ biBzdWNoIGNhc2UsIGEgbG9jYWwgZGVmYXVsdCAtIG5vdCBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1l bnQgLSBhcHBsaWVzLjwvdD4KCiAgICAgICAgICA8dD5TbywgaHR0cDovL3AuZXhhbXBsZS5jb20v aGMvcy5jb2FwLmV4YW1wbGUuY29tL2ZvbyBjb3VsZCBlaXRoZXIgcmVwcmVzZW50IHRoZSB0YXJn ZXQgY29hcDovL3MuY29hcC5leGFtcGxlLmNvbS9mb28gb3IgY29hcHM6Ly9zLmNvYXAuZXhhbXBs ZS5jb20vZm9vIGRlcGVuZGluZyBvbiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBwcmVzZXRzLjwvdD4K ICAgICAgICA8L3NlY3Rpb24+IDwhLS0gT3B0aW9uYWwgc2NoZW1lIC0tPgoKICAgICAgICA8c2Vj dGlvbiB0aXRsZT0iRW5jb2RpbmcgQ2F2ZWF0cyIgYW5jaG9yPSJzZWN0aW9uLmVuY29kaW5nLWNh dmVhdHMiPgogICAgICAgICAgPHQ+V2hlbiB0aGUgYXV0aG9yaXR5IG9mIHRoZSBUYXJnZXQgQ29B UCBVUkkgaXMgZ2l2ZW4gYXMgYW4gSVB2NmFkZHJlc3MsIHRoZW4gdGhlIHN1cnJvdW5kaW5nIHNx dWFyZSBicmFja2V0cyBtdXN0IGJlIHBlcmNlbnQtZW5jb2RlZCBpbiB0aGUgSG9zdGluZyBIVFRQ IFVSSSwgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGggdGhlIHN5bnRheCBkZWZpbmVkIGluIFNlY3Rp b24gMy4zLiBvZiA8eHJlZiB0YXJnZXQ9IlJGQzM5ODYiLz4gZm9yIGEgVVJJIHBhdGggc2VnbWVu dC4gIEUuZy46IGNvYXA6Ly9bMjAwMTpkYjg6OjFdL2xpZ2h0P29uIGJlY29tZXMgaHR0cDovL3Au ZXhhbXBsZS5jb20vaGMvY29hcDovLyU1QjIwMDE6ZGI4OjoxJTVEL2xpZ2h0P29uLjwvdD4KICAg ICAgICAgIDx0PkV2ZXJ5dGhpbmcgZWxzZSBjYW4gYmUgc2FmZWx5IGNvcGllZCB2ZXJiYXRpbSBm cm9tIHRoZSBUYXJnZXQgQ29BUCBVUkkgdG8gdGhlIEhvc3RpbmcgSFRUUCBVUkkuPC90PgogICAg ICAgIDwvc2VjdGlvbj4gPCEtLSBFbmNvZGluZyBDYXZlYXRzIC0tPgogICAgICA8L3NlY3Rpb24+ IDwhLS0gRGVmYXVsdCBNYXBwaW5nIC0tPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9IlVSSSBNYXBw aW5nIFRlbXBsYXRlIj4KICAgICAgICA8dD5UaGlzIHNlY3Rpb24gZGVmaW5lcyBhIGZvcm1hdCBm b3IgdGhlIFVSSSB0ZW1wbGF0ZSA8eHJlZiB0YXJnZXQ9IlJGQzY1NzAiLz4gdXNlZCBieSBhIEhD IHByb3h5IHRvIGluZm9ybSBpdHMgY2xpZW50cyBhYm91dCB0aGUgZXhwZWN0ZWQgc3ludGF4IGZv ciB0aGUgSG9zdGluZyBIVFRQIFVSSS4gIFRoaXMgd2lsbCB0aGVuIGJlIHVzZWQgYnkgdGhlIEhU VFAgY2xpZW50IHRvIGNvbnN0cnVjdCB0aGUgVVJJIHRvIGJlIHNlbnQgaW4gdGhlIEhUVFAgcmVx dWVzdCB0byB0aGUgSEMgcHJveHkuPC90PgoKICAgICAgICA8dD5XaGVuIGluc3RhbnRpYXRlZCwg YW4gVVJJIE1hcHBpbmcgVGVtcGxhdGUgaXMgYWx3YXlzIGNvbmNhdGVuYXRlZCB0byBhIEhDIFBy b3h5IFVSSSBwcm92aWRlZCBieSB0aGUgSEMgcHJveHkgdmlhIGRpc2NvdmVyeSAoc2VlIDx4cmVm IHRhcmdldD0ic2VjdGlvbi5kaXNjb3ZlcnkiLz4pLCBvciBieSBvdGhlciBtZWFucy48L3Q+Cgog ICAgICAgIDx0PkEgc2ltcGxlIGZvcm0gKDx4cmVmIHRhcmdldD0ic2VjdGlvbi5zaW1wbGUtZm9y bSIvPikgYW5kIGFuIGVuaGFuY2VkIGZvcm0gKDx4cmVmIHRhcmdldD0ic2VjdGlvbi5lbmhhbmNl ZC1mb3JtIi8+KSBhcmUgcHJvdmlkZWQgdG8gZml0IGRpZmZlcmVudCB1c2VycycgcmVxdWlyZW1l bnRzLjwvdD4KCiAgICAgICAgPHQ+Qm90aCBmb3JtcyBhcmUgZXhwcmVzc2VkIGFzIGxldmVsIDIg VVJJIHRlbXBsYXRlcyA8eHJlZiB0YXJnZXQ9IlJGQzY1NzAiLz4gdG8gdGFrZSBjYXJlIG9mIHRo ZSBleHBhbnNpb24gb2YgdmFsdWVzIHRoYXQgYXJlIGFsbG93ZWQgdG8gaW5jbHVkZSByZXNlcnZl ZCBVUkkgY2hhcmFjdGVycy4gIFRoZSBzeW50YXggb2YgYWxsIFVSSSBmb3JtYXRzIGlzIHNwZWNp ZmllZCBpbiB0aGlzIHNlY3Rpb24gaW4gQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0gKEFCTkYp IDx4cmVmIHRhcmdldD0iUkZDNTIzNCIvPi48L3Q+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJT aW1wbGUgRm9ybSIgYW5jaG9yPSJzZWN0aW9uLnNpbXBsZS1mb3JtIj4KICAgICAgICAgIDx0PlRo ZSBzaW1wbGUgZm9ybSBNVVNUIGJlIHVzZWQgZm9yIG1hcHBpbmdzIHdoZXJlIHRoZSBUYXJnZXQg Q29BUCBVUkkgaXMgZ29pbmcgdG8gYmUgY29waWVkICh1c2luZyBydWxlcyBvZiA8eHJlZiB0YXJn ZXQ9InNlY3Rpb24uZW5jb2RpbmctY2F2ZWF0cyIvPikgYXQgc29tZSBmaXhlZCBwb3NpdGlvbiBp bnRvIHRoZSBIb3N0aW5nIEhUVFAgVVJJLjwvdD4KCiAgICAgICAgICA8dD5UaGUgInR1IiB0ZW1w bGF0ZSB2YXJpYWJsZSBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGluIGEgdGVtcGxhdGUgZGVmaW5p dGlvbiB0byByZXByZXNlbnQgYSBUYXJnZXQgQ29BUCBVUkk6CiAgICAgICAgICAgIDxmaWd1cmU+ CiAgICAgICAgICAgICAgPGFydHdvcms+CiAgICB0dSA9IGNvYXAtVVJJIC8gY29hcHMtVVJJICA7 IGZyb20gW1JGQzcyNTJdLCBTZWN0aW9uIDYuMSBhbmQgNi4yCiAgICAgICAgICAgICAgPC9hcnR3 b3JrPgogICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIFRoZSBzYW1lIGNvbnNpZGVyYXRp b25zIGFzIGluIDx4cmVmIHRhcmdldD0ic2VjdGlvbi5vcHRpb25hbC1zY2hlbWUiLz4gYXBwbHks IGluIHRoYXQgdGhlIENvQVAgc2NoZW1lIG1heSBiZSBvbWl0dGVkIGZyb20gdGhlIEhvc3Rpbmcg SFRUUCBVUkkuPC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJFeGFtcGxlcyI+CiAgICAg ICAgICAgIDx0PkFsbCB0aGUgZm9sbG93aW5nIGV4YW1wbGVzIChnaXZlbiBhcyBhIHNwZWNpZmlj IFVSSSBtYXBwaW5nIHRlbXBsYXRlLCBhIFRhcmdldCBDb0FQIFVSSSwgYW5kIHRoZSBwcm9kdWNl ZCBIb3N0aW5nIEhUVFAgVVJJKSB1c2UgaHR0cDovL3AuZXhhbXBsZS5jb20vaGMgYXMgdGhlIEhD IFByb3h5IFVSSS4gIE5vdGUgdGhhdCB0aGVzZSBleGFtcGxlcyBhbGwgZGVmaW5lIG1hcHBpbmcg dGVtcGxhdGVzIHRoYXQgZGV2aWF0ZSBmcm9tIHRoZSBkZWZhdWx0IHRlbXBsYXRlIG9mIDx4cmVm IHRhcmdldD0ic2VjdGlvbi5kZWZhdWx0LW1hcHBpbmciLz4gdG8gYmUgYWJsZSB0byBpbGx1c3Ry YXRlIHRoZSB1c2Ugb2YgdGhlIGFib3ZlIHRlbXBsYXRlIHZhcmlhYmxlcy48L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSJudW1iZXJzIj4KICAgICAgICAgICAg ICAgIDx0PlRhcmdldCBDb0FQIFVSSSBpcyBhIHF1ZXJ5IGFyZ3VtZW50IG9mIHRoZSBIb3N0aW5n IEhUVFAgVVJJOgogICAgICAgICAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAgICAgICAgICAg IDxhcnR3b3JrPgogICAgICAgICAgICAgICAgICAgICAgPCFbQ0RBVEFbCj90YXJnZXRfdXJpPXsr dHV9Cgpjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodAoKaHR0cDovL3AuZXhhbXBsZS5jb20vaGM/ dGFyZ2V0X3VyaT1jb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodAoKb3IKCmNvYXBzOi8vcy5leGFt cGxlLmNvbS9saWdodAoKaHR0cDovL3AuZXhhbXBsZS5jb20vaGM/dGFyZ2V0X3VyaT1jb2Fwczov L3MuZXhhbXBsZS5jb20vbGlnaHQKICAgICAgICAgICAgICAgICAgICAgIF1dPgogICAgICAgICAg ICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAg ICAgICAgICA8L3Q+CgogICAgICAgICAgICAgICAgPHQ+VGFyZ2V0IENvQVAgVVJJIGluIHRoZSBw YXRoIGNvbXBvbmVudCBvZiB0aGUgSG9zdGluZyBIVFRQIFVSSToKICAgICAgICAgICAgICAgICAg PGZpZ3VyZT4KICAgICAgICAgICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgICAgICAg ICAgIDwhW0NEQVRBWwoveyt0dX0KCmNvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0CgpodHRwOi8v cC5leGFtcGxlLmNvbS9oYy9jb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodAoKb3IKCmNvYXBzOi8v cy5leGFtcGxlLmNvbS9saWdodAoKaHR0cDovL3AuZXhhbXBsZS5jb20vaGMvY29hcHM6Ly9zLmV4 YW1wbGUuY29tL2xpZ2h0CiAgICAgICAgICAgICAgICAgICAgICBdXT4KICAgICAgICAgICAgICAg ICAgICA8L2FydHdvcms+CiAgICAgICAgICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgICAg ICAgPC90PgoKICAgICAgICAgICAgICAgIDx0PiJjb2FwIiBVUkkgaXMgYSBxdWVyeSBhcmd1bWVu dCBvZiB0aGUgSG9zdGluZyBIVFRQIFVSSTsgY2xpZW50IGRlY2lkZXMgdG8gb21pdCBzY2hlbWUg YmVjYXVzZSBhIGRlZmF1bHQgc2NoZW1lIGlzIGFncmVlZCBiZWZvcmVoYW5kIGJldHdlZW4gY2xp ZW50IGFuZCBwcm94eToKICAgICAgICAgICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgICAg ICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgICAgICAgICAgIDwhW0NEQVRBWwo/Y29hcF91cmk9 eyt0dX0KCmNvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0CgpodHRwOi8vcC5leGFtcGxlLmNvbS9o Yz9jb2FwX3VyaT1zLmV4YW1wbGUuY29tL2xpZ2h0CiAgICAgICAgICAgICAgICAgICAgICBdXT4K ICAgICAgICAgICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICAgICAgICAgIDwvZmlndXJl PgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgICAg PC90PgogICAgICAgICAgPC9zZWN0aW9uPiA8IS0tIEV4YW1wbGVzIC0tPgogICAgICAgIDwvc2Vj dGlvbj4gPCEtLSBTaW1wbGUgRm9ybSAtLT4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IkVuaGFu Y2VkIEZvcm0iIGFuY2hvcj0ic2VjdGlvbi5lbmhhbmNlZC1mb3JtIj4KICAgICAgICAgIDx0PlRo ZSBlbmhhbmNlZCBmb3JtIGNhbiBiZSB1c2VkIHRvIGV4cHJlc3MgbW9yZSBzb3BoaXN0aWNhdGVk IG1hcHBpbmdzIG9mIHRoZSBUYXJnZXQgQ29BUCBVUkkgaW50byB0aGUgSG9zdGluZyBIVFRQIFVS SSwgaS5lLiwgbWFwcGluZ3MgdGhhdCBkbyBub3QgZml0IGludG8gdGhlIHNpbXBsZSBmb3JtLjwv dD4KICAgICAgICAgIDx0PlRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgaW5zdGFuY2Ugb2YgZWFj aCBvZiB0aGUgZm9sbG93aW5nIHRlbXBsYXRlIHZhcmlhYmxlcyBpbiBhIHRlbXBsYXRlIGRlZmlu aXRpb246CiAgICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgICAgPGFydHdvcms+CiAgICAg ICAgICAgICAgICA8IVtDREFUQVsKICAgIHMgID0gImNvYXAiIC8gImNvYXBzIiA7IGZyb20gW1JG QzcyNTJdLCBTZWN0aW9ucyA2LjEgYW5kIDYuMgogICAgaHAgPSBob3N0IFsiOiIgcG9ydF0gIDsg ZnJvbSBbUkZDMzk4Nl0sIFNlY3Rpb25zIDMuMi4yIGFuZCAzLjIuMwogICAgcCAgPSBwYXRoLWFi ZW1wdHkgICAgIDsgZnJvbSBbUkZDMzk4Nl0sIFNlY3Rpb24gMy4zCiAgICBxICA9IHF1ZXJ5ICAg ICAgICAgICAgOyBmcm9tIFtSRkMzOTg2XSwgU2VjdGlvbiAzLjQgCiAgICBxcSA9IFsgIj8iIHF1 ZXJ5IF0gICAgOyBxcSBpcyBlbXB0eSBpZiBhbmQgb25seSBpZiAncXVlcnknIGlzIGVtcHR5CiAg ICAgICAgICAgICAgICBdXT4KICAgICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICAgIDwv ZmlndXJlPgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+VGhlIHFxIGZvcm0gaXMgdXNlZCB3 aGVuIHRoZSBwYXRoIGFuZCB0aGUgKG9wdGlvbmFsKSBxdWVyeSBjb21wb25lbnRzIGFyZSB0byBi ZSBjb3BpZWQgdmVyYmF0aW0gZnJvbSB0aGUgVGFyZ2V0IENvQVAgVVJJIGludG8gdGhlIEhvc3Rp bmcgSFRUUCBVUkksIGkuZS4gYXMgInsrcH17K3FxfSIuICBJbnN0ZWFkLCB0aGUgcSBmb3JtIGlz IHVzZWQgd2hlbiB0aGUgcXVlcnkgYW5kIHBhdGggYXJlIG1hcHBlZCBhcyBzZXBhcmF0ZSBlbnRp dGllcywgZS5nLiBhcyBpbiAiY29hcF9wYXRoPXsrcH0mYW1wO2NvYXBfcXVlcnk9eytxfSIuPC90 PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJFeGFtcGxlcyI+CiAgICAgICAgICAgIDx0PkFs bCB0aGUgZm9sbG93aW5nIGV4YW1wbGVzIChnaXZlbiBhcyBhIHNwZWNpZmljIFVSSSBtYXBwaW5n IHRlbXBsYXRlLCBhIFRhcmdldCBDb0FQIFVSSSwgYW5kIHRoZSBwcm9kdWNlZCBIb3N0aW5nIEhU VFAgVVJJKSB1c2UgaHR0cDovL3AuZXhhbXBsZS5jb20vaGMgYXMgdGhlIEhDIFByb3h5IFVSSS48 L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSJudW1iZXJzIj4K ICAgICAgICAgICAgICAgIDx0PlRhcmdldCBDb0FQIFVSSSBjb21wb25lbnRzIGluIHBhdGggc2Vn bWVudHMsIGFuZCBvcHRpb25hbCBxdWVyeSBpbiBxdWVyeSBjb21wb25lbnQ6CiAgICAgICAgICAg ICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAg ICAgICAgICAgICA8IVtDREFUQVsKICAgIC97K3N9L3sraHB9eytwfXsrcXF9CgogICAgY29hcDov L3MuZXhhbXBsZS5jb20vbGlnaHQKCiAgICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYy9jb2FwL3Mu ZXhhbXBsZS5jb20vbGlnaHQKCiAgICBvcgoKICAgIGNvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0 P29uCgogICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGMvY29hcC9zLmV4YW1wbGUuY29tL2xpZ2h0 P29uCiAgICAgICAgICAgICAgICAgICAgICBdXT4KICAgICAgICAgICAgICAgICAgICA8L2FydHdv cms+CiAgICAgICAgICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgICAgICAgPC90PgoKICAg ICAgICAgICAgICAgIDx0PlRhcmdldCBDb0FQIFVSSSBjb21wb25lbnRzIHNwbGl0IGluIGluZGl2 aWR1YWwgcXVlcnkgYXJndW1lbnRzOgogICAgICAgICAgICAgICAgICA8ZmlndXJlPgogICAgICAg ICAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgICAgICAgICAgPCFbQ0RBVEFbCiAg ICA/cz17K3N9JmhwPXsraHB9JnA9eytwfSZxPXsrcX0KCiAgICBjb2FwOi8vcy5leGFtcGxlLmNv bS9saWdodAoKICAgIGh0dHA6Ly9wLmV4YW1wbGUuY29tL2hjP3M9Y29hcCZocD1zLmV4YW1wbGUu Y29tJnA9L2xpZ2h0JnE9CgogICAgb3IKCiAgICBjb2FwczovL3MuZXhhbXBsZS5jb20vbGlnaHQ/ b24KCiAgICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYz9zPWNvYXBzJmhwPXMuZXhhbXBsZS5jb20m cD0vbGlnaHQmcT1vbgogICAgICAgICAgICAgICAgICAgICAgXV0+CiAgICAgICAgICAgICAgICAg ICAgPC9hcnR3b3JrPgogICAgICAgICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICAgIDwvdD4KICAgICAgICAgIDwv c2VjdGlvbj4gPCEtLSBFeGFtcGxlcyAtLT4KICAgICAgICA8L3NlY3Rpb24+IDwhLS0gRW5oYW5j ZWQgRm9ybSAtLT4KICAgICAgPC9zZWN0aW9uPiA8IS0tIFVSSSBNYXBwaW5nIFRlbXBsYXRlIC0t PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9IkRpc2NvdmVyeSIgYW5jaG9yPSJzZWN0aW9uLmRpc2Nv dmVyeSI+CiAgICAgICAgPHQ+SW4gb3JkZXIgdG8gYWNjb21tb2RhdGUgc2l0ZSBzcGVjaWZpYyBu ZWVkcyB3aGlsZSBhbGxvd2luZyB0aGlyZCBwYXJ0aWVzIHRvIGRpc2NvdmVyIHRoZSBwcm94eSBm dW5jdGlvbiwgdGhlIEhDIHByb3h5IFNIT1VMRCBwdWJsaXNoIGluZm9ybWF0aW9uIHJlbGF0ZWQg dG8gdGhlIGxvY2F0aW9uIGFuZCBzeW50YXggb2YgdGhlIEhDIHByb3h5IGZ1bmN0aW9uIHVzaW5n IHRoZSBDb1JFIExpbmsgRm9ybWF0IDx4cmVmIHRhcmdldD0iUkZDNjY5MCIvPiBpbnRlcmZhY2Uu PC90PgoKICAgICAgICA8dD5UbyB0aGlzIGFpbSBhIG5ldyBSZXNvdXJjZSBUeXBlLCAiY29yZS5o YyIsIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gSXQgY2FuIGJlIHVzZWQgYXMgdGhlIHZh bHVlIGZvciB0aGUgInJ0IiBhdHRyaWJ1dGUgaW4gYSBxdWVyeSB0byB0aGUgLy53ZWxsLWtub3du L2NvcmUgaW4gb3JkZXIgdG8gbG9jYXRlIHRoZSBVUkkgd2hlcmUgdGhlIEhDIHByb3h5IGZ1bmN0 aW9uIGlzIGFuY2hvcmVkLCBpLmUuIHRoZSBIQyBQcm94eSBVUkkuPC90PgogIAogICAgICAgIDx0 PkFsb25nIHdpdGggaXQsIHRoZSBuZXcgdGFyZ2V0IGF0dHJpYnV0ZSAiaGN0IiBpcyBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQuIFRoaXMgYXR0cmlidXRlIE1BWSBiZSByZXR1cm5lZCBpbiBhICJj b3JlLmhjIiBsaW5rIHRvIHByb3ZpZGUgdGhlIFVSSSBNYXBwaW5nIFRlbXBsYXRlIGFzc29jaWF0 ZWQgdG8gdGhlIG1hcHBpbmcgcmVzb3VyY2UuICBUaGUgZGVmYXVsdCB0ZW1wbGF0ZSBnaXZlbiBp biA8eHJlZiB0YXJnZXQ9InNlY3Rpb24uZGVmYXVsdC1tYXBwaW5nIi8+LCBpLmUuLCB7K3R1fSwg TVVTVCBiZSBhc3N1bWVkIGlmIG5vICJoY3QiIGF0dHJpYnV0ZSBpcyBmb3VuZCBpbiB0aGUgcmV0 dXJuZWQgbGluay4gIElmIGEgImhjdCIgYXR0cmlidXRlIGlzIHByZXNlbnQgaW4gdGhlIHJldHVy bmVkIGxpbmssIHRoZW4gYSBjbGllbnQgTVVTVCB1c2UgaXQgdG8gY3JlYXRlIHRoZSBIb3N0aW5n IEhUVFAgVVJJLjwvdD4KCiAgICAgICAgPHQ+VGhlIFVSSSBtYXBwaW5nIFNIT1VMRCBiZSBkaXNj b3ZlcmFibGUgKGFzIHNwZWNpZmllZCBpbiBbUkZDNjY5MF0pIG9uIGJvdGggdGhlIEhUVFAgYW5k IHRoZSBDb0FQIHNpZGUgb2YgdGhlIEhDIHByb3h5LCB3aXRoIG9uZSBpbXBvcnRhbnQgZGlmZmVy ZW5jZTogb24gdGhlIENvQVAgc2lkZSB0aGUgbGluayBhc3NvY2lhdGVkIHRvIHRoZSAiY29yZS5o YyIgcmVzb3VyY2UgbmVlZHMgYW4gZXhwbGljaXQgYW5jaG9yIHJlZmVycmluZyB0byB0aGUgSFRU UCBvcmlnaW4sIHdoaWxlIG9uIHRoZSBIVFRQIGludGVyZmFjZSB0aGUgbGluayBjb250ZXh0IGlz IGFscmVhZHkgdGhlIEhUVFAgb3JpZ2luIGNhcnJpZWQgaW4gdGhlIHJlcXVlc3QncyBIb3N0IGhl YWRlciwgYW5kIGRvZXNuJ3QgaGF2ZSB0byBiZSBtYWRlIGV4cGxpY2l0LjwvdD4KCgogICAgICAg IDxzZWN0aW9uIHRpdGxlPSJFeGFtcGxlcyI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxp c3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAgICAgIDx0PlRoZSBmaXJzdCBleGFtcGxlIGV4 ZXJjaXNlcyB0aGUgQ29BUCBpbnRlcmZhY2UsIGFuZCBhc3N1bWVzIHRoYXQgdGhlIGRlZmF1bHQg dGVtcGxhdGUsIHsrdHV9LCBpcyB1c2VkLiAgRm9yIGV4YW1wbGUsIGluIHVzZSBjYXNlICMzIGlu IHNlY3Rpb24gPHhyZWYgdGFyZ2V0PSJ1c2VjYXNlcyIvPiwgdGhlIHNtYXJ0cGhvbmUgbWF5IGRp c2NvdmVyIHRoZSBwdWJsaWMgSEMgcHJveHkgYmVmb3JlIGxlYXZpbmcgdGhlIGhvbWUgbmV0d29y ay4gIFRoZW4gd2hlbiBvdXRzaWRlIHRoZSBob21lIG5ldHdvcmssIHRoZSBzbWFydHBob25lIHdp bGwgYmUgYWJsZSB0byBxdWVyeSB0aGUgYXBwcm9wcmlhdGUgaG9tZSBzZW5zb3IuCiAgICAgICAg ICAgICAgICA8ZmlndXJlPgogICAgICAgICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAg ICAgICAgICA8IVtDREFUQVsKICAgIFJlcTogIEdFVCBjb2FwOi8vW2ZmMDI6OjFdLy53ZWxsLWtu b3duL2NvcmU/cnQ9Y29yZS5oYwoKICAgIFJlczogIDIuMDUgQ29udGVudAogICAgICAgICAgPC9o Yy8+O2FuY2hvcj0iaHR0cDovL3AuZXhhbXBsZS5jb20iO3J0PSJjb3JlLmhjIgogICAgICAgICAg ICAgICAgICAgIF1dPgogICAgICAgICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICAgICAg ICA8L2ZpZ3VyZT4KICAgICAgICAgICAgICA8L3Q+CiAKICAgICAgICAgICAgICA8dD5UaGUgc2Vj b25kIGV4YW1wbGUgLSBhbHNvIG9uIHRoZSBDb0FQIHNpZGUgb2YgdGhlIEhDIHByb3h5IC0gdXNl cyBhIGN1c3RvbSB0ZW1wbGF0ZSwgaS5lLiwgb25lIHdoZXJlIHRoZSBDb0FQIFVSSSBpcyBjYXJy aWVkIGluc2lkZSB0aGUgcXVlcnkgY29tcG9uZW50LCB0aHVzIHRoZSByZXR1cm5lZCBsaW5rIGNh cnJpZXMgdGhlIFVSSSB0ZW1wbGF0ZSB0byBiZSB1c2VkIGluIGFuIGV4cGxpY2l0ICJoY3QiIGF0 dHJpYnV0ZToKICAgICAgICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgICAgICAgIDxhcnR3 b3JrPgogICAgICAgICAgICAgICAgICAgIDwhW0NEQVRBWwogICAgUmVxOiAgR0VUIGNvYXA6Ly9b ZmYwMjo6MV0vLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjCgogICAgUmVzOiAgMi4wNSBDb250 ZW50CiAgICAgICAgICA8L2hjPjthbmNob3I9Imh0dHA6Ly9wLmV4YW1wbGUuY29tIjsKICAgICAg ICAgIHJ0PSJjb3JlLmhjIjtoY3Q9Ij91cmk9eyt0dX0iCiAgICAgICAgICAgICAgICAgICAgXV0+ CiAgICAgICAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAgICAgIDwvZmlndXJlPgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgoKICAgICAgICBPbiB0aGUgSFRU UCBzaWRlLCBsaW5rIGluZm9ybWF0aW9uIGNhbiBiZSBzZXJpYWxpemVkIGluIG1vcmUgdGhhbiBv bmUgd2F5OgogICAgICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICAgICAg PHQ+dXNpbmcgdGhlICdhcHBsaWNhdGlvbi9saW5rLWZvcm1hdCcgY29udGVudCB0eXBlOgogICAg ICAgICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAg ICAgICAgICAgICAgPCFbQ0RBVEFbCiAgICBSZXE6ICBHRVQgLy53ZWxsLWtub3duL2NvcmU/cnQ9 Y29yZS5oYyBIVFRQLzEuMQogICAgICAgICAgSG9zdDogcC5leGFtcGxlLmNvbQoKICAgIFJlczog IEhUVFAvMS4xIDIwMCBPSwogICAgICAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9saW5r LWZvcm1hdAogICAgICAgICAgQ29udGVudC1MZW5ndGg6IDE4CgogICAgICAgICAgPC9oYy8+O3J0 PSJjb3JlLmhjIgogICAgICAgICAgICAgICAgICAgIF1dPgogICAgICAgICAgICAgICAgICAgIDwv YXJ0d29yaz4KICAgICAgICAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICAgICAgICA8L3Q+ CiAKICAgICAgICAgICAgICAgIDx0PnVzaW5nIHRoZSAnYXBwbGljYXRpb24vbGluay1mb3JtYXQr anNvbicgY29udGVudCB0eXBlIGFzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJJLUQuaWV0Zi1j b3JlLWxpbmtzLWpzb24iLz46CiAgICAgICAgICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAg ICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgICAgICAgICA8IVtDREFUQVsKICAgIFJl cTogIEdFVCAvLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xCiAgICAgICAgICBI b3N0OiBwLmV4YW1wbGUuY29tCgogICAgUmVzOiAgSFRUUC8xLjEgMjAwIE9LCiAgICAgICAgICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2xpbmstZm9ybWF0K2pzb24KICAgICAgICAgIENvbnRl bnQtTGVuZ3RoOiAzMQoKICAgICAgICAgIFt7ImhyZWYiOiIvaGMvIiwicnQiOiJjb3JlLmhjIn1d CiAgICAgICAgICAgICAgICAgICAgXV0+CiAgICAgICAgICAgICAgICAgIDwvYXJ0d29yaz4KICAg ICAgICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgICAgIDwvdD4KIAogICAgICAgICAgICAg IDx0PnVzaW5nIHRoZSBMaW5rIGhlYWRlcjoKICAgICAgICAgICAgICAgIDxmaWd1cmU+CiAgICAg ICAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgICAgICAgIDwhW0NEQVRBWwogICAg UmVxOiAgR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUuaGMgSFRUUC8xLjEKICAgICAgICAg IEhvc3Q6IHAuZXhhbXBsZS5jb20KCiAgICBSZXM6ICBIVFRQLzEuMSAyMDAgT0sKICAgICAgICAg IExpbms6IDwvaGMvPjtydD0iY29yZS5oYyIKICAgICAgICAgICAgICAgICAgICBdXT4KICAgICAg ICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9z ZWN0aW9uPiA8IS0tIEV4YW1wbGVzIC0tPgogICAgICA8L3NlY3Rpb24+IDwhLS0gRGlzY292ZXJ5 IC0tPgogICAgPC9zZWN0aW9uPiA8IS0tIFVSSSBNYXBwaW5nIC0tPgoKCiAgICA8IS0tICoqKioq KioqKioqKioqKioqKiogTUFJTiBTRUNUSU9OICoqKioqKioqKioqKioqKioqKioqIC0tPgogICAg PHNlY3Rpb24gdGl0bGU9Ik1lZGlhIFR5cGUgTWFwcGluZyIgYW5jaG9yPSJoYy1tZWRpYSI+CiAg ICAgIDxzZWN0aW9uIHRpdGxlPSJPdmVydmlldyI+CiAgICAgICAgPHQ+QSBIQyBwcm94eSBuZWVk cyB0byB0cmFuc2xhdGUgSFRUUCBtZWRpYSB0eXBlcyAoU2VjdGlvbiAzLjEuMS4xIG9mIDx4cmVm IHRhcmdldD0iUkZDNzIzMSIvPikgYW5kIGNvbnRlbnQgZW5jb2RpbmdzIChTZWN0aW9uIDMuMS4y LjIgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjMxIi8+KSBpbnRvIENvQVAgY29udGVudCBmb3JtYXRz IChTZWN0aW9uIDEyLjMgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjUyIi8+KSBhbmQgdmljZSB2ZXJz YS48L3Q+CiAgICAgICAgPHQ+TWVkaWEgdHlwZSB0cmFuc2xhdGlvbiBjYW4gaGFwcGVuIGluIEdF VCwgUFVUIG9yIFBPU1QgcmVxdWVzdHMgZ29pbmcgZnJvbSBIVFRQIHRvIENvQVAsIGFuZCBpbiAy Lnh4IChpLmUuLCBzdWNjZXNzZnVsKSByZXNwb25zZXMgZ29pbmcgZnJvbSBDb0FQIHRvIEhUVFAu ICBTcGVjaWZpY2FsbHksIFBVVCBhbmQgUE9TVCBuZWVkIHRvIG1hcCBib3RoIHRoZSBDb250ZW50 LVR5cGUgYW5kIENvbnRlbnQtRW5jb2RpbmcgSFRUUCBoZWFkZXJzIGludG8gYSBzaW5nbGUgQ29B UCBDb250ZW50LUZvcm1hdCBvcHRpb24sIHdoZXJlYXMgR0VUIG5lZWRzIHRvIG1hcCBBY2NlcHQg YW5kIEFjY2VwdC1FbmNvZGluZyBIVFRQIGhlYWRlcnMgaW50byBhIHNpbmdsZSBDb0FQIEFjY2Vw dCBvcHRpb24uICBUbyBnZW5lcmF0ZSB0aGUgSFRUUCByZXNwb25zZSwgdGhlIENvQVAgQ29udGVu dC1Gb3JtYXQgb3B0aW9uIGlzIG1hcHBlZCBiYWNrIHRvIGEgc3VpdGFibGUgSFRUUCBDb250ZW50 LVR5cGUgYW5kIENvbnRlbnQtRW5jb2RpbmcgY29tYmluYXRpb24uPC90PgoKICAgICAgICA8dD5B biBIVFRQIHJlcXVlc3QgY2FycnlpbmcgYSBDb250ZW50LVR5cGUgYW5kIENvbnRlbnQtRW5jb2Rp bmcgY29tYmluYXRpb24gd2hpY2ggdGhlIEhDIHByb3h5IGlzIHVuYWJsZSB0byBtYXAgdG8gYW4g ZXF1aXZhbGVudCBDb0FQIENvbnRlbnQtRm9ybWF0LCBTSEFMTCBlbGljaXQgYSA0MTUgKFVuc3Vw cG9ydGVkIE1lZGlhIFR5cGUpIHJlc3BvbnNlIGJ5IHRoZSBIQyBwcm94eS48L3Q+CgogICAgICAg IDx0Pk9uIHRoZSBjb250ZW50IG5lZ290aWF0aW9uIHNpZGUsIGZhaWx1cmUgdG8gbWFwIEFjY2Vw dCBhbmQgQWNjZXB0LSogaGVhZGVycyBTSE9VTEQgYmUgc2lsZW50bHkgaWdub3JlZDogdGhlIEhD IHByb3h5IFNIT1VMRCB0aGVyZWZvcmUgZm9yd2FyZCBhcyBhIENvQVAgcmVxdWVzdCB3aXRoIG5v IEFjY2VwdCBvcHRpb24uICBUaGUgSEMgcHJveHkgdGh1cyBkaXNyZWdhcmRzIHRoZSBBY2NlcHQv QWNjZXB0LSogaGVhZGVyIGZpZWxkcyBieSB0cmVhdGluZyB0aGUgcmVzcG9uc2UgYXMgaWYgaXQg aXMgbm90IHN1YmplY3QgdG8gY29udGVudCBuZWdvdGlhdGlvbiwgYXMgbWVudGlvbmVkIGluIFNl Y3Rpb25zIDUuMy4qIG9mIDx4cmVmIHRhcmdldD0iUkZDNzIzMSIvPi4gIEhvd2V2ZXIsIGEgSEMg cHJveHkgaW1wbGVtZW50YXRpb24gaXMgZnJlZSB0byBhdHRlbXB0IG1hcHBpbmcgYSBzaW5nbGUg QWNjZXB0IGhlYWRlciBpbiBhIEdFVCByZXF1ZXN0IHRvIG11bHRpcGxlIENvQVAgR0VUIHJlcXVl c3RzLCBlYWNoIHdpdGggYSBzaW5nbGUgQWNjZXB0IG9wdGlvbiwgd2hpY2ggYXJlIHRoZW4gdHJp ZWQgaW4gc2VxdWVuY2UgdW50aWwgb25lIHN1Y2NlZWRzLiAgTm90ZSB0aGF0IGFuIEhUVFAgQWNj ZXB0ICovKiBNVVNUIGJlIG1hcHBlZCB0byBhIENvQVAgcmVxdWVzdCB3aXRob3V0IEFjY2VwdCBv cHRpb24uPC90PgoKICAgICAgICA8dD5XaGlsZSB0aGUgQ29BUCB0byBIVFRQIGRpcmVjdGlvbiBo YXMgYWx3YXlzIGEgd2VsbCBkZWZpbmVkIG1hcHBpbmcgKHdpdGggdGhlIGV4Y2VwdGlvbiBleGFt aW5lZCBpbiA8eHJlZiB0YXJnZXQ9InNlYy1hcHBsaWNhdGlvbi1jb2FwLXBheWxvYWQiLz4pLCB0 aGUgSFRUUCB0byBDb0FQIGRpcmVjdGlvbiBpcyBtb3JlIHByb2JsZW1hdGljIGJlY2F1c2UgdGhl IHNvdXJjZSBzZXQsIGkuZS4sIHBvdGVudGlhbGx5IDEwMDArIElBTkEgcmVnaXN0ZXJlZCBtZWRp YSB0eXBlcywgaXMgbXVjaCBiaWdnZXIgdGhhbiB0aGUgZGVzdGluYXRpb24gc2V0LCBpLmUuLCB0 aGUgbWVyZSA2IHZhbHVlcyBpbml0aWFsbHkgZGVmaW5lZCBpbiBTZWN0aW9uIDEyLjMgb2YgPHhy ZWYgdGFyZ2V0PSJSRkM3MjUyIi8+LjwvdD4KCiAgICAgICAgPHQ+RGVwZW5kaW5nIG9uIHRoZSB0 aWdodC9sb29zZSBjb3VwbGluZyB3aXRoIHRoZSBhcHBsaWNhdGlvbihzKSBmb3Igd2hpY2ggaXQg cHJveGllcywgdGhlIEhDIHByb3h5IGNvdWxkIGltcGxlbWVudCBkaWZmZXJlbnQgbWVkaWEgdHlw ZSBtYXBwaW5ncy48L3Q+CgogICAgICAgIDx0PldoZW4gdGlnaHRseSBjb3VwbGVkLCB0aGUgSEMg cHJveHkga25vd3MgZXhhY3RseSB3aGljaCBjb250ZW50IGZvcm1hdHMgYXJlIHN1cHBvcnRlZCBi eSB0aGUgYXBwbGljYXRpb25zLCBhbmQgY2FuIGJlIHN0cmljdCB3aGVuIGVuZm9yY2luZyBpdHMg Zm9yd2FyZGluZyBwb2xpY2llcyBpbiBnZW5lcmFsLCBhbmQgdGhlIG1lZGlhIHR5cGUgbWFwcGlu ZyBpbiBwYXJ0aWN1bGFyLjwvdD4KCiAgICAgICAgPHQ+T24gdGhlIG90aGVyIHNpZGUsIHdoZW4g dGhlIEhDIHByb3h5IGlzIGEgZ2VuZXJhbCBwdXJwb3NlIGFwcGxpY2F0aW9uIGxheWVyIGdhdGV3 YXksIGJlaW5nIHRvbyBzdHJpY3QgY291bGQgc2lnbmlmaWNhbnRseSByZWR1Y2UgdGhlIGFtb3Vu dCBvZiB0cmFmZmljIHRoYXQgaXQgd291bGQgYmUgYWJsZSB0byBzdWNjZXNzZnVsbHkgZm9yd2Fy ZC4gIEluIHRoaXMgY2FzZSwgdGhlICJsb29zZSIgbWVkaWEgdHlwZSBtYXBwaW5nIGRldGFpbGVk IGluIDx4cmVmIHRhcmdldD0ic2VjLWxvb3NlLW10LW1hcHBpbmciLz4gTUFZIGJlIGltcGxlbWVu dGVkLjwvdD4KCiAgICAgICAgPCEtLSBUT0RPL3RiZCBtb3ZlIGl0IHRvIFNlYyBDb25zIC0tPgog ICAgICAgIDx0PlRoZSBsYXR0ZXIgZ3JhbnRzIG1vcmUgZXZvbHV0aW9uIG9mIHRoZSBzdXJyb3Vu ZGluZyBlY29zeXN0ZW0sIGF0IHRoZSBjb3N0IG9mIGFsbG93aW5nIG1vcmUgYXR0YWNrIHN1cmZh Y2UuICBJbiBmYWN0LCBhcyBhIHJlc3VsdCBvZiBzdWNoIHN0cmF0ZWd5LCBwYXlsb2FkcyB3b3Vs ZCBiZSBmb3J3YXJkZWQgbW9yZSBsaWJlcmFsbHkgYWNyb3NzIHRoZSB1bmNvbnN0cmFpbmVkL2Nv bnN0cmFpbmVkIG5ldHdvcmsgYm91bmRhcnkgb2YgdGhlIGNvbW11bmljYXRpb24gcGF0aC4gIFRo ZXJlZm9yZSwgd2hlbiBhcHBsaWVkLCBvdGhlciBmb3JtcyBvZiBhY2Nlc3MgY29udHJvbCBtdXN0 IGJlIHNldCBpbiBwbGFjZSB0byBhdm9pZCB1bmF1dGhvcml6ZWQgdXNlcnMgdG8gZGVwbGV0ZSBv ciBhYnVzZSBzeXN0ZW1zIGFuZCBuZXR3b3JrIHJlc291cmNlcy48L3Q+CiAgICAgIDwvc2VjdGlv bj4gIDwhLS0gT3ZlcnZpZXcgLS0+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iJ2FwcGxpY2F0aW9u L2NvYXAtcGF5bG9hZCcgTWVkaWEgVHlwZSIgYW5jaG9yPSJzZWMtYXBwbGljYXRpb24tY29hcC1w YXlsb2FkIj4KICAgICAgICA8dD5JZiB0aGUgSEMgcHJveHkgcmVjZWl2ZXMgYSBDb0FQIHJlc3Bv bnNlIHdpdGggYSBDb250ZW50LUZvcm1hdCB0aGF0IGl0IGRvZXMgbm90IHJlY29nbml6ZSAoZS5n LiBiZWNhdXNlIHRoZSB2YWx1ZSBoYXMgYmVlbiByZWdpc3RlcmVkIGFmdGVyIHRoZSBwcm94eSBo YXMgYmVlbiBkZXBsb3llZCwgb3IgdGhlIENvQVAgc2VydmVyIHVzZXMgYW4gZXhwZXJpbWVudGFs IHZhbHVlIHdoaWNoIGlzIG5vdCByZWdpc3RlcmVkKSwgdGhlbiB0aGUgSEMgcHJveHkgU0hBTEwg cmV0dXJuIGEgZ2VuZXJpYyAiYXBwbGljYXRpb24vY29hcC1wYXlsb2FkIiBtZWRpYSB0eXBlIHdp dGggbnVtZXJpYyBwYXJhbWV0ZXIgImNmIiBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0ic2Vj LWNvYXAtcGF5bG9hZC1yZWciLz4uPC90PgoKICAgICAgICA8dD5Gb3IgZXhhbXBsZSwgdGhlIENv QVAgY29udGVudCBmb3JtYXQgJzYwJyAoImFwcGxpY2F0aW9uL2Nib3IiKSB3b3VsZCBiZSByZXBy ZXNlbnRlZCBieSAiYXBwbGljYXRpb24vY29hcC1wYXlsb2FkO2NmPTYwIiwgaWYgdGhlIEhDIFBy b3h5IGRvZXNuJ3QgcmVjb2duaXplIHRoZSBjb250ZW50IGZvcm1hdCAnNjAnLjwvdD4KCiAgICAg ICAgPHQ+QSBIVFRQIGNsaWVudCBtYXkgdXNlIHRoZSBtZWRpYSB0eXBlICJhcHBsaWNhdGlvbi9j b2FwLXBheWxvYWQiIGFzIGEgbWVhbnMgdG8gc2VuZCBhIHNwZWNpZmljIGNvbnRlbnQgZm9ybWF0 IHRvIGEgQ29BUCBzZXJ2ZXIgdmlhIGEgSEMgUHJveHkgaWYgdGhlIGNsaWVudCBoYXMgZGV0ZXJt aW5lZCB0aGF0IHRoZSBIQyBQcm94eSBkb2VzIG5vdCBkaXJlY3RseSBzdXBwb3J0IHRoZSB0eXBl IG1hcHBpbmcgaXQgbmVlZHMuIFRoaXMgY2FzZSBtYXkgaGFwcGVuIHdoZW4gZGVhbGluZyBmb3Ig ZXhhbXBsZSB3aXRoIG5ld2x5IHJlZ2lzdGVyZWQsIHlldCB0byBiZSByZWdpc3RlcmVkLCBvciBl eHBlcmltZW50YWwgQ29BUCBjb250ZW50IGZvcm1hdHMuPC90PgogICAgICA8L3NlY3Rpb24+ICA8 IS0tIENvbnRlbnQgRm9ybWF0IHRvIE1lZGlhIFR5cGUgTWFwcGluZyAtLT4KCiAgICAgIDxzZWN0 aW9uIHRpdGxlPSJMb29zZSBNZWRpYSBUeXBlIE1hcHBpbmciIGFuY2hvcj0ic2VjLWxvb3NlLW10 LW1hcHBpbmciPgogICAgICAgIDx0PkJ5IHN0cnVjdHVyaW5nIHRoZSB0eXBlIGluZm9ybWF0aW9u IGluIGEgc3VwZXItY2xhc3MgKGUuZy4gInRleHQiKSBmb2xsb3dlZCBieSBhIGZpbmVyIGdyYWlu ZWQgc3ViLWNsYXNzIChlLmcuICJodG1sIiksIGFuZCBvcHRpb25hbCBwYXJhbWV0ZXJzIChlLmcu ICJjaGFyc2V0PXV0Zi04IiksIEludGVybmV0IG1lZGlhIHR5cGVzIHByb3ZpZGUgYSByaWNoIGFu ZCBzY2FsYWJsZSBmcmFtZXdvcmsgZm9yIGVuY29kaW5nIHRoZSB0eXBlIG9mIGFueSBnaXZlbiBl bnRpdHkuPC90PgoKICAgICAgICA8dD5UaGlzIGFwcHJvYWNoIGlzIG5vdCBhcHBsaWNhYmxlIHRv IENvQVAsIHdoZXJlIENvbnRlbnQgRm9ybWF0cyBjb25mbGF0ZSBhbiBJbnRlcm5ldCBtZWRpYSB0 eXBlIChwb3RlbnRpYWxseSB3aXRoIHNwZWNpZmljIHBhcmFtZXRlcnMpIGFuZCBhIGNvbnRlbnQg ZW5jb2RpbmcgaW50byBvbmUgc21hbGwgaW50ZWdlciB2YWx1ZS48L3Q+CgogICAgICAgIDx0PlRv IHJlbWVkeSB0aGlzIGxvc3Mgb2YgZmxleGliaWxpdHksIHdlIGludHJvZHVjZSB0aGUgY29uY2Vw dCBvZiBhICJsb29zZSIgbWVkaWEgdHlwZSBtYXBwaW5nLCB3aGVyZSBtZWRpYSB0eXBlcyB0aGF0 IGFyZSBzcGVjaWFsaXphdGlvbnMgb2YgYSBtb3JlIGdlbmVyaWMgbWVkaWEgdHlwZSBjYW4gYmUg YWxpYXNlZCB0byB0aGVpciBzdXBlci1jbGFzcyBhbmQgdGhlbiBtYXBwZWQgKGlmIHBvc3NpYmxl KSB0byBvbmUgb2YgdGhlIENvQVAgY29udGVudCBmb3JtYXRzLiAgRm9yIGV4YW1wbGUsICJhcHBs aWNhdGlvbi9zb2FwK3htbCIgY2FuIGJlIGFsaWFzZWQgdG8gImFwcGxpY2F0aW9uL3htbCIsIHdo aWNoIGhhcyBhIGtub3duIGNvbnZlcnNpb24gdG8gQ29BUC4gIEluIHRoZSBjb250ZXh0IG9mIHRo aXMgImxvb3NlIiBtZWRpYSB0eXBlIG1hcHBpbmcsICJhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0i IGNhbiBiZSB1c2VkIGFzIGEgZmFsbGJhY2sgd2hlbiBubyBiZXR0ZXIgYWxpYXMgaXMgZm91bmQg Zm9yIGEgc3BlY2lmaWMgbWVkaWEgdHlwZS48L3Q+CgogICAgICAgIDx0Pjx4cmVmIHRhcmdldD0i dGFiLWdlbmVyYWxpc2VkLW10Ii8+IGRlZmluZXMgdGhlIGRlZmF1bHQgbG9va3VwIHRhYmxlIGZv ciB0aGUgImxvb3NlIiBtZWRpYSB0eXBlIG1hcHBpbmcuICBHaXZlbiBhbiBpbnB1dCBtZWRpYSB0 eXBlLCB0aGUgdGFibGUgcmV0dXJucyBpdHMgYmVzdCBnZW5lcmFsaXplZCBtZWRpYSB0eXBlIHVz aW5nIHRoZSBtb3N0IHNwZWNpZmljIG1hdGNoIGkuZS4gdGhlIHRhYmxlIGVudHJpZXMgYXJlIGNv bXBhcmVkIHRvIHRoZSBpbnB1dCBpbiB0b3AgdG8gYm90dG9tIG9yZGVyIHVudGlsIGFuIGVudHJ5 IG1hdGNoZXMuPC90PgoKICAgICAgICA8dGV4dHRhYmxlIGFuY2hvcj0idGFiLWdlbmVyYWxpc2Vk LW10IiB0aXRsZT0iTWVkaWEgdHlwZSBnZW5lcmFsaXphdGlvbiBsb29rdXAgdGFibGUiPgogICAg ICAgICAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5JbnRlcm5ldCBtZWRpYSB0eXBlPC90dGNvbD4KICAg ICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+R2VuZXJhbGl6ZWQgbWVkaWEgdHlwZTwvdHRjb2w+ CiAgICAgICAgICA8Yz5hcHBsaWNhdGlvbi8qK3htbDwvYz4KICAgICAgICAgIDxjPmFwcGxpY2F0 aW9uL3htbDwvYz4KICAgICAgICAgIDxjPmFwcGxpY2F0aW9uLyoranNvbjwvYz4KICAgICAgICAg IDxjPmFwcGxpY2F0aW9uL2pzb248L2M+CiAgICAgICAgICA8Yz50ZXh0L3htbDwvYz4KICAgICAg ICAgIDxjPmFwcGxpY2F0aW9uL3htbDwvYz4KICAgICAgICAgIDxjPnRleHQvKjwvYz4KICAgICAg ICAgIDxjPnRleHQvcGxhaW48L2M+CiAgICAgICAgICA8Yz4qLyo8L2M+CiAgICAgICAgICA8Yz5h cHBsaWNhdGlvbi9vY3RldC1zdHJlYW08L2M+CiAgICAgICAgPC90ZXh0dGFibGU+CiAgICAgICAg PHQ+VGhlICJsb29zZSIgbWVkaWEgdHlwZSBtYXBwaW5nIGlzIGFuIE9QVElPTkFMIGZlYXR1cmUu ICBJbXBsZW1lbnRhdGlvbnMgc3VwcG9ydGluZyB0aGlzIGtpbmQgb2YgbWFwcGluZyBzaG91bGQg cHJvdmlkZSBhIGZsZXhpYmxlIHdheSB0byBkZWZpbmUgdGhlIHNldCBvZiBtZWRpYSB0eXBlIGdl bmVyYWxpemF0aW9ucyBhbGxvd2VkLjwvdD4KICAgICAgPC9zZWN0aW9uPiAgPCEtLSBMb29zZSBN ZWRpYSBUeXBlIE1hcHBpbmcgLS0+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iTWVkaWEgVHlwZSB0 byBDb250ZW50IEZvcm1hdCBNYXBwaW5nIEFsZ29yaXRobSIgYW5jaG9yPSJzZWMtbXQyY2YiPgog ICAgICAgIDx0PlRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBhbGdvcml0aG0gdXNlZCB0byBtYXAg YW4gSFRUUCBJbnRlcm5ldCBtZWRpYSB0eXBlIHRvIGl0cyBjb3JyZXNwb25kZW50IENvQVAgY29u dGVudCBmb3JtYXQuPC90PgoKICAgICAgICA8dD5UaGUgYWxnb3JpdGhtIHVzZXMgdGhlIG1hcHBp bmcgdGFibGUgZGVmaW5lZCBpbiBTZWN0aW9uIDEyLjMgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjUy Ii8+IHBsdXMsIHBvc3NpYmx5LCBhbnkgbG9jYWxseSBkZWZpbmVkIGV4dGVuc2lvbiBvZiBpdC4g IE9wdGlvbmFsbHksIHRoZSB0YWJsZSBhbmQgbG9va3VwIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4g PHhyZWYgdGFyZ2V0PSJzZWMtbG9vc2UtbXQtbWFwcGluZyIvPiBjYW4gYmUgdXNlZCBpZiB0aGUg aW1wbGVtZW50YXRpb24gY2hvb3NlcyBzby48L3Q+CgogICAgICAgIDx0Pk5vdGUgdGhhdCB0aGUg YWxnb3JpdGhtIG1heSBoYXZlIHNpZGUgZWZmZWN0cyBvbiB0aGUgYXNzb2NpYXRlZCByZXByZXNl bnRhdGlvbiAoc2VlIGFsc28gPHhyZWYgdGFyZ2V0PSJzZWMtY29udGVudC10cmFucyIvPikuPC90 PgoKICAgICAgICA8dD5JbiB0aGUgZm9sbG93aW5nOgogICAgICAgICAgPGxpc3Qgc3R5bGU9InN5 bWJvbHMiPgogICAgICAgICAgICA8dD5DLVQsIEMtRSwgYW5kIEMtRiBzdGFuZCBmb3IgdGhlIHZh bHVlcyBvZiB0aGUgQ29udGVudC1UeXBlIChvciBBY2NlcHQpIEhUVFAgaGVhZGVyLCBDb250ZW50 LUVuY29kaW5nIChvciBBY2NlcHQtRW5jb2RpbmcpIEhUVFAgaGVhZGVyLCBhbmQgQ29udGVudC1G b3JtYXQgQ29BUCBvcHRpb24gcmVzcGVjdGl2ZWx5LjwvdD4KICAgICAgICAgICAgPHQ+SWYgQy1F IGlzIG5vdCBnaXZlbiBpdCBpcyBhc3N1bWVkIHRvIGJlICJpZGVudGl0eSIuPC90PgogICAgICAg ICAgICA8dD5NQVAgaXMgdGhlIG1hbmRhdG9yeSBsb29rdXAgdGFibGUsIEdNQVAgaXMgdGhlIG9w dGlvbmFsIGdlbmVyYWxpemVkIHRhYmxlLjwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8 L3Q+CiAgICAgICAgPGZpZ3VyZSBhbmNob3I9ImZpZy1tdDJjZiI+CiAgICAgICAgICA8YXJ0d29y az4KICAgICAgICBJTlBVVDogIEMtVCBhbmQgQy1FCiAgICAgICAgT1VUUFVUOiBDLUYgb3IgRmFp bAoKICAgICAgICAxLiAgaWYgbm8gQy1UOiByZXR1cm4gRmFpbAogICAgICAgIDIuICBDLUYgPSBN QVBbQy1ULCBDLUVdCiAgICAgICAgMy4gIGlmIEMtRiBpcyBub3QgTm9uZTogcmV0dXJuIEMtRgog ICAgICAgIDQuICBpZiBDLUUgaXMgbm90ICJpZGVudGl0eSI6CiAgICAgICAgNS4gICAgaWYgQy1F IGlzIHN1cHBvcnRlZCAoZS5nLiBnemlwKToKICAgICAgICA2LiAgICAgIGRlY29kZSB0aGUgcmVw cmVzZW50YXRpb24gYWNjb3JkaW5nbHkKICAgICAgICA3LiAgICAgIHNldCBDLUUgdG8gImlkZW50 aXR5IgogICAgICAgIDguICAgIGVsc2U6CiAgICAgICAgOS4gICAgICByZXR1cm4gRmFpbAogICAg ICAgIDEwLiByZXBlYXQgc3RlcHMgMi4gYW5kIDMuCiAgICAgICAgMTEuIGlmIEMtVCBhbGxvd3Mg YSBub24tbG9zc3kgdHJhbnNmb3JtYXRpb24gaW50byBcCiAgICAgICAgMTIuICAgIG9uZSBvZiB0 aGUgc3VwcG9ydGVkIEMtRjoKICAgICAgICAxMy4gICAgICB0cmFuc2NvZGUgdGhlIHJlcHJlc2Vu dGF0aW9uIGFjY29yZGluZ2x5CiAgICAgICAgMTQuICAgICAgcmV0dXJuIEMtRgogICAgICAgIDE1 LiBpZiBHTUFQIGlzIGRlZmluZWQ6CiAgICAgICAgMTYuICAgQy1GID0gR01BUFtDLVRdCiAgICAg ICAgMTcuICAgaWYgQy1GIGlzIG5vdCBOb25lOiByZXR1cm4gQy1GCiAgICAgICAgMTguIHJldHVy biBGYWlsCiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPCEt LSBUT0RPIG1heWJlIGRlc2NyaWJlIHRoZSBhbGdvcml0aG0/IC0tPgogICAgICAgIDwhLS0gVE9E TyBwcm92aWRlIGV4YW1wbGVzIC0tPgogICAgICA8L3NlY3Rpb24+ICA8IS0tIE1lZGlhIFR5cGUg dG8gQ29udGVudCBGb3JtYXQgTWFwcGluZyBBbGdvcml0aG0gLS0+CgogICAgICA8c2VjdGlvbiB0 aXRsZT0iQ29udGVudCBUcmFuc2NvZGluZyIgYW5jaG9yPSJzZWMtY29udGVudC10cmFucyI+CiAg ICAgICAgPHNlY3Rpb24gdGl0bGU9IkdlbmVyYWwiPgogICAgICAgICAgPHQ+UGF5bG9hZCBjb250 ZW50IHRyYW5zY29kaW5nIChlLmcuIHNlZSBzdGVwcyAxMS0xNCBvZiA8eHJlZiB0YXJnZXQ9ImZp Zy1tdDJjZiIvPikgaXMgYW4gT1BUSU9OQUwgZmVhdHVyZS4gIEltcGxlbWVudGF0aW9ucyBzdXBw b3J0aW5nIHRoaXMgZmVhdHVyZSBzaG91bGQgcHJvdmlkZSBhIGZsZXhpYmxlIHdheSB0byBkZWZp bmUgdGhlIHNldCBvZiB0cmFuc2NvZGluZ3MgYWxsb3dlZC48L3Q+CgogICAgICAgICAgPHQ+QXMg bm90ZWQgaW4gPHhyZWYgdGFyZ2V0PSJzZWMtbXQyY2YiLz4sIHRoZSBwcm9jZXNzIG9mIG1hcHBp bmcgdGhlIG1lZGlhIHR5cGUgY2FuIGhhdmUgc2lkZSBlZmZlY3RzIG9uIHRoZSBmb3J3YXJkZWQg ZW50aXR5IGJvZHkuICBUaGlzIG1heSBiZSBjYXVzZWQgYnkgdGhlIHJlbW92YWwgb3IgYWRkaXRp b24gb2YgYSBzcGVjaWZpYyBjb250ZW50IGVuY29kaW5nLCBvciBiZWNhdXNlIHRoZSBIQyBwcm94 eSBkZWNpZGVzIHRvIHRyYW5zY29kZSB0aGUgcmVwcmVzZW50YXRpb24gdG8gYSBkaWZmZXJlbnQg KGNvbXBhdGlibGUpIGZvcm1hdC4gIFRoZSBsYXR0ZXIgcHJvdmVzIHVzZWZ1bCB3aGVuIGFuIG9w dGltaXplZCB2ZXJzaW9uIG9mIGEgc3BlY2lmaWMgZm9ybWF0IGV4aXN0cy4gIEZvciBleGFtcGxl IGFuIFhNTC1lbmNvZGVkIHJlc291cmNlIGNvdWxkIGJlIHRyYW5zY29kZWQgdG8gRWZmaWNpZW50 IFhNTCBJbnRlcmNoYW5nZSAoRVhJKSBmb3JtYXQsIG9yIGEgSlNPTi1lbmNvZGVkIHJlc291cmNl IGludG8gQ0JPUiA8eHJlZiB0YXJnZXQ9IlJGQzcwNDkiLz4sIGVmZmVjdGl2ZWx5IGFjaGlldmlu ZyBjb21wcmVzc2lvbiB3aXRob3V0IGxvc2luZyBhbnkgaW5mb3JtYXRpb24uPC90PgoKICAgICAg ICAgIDx0Pkhvd2V2ZXIsIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGluIGNlcnRhaW4gY2FzZXMs IHRyYW5zY29kaW5nIGNhbiBsb3NlIGluZm9ybWF0aW9uIGluIGEgbm9uLW9idmlvdXMgbWFubmVy LiAgRm9yIGV4YW1wbGUsIGVuY29kaW5nIGFuIFhNTCBkb2N1bWVudCB1c2luZyBzY2hlbWEtaW5m b3JtZWQgRVhJIGVuY29kaW5nIGxlYWRzIHRvIGEgbG9zcyBvZiBpbmZvcm1hdGlvbiB3aGVuIHRo ZSBkZXN0aW5hdGlvbiBkb2VzIG5vdCBrbm93IHRoZSBleGFjdCBzY2hlbWEgdmVyc2lvbiB1c2Vk IGJ5IHRoZSBlbmNvZGVyLCB3aGljaCBtZWFucyB0aGF0IHdoZW5ldmVyIHRoZSBIQyBwcm94eSB0 cmFuc2NvZGVzIGFuIGFwcGxpY2F0aW9uL1hNTCB0byBhcHBsaWNhdGlvbi9FWEkgaW4tYmFuZCBt ZXRhZGF0YSBjb3VsZCBiZSBsb3N0LiAgVGhlcmVmb3JlLCB0aGUgaW1wbGVtZW50ZXIgc2hvdWxk IGFsd2F5cyBjYXJlZnVsbHkgdmVyaWZ5IHN1Y2ggbG9zc3kgcGF5bG9hZCB0cmFuc2Zvcm1hdGlv bnMgYmVmb3JlIHRyaWdnZXJpbmcgdGhlIHRyYW5zY29kaW5nLjwvdD4KICAgICAgICA8L3NlY3Rp b24+ICA8IS0tIEdlbmVyYWwgLS0+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJDb1JFIExpbmsg Rm9ybWF0Ij4KICAgICAgICAgIDx0PlRoZSBDb1JFIExpbmsgRm9ybWF0IDx4cmVmIHRhcmdldD0i UkZDNjY5MCIvPiBpcyBhIHNldCBvZiBsaW5rcyAoaS5lLiwgVVJJcyBhbmQgdGhlaXIgZm9ybWFs IHJlbGF0aW9uc2hpcHMpIHdoaWNoIGlzIGNhcnJpZWQgYXMgY29udGVudCBwYXlsb2FkIGluIGEg Q29BUCByZXNwb25zZS4gIFRoZXNlIGxpbmtzIHVzdWFsbHkgaW5jbHVkZSBDb0FQIFVSSXMgdGhh dCBtaWdodCBiZSB0cmFuc2xhdGVkIGJ5IHRoZSBIQyBwcm94eSB0byB0aGUgY29ycmVzcG9uZGVu dCBIVFRQIFVSSXMgdXNpbmcgdGhlIGltcGxlbWVudGVkIFVSSSBtYXBwaW5nIGZ1bmN0aW9uIChz ZWUgPHhyZWYgdGFyZ2V0PSJVUkktbWFwcGluZyIvPikuICBTdWNoIGEgcHJvY2VzcyB3b3VsZCBp bnNwZWN0IHRoZSBmb3J3YXJkZWQgdHJhZmZpYyBhbmQgYXR0ZW1wdCB0byByZS13cml0ZSB0aGUg Ym9keSBvZiByZXNvdXJjZXMgd2l0aCBhbiBhcHBsaWNhdGlvbi9saW5rLWZvcm1hdCBtZWRpYSB0 eXBlLCBtYXBwaW5nIHRoZSBlbWJlZGRlZCBDb0FQIFVSSXMgdG8gdGhlaXIgSFRUUCBjb3VudGVy cGFydHMuICBTb21lIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCB0aGlzIGFwcHJvYWNoIGFyZToKICAg ICAgICAgICAgPGxpc3Qgc3R5bGU9Im51bWJlcnMiPgogICAgICAgICAgICAgIDx0PlRoZSBjbGll bnQgbWF5IGJlIGludGVyZXN0ZWQgdG8gcmV0cmlldmUgb3JpZ2luYWwgKHVuYWx0ZXJlZCkgQ29B UCBwYXlsb2FkcyB0aHJvdWdoIHRoZSBIQyBwcm94eSwgbm90IG1vZGlmaWVkIHZlcnNpb25zLjwv dD4KICAgICAgICAgICAgICA8dD5UYW1wZXJpbmcgd2l0aCBwYXlsb2FkcyBpcyBpbmNvbXBhdGli bGUgd2l0aCByZXNvdXJjZXMgdGhhdCBhcmUgaW50ZWdyaXR5IHByb3RlY3RlZCAoYWx0aG91Z2gg dGhpcyBpcyBhIHByb2JsZW0gd2l0aCB0cmFuc2NvZGluZyBpbiBnZW5lcmFsKS48L3Q+CiAgICAg ICAgICAgICAgPHQ+VGhlIEhDIHByb3h5IG5lZWRzIHRvIGZ1bGx5IHVuZGVyc3RhbmQgPHhyZWYg dGFyZ2V0PSJSRkM2NjkwIi8+IHN5bnRheCBhbmQgc2VtYW50aWNzLCBvdGhlcndpc2UgdGhlcmUg aXMgYW4gaW5oZXJlbnQgcmlzayB0byBjb3JydXB0IHRoZSBwYXlsb2Fkcy48L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgICAgVGhlcmVmb3JlLCBDb1JFIExpbmsgRm9ybWF0IHBheWxv YWQgc2hvdWxkIG9ubHkgYmUgdHJhbnNjb2RlZCBhdCB0aGUgcmlzayBhbmQgZGlzY3JldGlvbiBv ZiB0aGUgcHJveHkgaW1wbGVtZW50ZXIuPC90PgogICAgICAgIDwvc2VjdGlvbj4gIDwhLS0gQ29S RSBMaW5rIEZvcm1hdCAtLT4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IkRpYWdub3N0aWMgTWVz c2FnZXMiIGFuY2hvcj0ic2VjLWRpYWdub3N0aWMiPgogICAgICAgICAgPHQ+Q29BUCByZXNwb25z ZXMgbWF5LCBpbiBjZXJ0YWluIGVycm9yIGNhc2VzLCBjb250YWluIGEgZGlhZ25vc3RpYyBtZXNz YWdlIGluIHRoZSBwYXlsb2FkIGV4cGxhaW5pbmcgdGhlIGVycm9yIHNpdHVhdGlvbiwgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNS41LjIgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjUyIi8+LiAgSWYg cHJlc2VudCwgdGhlIENvQVAgcmVzcG9uc2UgZGlhZ25vc3RpYyBwYXlsb2FkIFNIT1VMRCBiZSBj b3BpZWQgaW4gdGhlIEhUVFAgcmVzcG9uc2UgYm9keS4gIFRoZSBDb0FQIGRpYWdub3N0aWMgbWVz c2FnZSBNVVNUIE5PVCBiZSBjb3BpZWQgaW50byB0aGUgSFRUUCByZWFzb24tcGhyYXNlLCBzaW5j ZSBpdCBwb3RlbnRpYWxseSBjb250YWlucyBDUi1MRiBjaGFyYWN0ZXJzIHdoaWNoIGFyZSBpbmNv bXBhdGlibGUgd2l0aCBIVFRQIHJlYXNvbi1waHJhc2Ugc3ludGF4LjwvdD4KICAgICAgICA8L3Nl Y3Rpb24+ICA8IS0tIERpYWdub3N0aWMgTWVzc2FnZXMiIC0tPgogICAgICA8L3NlY3Rpb24+IDwh LS0gQ29udGVudCBUcmFuc2NvZGluZyAtLT4KICAgIDwvc2VjdGlvbj4gPCEtLSBNZWRpYSBUeXBl IE1hcHBpbmcgLS0+CgogICAgPCEtLSAqKioqKioqKioqKioqKioqKioqIE1BSU4gU0VDVElPTiAq KioqKioqKioqKioqKioqKioqKiAtLT4KICAgIDxzZWN0aW9uIHRpdGxlPSJSZXNwb25zZSBDb2Rl IE1hcHBpbmciIGFuY2hvcj0iaGMtcmVzcCI+CiAgICAgIDx0Pjx4cmVmIHRhcmdldD0idGFiLWh0 dHAtY29hcCIvPiBkZWZpbmVzIHRoZSBIVFRQIHJlc3BvbnNlIHN0YXR1cyBjb2RlcyB0byB3aGlj aCBlYWNoIENvQVAgcmVzcG9uc2UgY29kZSBTSE9VTEQgYmUgbWFwcGVkLiAgTXVsdGlwbGUgYXBw ZWFyYW5jZXMgb2YgYSBIVFRQIHN0YXR1cyBjb2RlIGluIHRoZSBzZWNvbmQgY29sdW1uIGluZGlj YXRlcyBtdWx0aXBsZSBlcXVpdmFsZW50IEhUVFAgcmVzcG9uc2VzIGFyZSBwb3NzaWJsZSBiYXNl ZCBvbiB0aGUgc2FtZSBDb0FQIHJlc3BvbnNlIGNvZGUsIGRlcGVuZGluZyBvbiB0aGUgY29uZGl0 aW9ucyBjaXRlZCBpbiB0aGUgTm90ZXMgKHRoaXJkIGNvbHVtbiBhbmQgdGV4dCBiZWxvdyB0YWJs ZSkuPC90PgoKICAgICAgPHRleHR0YWJsZSBhbmNob3I9InRhYi1odHRwLWNvYXAiIHRpdGxlPSJD b0FQLUhUVFAgUmVzcG9uc2UgQ29kZSBNYXBwaW5ncyI+CiAgICAgICAgPHR0Y29sIGFsaWduPSJs ZWZ0Ij5Db0FQIFJlc3BvbnNlIENvZGU8L3R0Y29sPgogICAgICAgIDx0dGNvbCBhbGlnbj0ibGVm dCI+SFRUUCBTdGF0dXMgQ29kZTwvdHRjb2w+CiAgICAgICAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5O b3RlczwvdHRjb2w+CiAgICAgICAgPGM+Mi4wMSBDcmVhdGVkICAgICAgICAgICAgICAgIDwvYz4K ICAgICAgICA8Yz4yMDEgQ3JlYXRlZCAgICAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPjE8 L2M+CiAgICAgICAgPGM+Mi4wMiBEZWxldGVkICAgICAgICAgICAgICAgIDwvYz4KICAgICAgICA8 Yz4yMDAgT0sgICAgICAgICAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPjI8L2M+CiAgICAg ICAgPGM+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz4yMDQgTm8g Q29udGVudCAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPjI8L2M+CiAgICAgICAgPGM+Mi4w MyBWYWxpZCAgICAgICAgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz4zMDQgTm90IE1vZGlmaWVk ICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPjM8L2M+CiAgICAgICAgPGM+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz4yMDAgT0sgICAgICAgICAgICAgICAgICAg ICAgPC9jPgogICAgICAgIDxjPjQ8L2M+CiAgICAgICAgPGM+Mi4wNCBDaGFuZ2VkICAgICAgICAg ICAgICAgIDwvYz4KICAgICAgICA8Yz4yMDAgT0sgICAgICAgICAgICAgICAgICAgICAgPC9jPgog ICAgICAgIDxjPjI8L2M+CiAgICAgICAgPGM+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv Yz4KICAgICAgICA8Yz4yMDQgTm8gQ29udGVudCAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxj PjI8L2M+CiAgICAgICAgPGM+Mi4wNSBDb250ZW50ICAgICAgICAgICAgICAgIDwvYz4KICAgICAg ICA8Yz4yMDAgT0sgICAgICAgICAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAg ICAgICAgPGM+NC4wMCBCYWQgUmVxdWVzdCAgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz40MDAg QmFkIFJlcXVlc3QgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAgICAgPGM+ NC4wMSBVbmF1dGhvcml6ZWQgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz40MDMgRm9yYmlkZGVu ICAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPjU8L2M+CiAgICAgICAgPGM+NC4wMiBCYWQg T3B0aW9uICAgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz40MDAgQmFkIFJlcXVlc3QgICAgICAg ICAgICAgPC9jPgogICAgICAgIDxjPjY8L2M+CiAgICAgICAgPGM+NC4wMiBCYWQgT3B0aW9uICAg ICAgICAgICAgIDwvYz4KICAgICAgICA8Yz41MDAgSW50ZXJuYWwgU2VydmVyIEVycm9yICAgPC9j PgogICAgICAgIDxjPjY8L2M+CiAgICAgICAgPGM+NC4wMyBGb3JiaWRkZW4gICAgICAgICAgICAg IDwvYz4KICAgICAgICA8Yz40MDMgRm9yYmlkZGVuICAgICAgICAgICAgICAgPC9jPgogICAgICAg IDxjPiA8L2M+CiAgICAgICAgPGM+NC4wNCBOb3QgRm91bmQgICAgICAgICAgICAgIDwvYz4KICAg ICAgICA8Yz40MDQgTm90IEZvdW5kICAgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+ CiAgICAgICAgPGM+NC4wNSBNZXRob2QgTm90IEFsbG93ZWQgICAgIDwvYz4KICAgICAgICA8Yz40 MDAgQmFkIFJlcXVlc3QgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPjc8L2M+CiAgICAgICAg PGM+NC4wNiBOb3QgQWNjZXB0YWJsZSAgICAgICAgIDwvYz4KICAgICAgICA8Yz40MDYgTm90IEFj Y2VwdGFibGUgICAgICAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAgICAgPGM+NC4xMiBQ cmVjb25kaXRpb24gRmFpbGVkICAgIDwvYz4KICAgICAgICA8Yz40MTIgUHJlY29uZGl0aW9uIEZh aWxlZCAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAgICAgPGM+NC4xMyBSZXF1ZXN0IEVu dC4gVG9vIExhcmdlIDwvYz4KICAgICAgICA8Yz40MTMgUmVxdWVzdCBSZXByLiBUb28gTGFyZ2Ug PC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAgICAgPGM+NC4xNSBVbnN1cHBvcnRlZCBNZWRpYSBU eXBlIDwvYz4KICAgICAgICA8Yz40MTUgVW5zdXBwb3J0ZWQgTWVkaWEgVHlwZSAgPC9jPgogICAg ICAgIDxjPiA8L2M+CiAgICAgICAgPGM+NS4wMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3IgIDwvYz4K ICAgICAgICA8Yz41MDAgSW50ZXJuYWwgU2VydmVyIEVycm9yICAgPC9jPgogICAgICAgIDxjPiA8 L2M+CiAgICAgICAgPGM+NS4wMSBOb3QgSW1wbGVtZW50ZWQgICAgICAgIDwvYz4KICAgICAgICA8 Yz41MDEgTm90IEltcGxlbWVudGVkICAgICAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAg ICAgPGM+NS4wMiBCYWQgR2F0ZXdheSAgICAgICAgICAgIDwvYz4KICAgICAgICA8Yz41MDIgQmFk IEdhdGV3YXkgICAgICAgICAgICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAgICAgPGM+NS4w MyBTZXJ2aWNlIFVuYXZhaWxhYmxlICAgIDwvYz4KICAgICAgICA8Yz41MDMgU2VydmljZSBVbmF2 YWlsYWJsZSAgICAgPC9jPgogICAgICAgIDxjPjg8L2M+CiAgICAgICAgPGM+NS4wNCBHYXRld2F5 IFRpbWVvdXQgICAgICAgIDwvYz4KICAgICAgICA8Yz41MDQgR2F0ZXdheSBUaW1lb3V0ICAgICAg ICAgPC9jPgogICAgICAgIDxjPiA8L2M+CiAgICAgICAgPGM+NS4wNSBQcm94eWluZyBOb3QgU3Vw cG9ydGVkIDwvYz4KICAgICAgICA8Yz41MDIgQmFkIEdhdGV3YXkgICAgICAgICAgICAgPC9jPgog ICAgICAgIDxjPjk8L2M+CiAgICAgIDwvdGV4dHRhYmxlPgogICAgICA8dD5Ob3RlczoKICAgICAg ICA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAgICAgICA8dD5BIENvQVAgc2VydmVyIG1heSBy ZXR1cm4gYW4gYXJiaXRyYXJ5IGZvcm1hdCBwYXlsb2FkIGFsb25nIHdpdGggdGhpcyByZXNwb25z ZS4gSWYgcHJlc2VudCwgdGhpcyBwYXlsb2FkIE1VU1QgYmUgcmV0dXJuZWQgYXMgZW50aXR5IGlu IHRoZSBIVFRQIDIwMSByZXNwb25zZS4gU2VjdGlvbiA3LjMuMiBvZiA8eHJlZiB0YXJnZXQ9IlJG QzcyMzEiLz4gZG9lcyBub3QgcHV0IGFueSByZXF1aXJlbWVudCBvbiB0aGUgZm9ybWF0IG9mIHRo ZSBlbnRpdHkuIChJbiB0aGUgcGFzdCwgPHhyZWYgdGFyZ2V0PSJSRkMyNjE2Ii8+IGRpZC4pPC90 PgoKICAgICAgICAgIDx0PlRoZSBIVFRQIGNvZGUgaXMgMjAwIG9yIDIwNCByZXNwZWN0aXZlbHkg Zm9yIHRoZSBjYXNlIHRoYXQgYSBDb0FQIHNlcnZlciByZXR1cm5zIGEgcGF5bG9hZCBvciBub3Qu IDx4cmVmIHRhcmdldD0iUkZDNzIzMSIvPiBTZWN0aW9uIDUuMyByZXF1aXJlcyBjb2RlIDIwMCBp biBjYXNlIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIGFjdGlvbiByZXN1bHQgaXMgcmV0dXJuZWQg Zm9yIERFTEVURS9QT1NUL1BVVCwgYW5kIGNvZGUgMjA0IGlmIG5vdC4gSGVuY2UsIGEgcHJveHkg TVVTVCB0cmFuc2ZlciBhbnkgQ29BUCBwYXlsb2FkIGNvbnRhaW5lZCBpbiBhIENvQVAgMi4wMiBy ZXNwb25zZSB0byB0aGUgSFRUUCBjbGllbnQgdXNpbmcgYSAyMDAgT0sgcmVzcG9uc2UuPC90Pgog CiAgICAgICAgICA8dD5IVFRQIGNvZGUgMzA0IChOb3QgTW9kaWZpZWQpIGlzIHNlbnQgaWYgdGhl IEhUVFAgY2xpZW50IHBlcmZvcm1lZCBhIGNvbmRpdGlvbmFsIEhUVFAgcmVxdWVzdCBhbmQgdGhl IENvQVAgc2VydmVyIHJlc3BvbmRlZCB3aXRoIDIuMDMgKFZhbGlkKSB0byB0aGUgY29ycmVzcG9u ZGluZyBDb0FQIHZhbGlkYXRpb24gcmVxdWVzdC4gTm90ZSB0aGF0IFNlY3Rpb24gNC4xIG9mIDx4 cmVmIHRhcmdldD0iUkZDNzIzMiIvPiBwdXRzIHNvbWUgcmVxdWlyZW1lbnRzIG9uIGhlYWRlciBm aWVsZHMgdGhhdCBtdXN0IGJlIHByZXNlbnQgaW4gdGhlIEhUVFAgMzA0IHJlc3BvbnNlLjwvdD4K IAogICAgICAgICAgPHQ+QSAyMDAgcmVzcG9uc2UgdG8gYSBDb0FQIDIuMDMgb2NjdXJzIG9ubHkg d2hlbiB0aGUgSEMgcHJveHksIGZvciBlZmZpY2llbmN5IHJlYXNvbnMsIGlzIHJ1bm5pbmcgYSBs b2NhbCBjYWNoZS4gIEFuIHVuY29uZGl0aW9uYWwgSFRUUCBHRVQgd2hpY2ggcHJvZHVjZXMgYSBj YWNoZS1oaXQsIGNvdWxkIHRyaWdnZXIgYSByZS12YWxpZGF0aW9uIChpLmUuIGEgY29uZGl0aW9u YWwgR0VUKSBvbiB0aGUgQ29BUCBzaWRlLiAgVGhlIHByb3h5IHJlY2VpdmluZyAyLjAzIHVwZGF0 ZXMgdGhlIGZyZXNobmVzcyBvZiBpdHMgY2FjaGVkIHJlcHJlc2VudGF0aW9uIGFuZCByZXR1cm5z IGl0IHRvIHRoZSBIVFRQIGNsaWVudC48L3Q+CiAKICAgICAgICAgIDx0PkEgSFRUUCA0MDEgVW5h dXRob3JpemVkIChTZWN0aW9uIDMuMSBvZiA8eHJlZiB0YXJnZXQ9IlJGQzcyMzUiLz4pIHJlc3Bv bnNlIGlzIG5vdCBhcHBsaWNhYmxlIGJlY2F1c2UgdGhlcmUgaXMgbm8gZXF1aXZhbGVudCBpbiBD b0FQIG9mIFdXVy1BdXRoZW50aWNhdGUgd2hpY2ggaXMgbWFuZGF0b3J5IGluIGEgSFRUUCA0MDEg cmVzcG9uc2UuPC90PgogCiAgICAgICAgICA8dD5JZiB0aGUgcHJveHkgaGFzIGEgd2F5IHRvIGRl dGVybWluZSB0aGF0IHRoZSBCYWQgT3B0aW9uIGlzIGR1ZSB0byB0aGUgc3RyYWlnaHRmb3J3YXJk IG1hcHBpbmcgb2YgYSBjbGllbnQgcmVxdWVzdCBoZWFkZXIgaW50byBhIENvQVAgb3B0aW9uLCB0 aGVuIHJldHVybmluZyBIVFRQIDQwMCAoQmFkIFJlcXVlc3QpIGlzIGFwcHJvcHJpYXRlLiAgSW4g YWxsIG90aGVyIGNhc2VzLCB0aGUgcHJveHkgTVVTVCByZXR1cm4gSFRUUCA1MDAgKEludGVybmFs IFNlcnZlciBFcnJvcikgc3RhdGluZyBpdHMgaW5hYmlsaXR5IHRvIHByb3ZpZGUgYSBzdWl0YWJs ZSB0cmFuc2xhdGlvbiB0byB0aGUgY2xpZW50J3MgcmVxdWVzdC48L3Q+CgogICAgICAgICAgPHQ+ QSBDb0FQIDQuMDUgKE1ldGhvZCBOb3QgQWxsb3dlZCkgcmVzcG9uc2UgU0hPVUxEIG5vcm1hbGx5 IGJlIG1hcHBlZCB0byBhIEhUVFAgNDAwIChCYWQgUmVxdWVzdCkgY29kZSwgYmVjYXVzZSB0aGUg SFRUUCA0MDUgcmVzcG9uc2Ugd291bGQgcmVxdWlyZSBzcGVjaWZ5aW5nIHRoZSBzdXBwb3J0ZWQg bWV0aG9kcyAtIHdoaWNoIGFyZSBnZW5lcmFsbHkgdW5rbm93bi4gIEluIHRoaXMgY2FzZSB0aGUg SEMgUHJveHkgU0hPVUxEIGFsc28gcmV0dXJuIGEgSFRUUCByZWFzb24tcGhyYXNlIGluIHRoZSBI VFRQIHN0YXR1cyBsaW5lIHRoYXQgc3RhcnRzIHdpdGggdGhlIHN0cmluZyAiQ29BUCBzZXJ2ZXIg cmV0dXJuZWQgNC4wNSIgaW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0cm91Ymxlc2hvb3RpbmcuICBI b3dldmVyLCBpZiB0aGUgSEMgcHJveHkgaGFzIG1vcmUgZ3JhbnVsYXIgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHN1cHBvcnRlZCBtZXRob2RzIGZvciB0aGUgcmVxdWVzdGVkIHJlc291cmNlIChlLmcu IHZpYSBhIFJlc291cmNlIERpcmVjdG9yeSAoPHhyZWYgdGFyZ2V0PSJJLUQuaWV0Zi1jb3JlLXJl c291cmNlLWRpcmVjdG9yeSIvPikpIHRoZW4gaXQgTUFZIHNlbmQgYmFjayBhIEhUVFAgNDA1IChN ZXRob2QgTm90IEFsbG93ZWQpIHdpdGggYSBwcm9wZXJseSBmaWxsZWQgaW4gIkFsbG93IiByZXNw b25zZS1oZWFkZXIgZmllbGQgKFNlY3Rpb24gNy40LjEgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjMx Ii8+KS48L3Q+CgogICAgICAgICAgPHQ+VGhlIHZhbHVlIG9mIHRoZSBIVFRQICJSZXRyeS1BZnRl ciIgcmVzcG9uc2UtaGVhZGVyIGZpZWxkIGlzIHRha2VuIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBD b0FQIE1heC1BZ2UgT3B0aW9uLCBpZiBwcmVzZW50LjwvdD4KCiAgICAgICAgICA8dD5UaGlzIENv QVAgcmVzcG9uc2UgY2FuIG9ubHkgaGFwcGVuIGlmIHRoZSBwcm94eSBpdHNlbGYgaXMgY29uZmln dXJlZCB0byB1c2UgYSBDb0FQIGZvcndhcmQtcHJveHkgKFNlY3Rpb24gNS43IG9mIDx4cmVmIHRh cmdldD0iUkZDNzI1MiIvPikgdG8gZXhlY3V0ZSBzb21lLCBvciBhbGwsIG9mIGl0cyBDb0FQIHJl cXVlc3RzLjwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4KICAgIDwvc2VjdGlvbj4gPCEt LSBSZXNwb25zZSBNYXBwaW5nIC0tPgoKICAgIDwhLS0gKioqKioqKioqKioqKioqKioqKiBNQUlO IFNFQ1RJT04gKioqKioqKioqKioqKioqKioqKiogLS0+CiAgICA8c2VjdGlvbiB0aXRsZT0iQWRk aXRpb25hbCBNYXBwaW5nIEd1aWRlbGluZXMiIGFuY2hvcj0iaGMtYWRkaXRpb25hbCI+CiAgICAg IDxzZWN0aW9uIHRpdGxlPSJDYWNoaW5nIGFuZCBDb25nZXN0aW9uIENvbnRyb2wiIGFuY2hvcj0i aGMtY2FjaGluZyI+CiAgICAgICAgPCEtLSBkaXNjdXNzIGNhY2hlLWNvbnRyb2wgLS0+CiAgICAg ICAgPHQ+QSBIQyBwcm94eSBzaG91bGQgY2FjaGUgQ29BUCByZXNwb25zZXMsIGFuZCByZXBseSB3 aGVuZXZlciBhcHBsaWNhYmxlIHdpdGggYSBjYWNoZWQgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJl cXVlc3RlZCByZXNvdXJjZS48L3Q+CgogICAgICAgICAgPCEtLSBUaGUgc2FtZSBjb25zaWRlcmF0 aW9uIGFwcGxpZXMgaWYgbXVsdGlwbGUgYWN0aXZlIEhUVFAgc3Vic2NyaXB0aW9ucyBpbnZvbHZl IHRoZSBzYW1lIG9ic2VydmUgcmVsYXRpb25zaGlwIC0tPgogICAgICAgIDwhLS0KICAgICAgICA8 dD5EdXBsaWNhdGUgaWRlbXBvdGVudCBwZW5kaW5nIHJlcXVlc3RzIGJ5IGEgSEMgcHJveHkgdG8g dGhlIHNhbWUgQ29BUCByZXNvdXJjZSBTSE9VTEQgaW4gZ2VuZXJhbCBiZSBhdm9pZGVkLCBieSB1 c2luZyB0aGUgc2FtZSByZXNwb25zZSBmb3IgbXVsdGlwbGUgcmVxdWVzdGluZyBIVFRQIGNsaWVu dHMgd2l0aG91dCBkdXBsaWNhdGluZyB0aGUgQ29BUCByZXF1ZXN0LjwvdD4KICAgICAgICAtLT4K CiAgICAgICAgPHQ+SWYgdGhlIEhUVFAgY2xpZW50IGRyb3BzIHRoZSBjb25uZWN0aW9uIGFmdGVy IHRoZSBIVFRQIHJlcXVlc3Qgd2FzIG1hZGUsIGEgSEMgcHJveHkgc2hvdWxkIHdhaXQgZm9yIHRo ZSBhc3NvY2lhdGVkIENvQVAgcmVzcG9uc2UgYW5kIGNhY2hlIGl0IGlmIHBvc3NpYmxlLiAgU3Vi c2VxdWVudCByZXF1ZXN0cyB0byB0aGUgSEMgcHJveHkgZm9yIHRoZSBzYW1lIHJlc291cmNlIGNh biB1c2UgdGhlIHJlc3VsdCBwcmVzZW50IGluIGNhY2hlLCBvciwgaWYgYSByZXNwb25zZSBoYXMg c3RpbGwgdG8gY29tZSwgdGhlIEhUVFAgcmVxdWVzdHMgd2lsbCB3YWl0IG9uIHRoZSBvcGVuIENv QVAgcmVxdWVzdC48L3Q+CgogICAgICAgIDx0PkFjY29yZGluZyB0byA8eHJlZiB0YXJnZXQ9IlJG QzcyNTIiLz4sIGEgcHJveHkgbXVzdCBsaW1pdCB0aGUgbnVtYmVyIG9mIG91dHN0YW5kaW5nIHJl cXVlc3RzIHRvIGEgZ2l2ZW4gQ29BUCBzZXJ2ZXIgdG8gTlNUQVJULiBUbyBsaW1pdCB0aGUgYW1v dW50IG9mIGFnZ3JlZ2F0ZSB0cmFmZmljIHRvIGEgY29uc3RyYWluZWQgbmV0d29yaywgdGhlIEhD IHByb3h5IHNob3VsZCBhbHNvIHB1dCBhIGxpbWl0IG9uIHRoZSBudW1iZXIgb2YgY29uY3VycmVu dCBDb0FQIHJlcXVlc3RzIHBlbmRpbmcgb24gdGhlIHNhbWUgY29uc3RyYWluZWQgbmV0d29yazsg ZnVydGhlciBpbmNvbWluZyByZXF1ZXN0cyBtYXkgZWl0aGVyIGJlIHF1ZXVlZCBvciBkcm9wcGVk IChyZXR1cm5pbmcgNTAzIFNlcnZpY2UgVW5hdmFpbGFibGUpLiBUaGlzIGxpbWl0IGFuZCB0aGUg cHJveHkgcXVldWVpbmcvZHJvcHBpbmcgYmVoYXZpb3Igc2hvdWxkIGJlIGNvbmZpZ3VyYWJsZS48 L3Q+CgogICAgICAgIDx0PkhpZ2hseSB2b2xhdGlsZSByZXNvdXJjZXMgdGhhdCBhcmUgYmVpbmcg ZnJlcXVlbnRseSByZXF1ZXN0ZWQgbWF5IGJlIG9ic2VydmVkIDx4cmVmIHRhcmdldD0iUkZDNzY0 MSIvPiBieSB0aGUgSEMgcHJveHkgdG8ga2VlcCB0aGVpciBjYWNoZWQgcmVwcmVzZW50YXRpb24g ZnJlc2ggd2hpbGUgbWluaW1pemluZyB0aGUgYW1vdW50IG9mIENvQVAgdHJhZmZpYyBpbiB0aGUg Y29uc3RyYWluZWQgbmV0d29yay4gIFNlZSA8eHJlZiB0YXJnZXQ9InJlZnJlc2hfdmlhX29ic2Vy dmUiLz4uPC90PgogICAgICA8L3NlY3Rpb24+ICA8IS0tIENhY2hpbmcgYW5kIENvbmdlc3Rpb24g Q29udHJvbCAtLT4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJDYWNoZSBSZWZyZXNoIHZpYSBPYnNl cnZlIiBhbmNob3I9InJlZnJlc2hfdmlhX29ic2VydmUiPgogICAgICAgIDx0PlRoZXJlIGFyZSBj YXNlcyB3aGVyZSB1c2luZyB0aGUgQ29BUCBvYnNlcnZlIHByb3RvY29sIDx4cmVmIHRhcmdldD0i UkZDNzY0MSIvPiB0byBoYW5kbGUgcHJveHkgY2FjaGUgcmVmcmVzaCBpcyBwcmVmZXJhYmxlIHRv IHRoZSB2YWxpZGF0aW9uIG1lY2hhbmlzbSBiYXNlZCBvbiBFVGFnIGFzIGRlZmluZWQgaW4gPHhy ZWYgdGFyZ2V0PSJSRkM3MjUyIi8+LiAgU3VjaCBzY2VuYXJpb3MgaW5jbHVkZSwgYnV0IGFyZSBu b3QgbGltaXRlZCB0bywgc2xlZXB5IENvQVAgbm9kZXMgLS0gd2l0aCBwb3NzaWJseSBoaWdoIHZh cmlhbmNlIGluIHJlcXVlc3RzJyBkaXN0cmlidXRpb24gLS0gd2hpY2ggd291bGQgZ3JlYXRseSBi ZW5lZml0IGZyb20gYSBzZXJ2ZXIgZHJpdmVuIGNhY2hlIHVwZGF0ZSBtZWNoYW5pc20uICBJZGVh bCBjYW5kaWRhdGVzIGZvciBDb0FQIG9ic2VydmUgYXJlIGFsc28gY3Jvd2RlZCBvciB2ZXJ5IGxv dyB0aHJvdWdocHV0IG5ldHdvcmtzLCB3aGVyZSByZWR1Y3Rpb24gb2YgdGhlIHRvdGFsIG51bWJl ciBvZiBleGNoYW5nZWQgbWVzc2FnZXMgaXMgYW4gaW1wb3J0YW50IHJlcXVpcmVtZW50LjwvdD4K CiAgICAgICAgPHQ+VGhpcyBzdWJzZWN0aW9uIGFpbXMgYXQgcHJvdmlkaW5nIGEgcHJhY3RpY2Fs IGV2YWx1YXRpb24gbWV0aG9kIHRvIGRlY2lkZSB3aGV0aGVyIHJlZnJlc2hpbmcgYSBjYWNoZWQg cmVzb3VyY2UgUiBpcyBtb3JlIGVmZmljaWVudGx5IGhhbmRsZWQgdmlhIEVUYWcgdmFsaWRhdGlv biBvciBieSBlc3RhYmxpc2hpbmcgYW4gb2JzZXJ2YXRpb24gb24gUi48L3Q+CgogICAgICAgIDx0 PkxldCBUX1IgYmUgdGhlIG1lYW4gdGltZSBiZXR3ZWVuIHR3byBjbGllbnQgcmVxdWVzdHMgdG8g cmVzb3VyY2UgUiwgbGV0IFRfQyBiZSB0aGUgbWVhbiB0aW1lIGJldHdlZW4gdHdvIHJlcHJlc2Vu dGF0aW9uIGNoYW5nZXMgb2YgUiwgYW5kIGxldCBNX1IgYmUgdGhlIG1lYW4gbnVtYmVyIG9mIENv QVAgbWVzc2FnZXMgcGVyIHNlY29uZCBleGNoYW5nZWQgdG8gYW5kIGZyb20gcmVzb3VyY2UgUi4g IElmIHdlIGFzc3VtZSB0aGF0IHRoZSBpbml0aWFsIGNvc3QgZm9yIGVzdGFibGlzaGluZyB0aGUg b2JzZXJ2YXRpb24gaXMgbmVnbGlnaWJsZSwgYW4gb2JzZXJ2YXRpb24gb24gUiByZWR1Y2VzIE1f UiBpZiBhbmQgb25seSBpZiBUX1IgJmx0OyAyKlRfQyB3aXRoIHJlc3BlY3QgdG8gdXNpbmcgRVRh ZyB2YWxpZGF0aW9uLCB0aGF0IGlzIGlmIGFuZCBvbmx5IGlmIHRoZSBtZWFuIGFycml2YWwgcmF0 ZSBvZiByZXF1ZXN0cyBmb3IgcmVzb3VyY2UgUiBpcyBncmVhdGVyIHRoYW4gaGFsZiB0aGUgY2hh bmdlIHJhdGUgb2YgUi48L3Q+CgogICAgICAgIDx0PldoZW4gb2JzZXJ2aW5nIHRoZSByZXNvdXJj ZSBSLCBNX1IgaXMgYWx3YXlzIHVwcGVyIGJvdW5kZWQgYnkgMi9UX0MuPC90PgogICAgICA8L3Nl Y3Rpb24+ICA8IS0tIENhY2hlIFJlZnJlc2ggdmlhIE9ic2VydmUgLS0+CgogICAgICA8c2VjdGlv biB0aXRsZT0iVXNlIG9mIENvQVAgQmxvY2t3aXNlIFRyYW5zZmVyIiBhbmNob3I9ImhjLWJsb2Nr Ij4KICAgICAgICA8dD5BIEhDIHByb3h5IFNIT1VMRCBzdXBwb3J0IENvQVAgYmxvY2t3aXNlIHRy YW5zZmVycyA8eHJlZiB0YXJnZXQ9IkktRC5pZXRmLWNvcmUtYmxvY2siLz4gdG8gYWxsb3cgdHJh bnNwb3J0IG9mIGxhcmdlIENvQVAgcGF5bG9hZHMgd2hpbGUgYXZvaWRpbmcgZXhjZXNzaXZlIGxp bmstbGF5ZXIgZnJhZ21lbnRhdGlvbiBpbiBjb25zdHJhaW5lZCBuZXR3b3JrcywgYW5kIHRvIGNv cGUgd2l0aCBzbWFsbCBkYXRhZ3JhbSBidWZmZXJzIGluIENvQVAgZW5kLXBvaW50cyBhcyBkZXNj cmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkM3MjUyIi8+IFNlY3Rpb24gNC42LjwvdD4KCiAgICAg ICAgPHQ+QSBIQyBwcm94eSBTSE9VTEQgYXR0ZW1wdCB0byByZXRyeSBhIHBheWxvYWQtY2Fycnlp bmcgQ29BUCBQVVQgb3IgUE9TVCByZXF1ZXN0IHdpdGggYmxvY2t3aXNlIHRyYW5zZmVyIGlmIHRo ZSBkZXN0aW5hdGlvbiBDb0FQIHNlcnZlciByZXNwb25kZWQgd2l0aCA0LjEzIChSZXF1ZXN0IEVu dGl0eSBUb28gTGFyZ2UpIHRvIHRoZSBvcmlnaW5hbCByZXF1ZXN0LiAgQSBIQyBwcm94eSBTSE9V TEQgYXR0ZW1wdCB0byB1c2UgYmxvY2t3aXNlIHRyYW5zZmVyIHdoZW4gc2VuZGluZyBhIENvQVAg UFVUIG9yIFBPU1QgcmVxdWVzdCBtZXNzYWdlIHRoYXQgaXMgbGFyZ2VyIHRoYW4gQkxPQ0tXSVNF X1RIUkVTSE9MRCBieXRlcy4gVGhlIHZhbHVlIG9mIEJMT0NLV0lTRV9USFJFU0hPTEQgaXMgaW1w bGVtZW50YXRpb24tc3BlY2lmaWMsIGZvciBleGFtcGxlIGl0IGNhbiBiZToKICAgICAgICAgIDxs aXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgICAgPHQ+Y2FsY3VsYXRlZCBiYXNlZCBvbiBh IGtub3duIG9yIHR5cGljYWwgVURQIGRhdGFncmFtIGJ1ZmZlciBzaXplIGZvciBDb0FQIGVuZC1w b2ludHMsIG9yPC90PgogICAgICAgICAgICA8dD5zZXQgdG8gTiB0aW1lcyB0aGUga25vd24gc2l6 ZSBvZiBhIGxpbmstbGF5ZXIgZnJhbWUgaW4gYSBjb25zdHJhaW5lZCBuZXR3b3JrIHdoZXJlIGUu Zy4gTj01LCBvcjwvdD4KICAgICAgICAgICAgPHQ+cHJlc2V0IHRvIGEga25vd24gSVAgTVRVIHZh bHVlLCBvcjwvdD4KICAgICAgICAgICAgPHQ+c2V0IHRvIGEga25vd24gUGF0aCBNVFUgdmFsdWUu PC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgICAgVGhlIHZhbHVlIEJMT0NLV0lTRV9USFJF U0hPTEQsIG9yIHRoZSBwYXJhbWV0ZXJzIGZyb20gd2hpY2ggaXQgaXMgY2FsY3VsYXRlZCwgc2hv dWxkIGJlIGNvbmZpZ3VyYWJsZSBpbiBhIHByb3h5IGltcGxlbWVudGF0aW9uLiBUaGUgbWF4aW11 bSBibG9jayBzaXplIHRoZSBwcm94eSB3aWxsIGF0dGVtcHQgdG8gdXNlIGluIENvQVAgcmVxdWVz dHMgc2hvdWxkIGFsc28gYmUgY29uZmlndXJhYmxlLjwvdD4KCiAgICAgICAgPHQ+VGhlIEhDIHBy b3h5IFNIT1VMRCBkZXRlY3QgQ29BUCBlbmQtcG9pbnRzIG5vdCBzdXBwb3J0aW5nIGJsb2Nrd2lz ZSB0cmFuc2ZlcnMuICBUaGlzIGNhbiBiZSBkb25lIGJ5IGNoZWNraW5nIGZvciBhIDQuMDIgKEJh ZCBPcHRpb24pIHJlc3BvbnNlIHJldHVybmVkIGJ5IGFuIGVuZC1wb2ludCBpbiByZXNwb25zZSB0 byBhIENvQVAgcmVxdWVzdCB3aXRoIGEgQmxvY2sqIE9wdGlvbiwgYW5kIHN1YnNlcXVlbnQgYWJz ZW5jZSBvZiB0aGUgNC4wMiBpbiByZXNwb25zZSB0byB0aGUgc2FtZSByZXF1ZXN0IHdpdGhvdXQg QmxvY2sqIE9wdGlvbnMuICBUaGlzIGFsbG93cyB0aGUgSEMgcHJveHkgdG8gYmUgbW9yZSBlZmZp Y2llbnQsIG5vdCBhdHRlbXB0aW5nIHJlcGVhdGVkIGJsb2Nrd2lzZSB0cmFuc2ZlcnMgdG8gQ29B UCBzZXJ2ZXJzIHRoYXQgZG8gbm90IHN1cHBvcnQgaXQuPC90PgoKICAgICAgPC9zZWN0aW9uPiAg PCEtLSBVc2Ugb2YgQ29BUCBCbG9ja3dpc2UgVHJhbnNmZXIgLS0+CgogICAgICA8c2VjdGlvbiB0 aXRsZT0iQ29BUCBNdWx0aWNhc3QiIGFuY2hvcj0iaGMtbXVsdGljYXN0Ij4KICAgICAgICA8dD5B IEhDIHByb3h5IE1BWSBzdXBwb3J0IENvQVAgbXVsdGljYXN0LiBJZiBpdCBkb2VzLCB0aGUgSEMg cHJveHkgc2VuZHMgb3V0IGEgbXVsdGljYXN0IENvQVAgcmVxdWVzdCBpZiB0aGUgVGFyZ2V0IENv QVAgVVJJJ3MgYXV0aG9yaXR5IGlzIGEgbXVsdGljYXN0IElQIGxpdGVyYWwgb3IgcmVzb2x2ZXMg dG8gYSBtdWx0aWNhc3QgSVAgYWRkcmVzcy4gIElmIHRoZSBIQyBwcm94eSBkb2VzIG5vdCBzdXBw b3J0IENvQVAgbXVsdGljYXN0LCBpdCBTSE9VTEQgcmVzcG9uZCA0MDMgKEZvcmJpZGRlbikgdG8g YW55IHZhbGlkIEhUVFAgcmVxdWVzdCB0aGF0IG1hcHMgdG8gYSBDb0FQIG11bHRpY2FzdCByZXF1 ZXN0LjwvdD4KCiAgICAgICAgPHQ+RGV0YWlscyByZWxhdGVkIHRvIHN1cHBvcnRpbmcgQ29BUCBt dWx0aWNhc3QgYXJlIGN1cnJlbnRseSBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBzaW5j ZSBpbiBhIHByb3h5IHNjZW5hcmlvIGEgSFRUUCBjbGllbnQgdHlwaWNhbGx5IGV4cGVjdHMgdG8g cmVjZWl2ZSBhIHNpbmdsZSByZXNwb25zZSwgbm90IG11bHRpcGxlLiAgSG93ZXZlciwgYSBIQyBw cm94eSB0aGF0IGltcGxlbWVudHMgQ29BUCBtdWx0aWNhc3QgbWF5IGluY2x1ZGUgYXBwbGljYXRp b24tc3BlY2lmaWMgZnVuY3Rpb25zIHRvIGFnZ3JlZ2F0ZSBtdWx0aXBsZSBDb0FQIHJlc3BvbnNl cyBpbnRvIGEgc2luZ2xlIEhUVFAgcmVzcG9uc2UuICBXZSBzdWdnZXN0IHVzaW5nIHRoZSAiYXBw bGljYXRpb24vaHR0cCIgaW50ZXJuZXQgbWVkaWEgdHlwZSAoU2VjdGlvbiA4LjMuMiBvZiA8eHJl ZiB0YXJnZXQ9IlJGQzcyMzAiLz4pIHRvIGVuY2xvc2UgYSBzZXQgb2Ygb25lIG9yIG1vcmUgSFRU UCByZXNwb25zZSBtZXNzYWdlcywgZWFjaCByZXByZXNlbnRpbmcgdGhlIG1hcHBpbmcgb2Ygb25l IENvQVAgcmVzcG9uc2UuPC90PgoKICAgICAgICA8dD5Gb3IgZnVydGhlciBjb25zaWRlcmF0aW9u cyByZWxhdGVkIHRvIHRoZSBoYW5kbGluZyBvZiBtdWx0aWNhc3QgcmVxdWVzdHMsIHNlZSA8eHJl ZiB0YXJnZXQ9InNlYy5tdWx0aWNhc3QiIC8+LjwvdD4KICAgICAgPC9zZWN0aW9uPiAgPCEtLSBD b0FQIE11bHRpY2FzdCAtLT4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJUaW1lb3V0cyIgYW5jaG9y PSJoYy10aW1lb3V0cyI+CiAgICAgICAgPHQ+SWYgdGhlIENvQVAgc2VydmVyIHRha2VzIGEgbG9u ZyB0aW1lIGluIHJlc3BvbmRpbmcsIHRoZSBIVFRQIGNsaWVudCBvciBhbnkgb3RoZXIgcHJveHkg aW4gYmV0d2VlbiBtYXkgdGltZW91dC4gIEZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiB0aW1lb3V0cyBp biBIVFRQIGlzIGF2YWlsYWJsZSBpbiBTZWN0aW9uIDYuMi40IG9mIDx4cmVmIHRhcmdldD0iUkZD NzIzMCIvPi48L3Q+CgogICAgICAgIDx0PkEgSEMgcHJveHkgTVVTVCBkZWZpbmUgYW4gaW50ZXJu YWwgdGltZW91dCBmb3IgZWFjaCBwZW5kaW5nIENvQVAgcmVxdWVzdCwgYmVjYXVzZSB0aGUgQ29B UCBzZXJ2ZXIgbWF5IHNpbGVudGx5IGRpZSBiZWZvcmUgY29tcGxldGluZyB0aGUgcmVxdWVzdC4g IEFzc3VtaW5nIHRoZSBQcm94eSB1c2VzIGNvbmZpcm1hYmxlIENvQVAgcmVxdWVzdHMsIHN1Y2gg dGltZW91dCB2YWx1ZSBUIFNIT1VMRCBiZSBhdCBsZWFzdDwvdD4KCiAgICAgICAgPHQ+VCA9IE1B WF9SVFQgKyBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZPC90PgoKICAgICAgICA8dD53aGVyZSBN QVhfUlRUIGlzIGRlZmluZWQgaW4gW1JGQzcyNTJdIGFuZCBNQVhfU0VSVkVSX1JFU1BPTlNFX0RF TEFZIGlzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkM3MzkwIi8+LjwvdD4KICAgICAgPC9z ZWN0aW9uPiAgPCEtLSBUaW1lb3V0cyAtLT4KCiAgICA8L3NlY3Rpb24+IDwhLS0gQWRkaXRpb25h bCBHdWlkZWxpbmVzIC0tPgoKICAgIDwhLS0gKioqKioqKioqKioqKioqKioqKiBNQUlOIFNFQ1RJ T04gKioqKioqKioqKioqKioqKioqKiogLS0+CiAgICA8c2VjdGlvbiBhbmNob3I9IklBTkEiIHRp dGxlPSJJQU5BIENvbnNpZGVyYXRpb25zIj4KICAgICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtY29y ZS1oYy1yZWciIHRpdGxlPSJOZXcgJ2NvcmUuaGMnIFJlc291cmNlIFR5cGUiPgogICAgICAgIDx0 PlRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIGEgbmV3IFJlc291cmNlIFR5cGUgKHJ0PSkgTGluayBU YXJnZXQgQXR0cmlidXRlLCAnY29yZS5oYycsIGluIHRoZSAiUmVzb3VyY2UgVHlwZSAocnQ9KSBM aW5rIFRhcmdldCBBdHRyaWJ1dGUgVmFsdWVzIiBzdWJyZWdpc3RyeSB1bmRlciB0aGUgIkNvbnN0 cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIChDb1JFKSBQYXJhbWV0ZXJzIiByZWdpc3RyeS48 L3Q+CgogICAgICAgIDx0PkF0dHJpYnV0ZSBWYWx1ZTogY29yZS5oYzwvdD4KICAgICAgICA8dD5E ZXNjcmlwdGlvbjogSFRUUCB0byBDb0FQIG1hcHBpbmcgYmFzZSByZXNvdXJjZS48L3Q+CiAgICAg ICAgPHQ+UmVmZXJlbmNlOiBTZWUgPHhyZWYgdGFyZ2V0PSJzZWN0aW9uLmRpc2NvdmVyeSIvPi48 L3Q+CiAgICAgIDwvc2VjdGlvbj4gIDwhLS0gTmV3ICdjb3JlLmhjJyBSZXNvdXJjZSBUeXBlIC0t PgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtY29hcC1wYXlsb2FkLXJlZyIgdGl0bGU9Ik5l dyAnY29hcC1wYXlsb2FkJyBJbnRlcm5ldCBNZWRpYSBUeXBlIj4KICAgICAgICA8dD5UaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhlICJhcHBsaWNhdGlvbi9jb2FwLXBheWxvYWQiIG1lZGlhIHR5cGUg d2l0aCBhIHNpbmdsZSBwYXJhbWV0ZXIgImNmIi4gVGhpcyBtZWRpYSB0eXBlIHJlcHJlc2VudHMg YW55IHBheWxvYWQgdGhhdCBhIENvQVAgbWVzc2FnZSBjYW4gY2FycnksIGhhdmluZyBhIGNvbnRl bnQgZm9ybWF0IHRoYXQgY2FuIGJlIGlkZW50aWZpZWQgYnkgYSBDb0FQIENvbnRlbnQtRm9ybWF0 IHBhcmFtZXRlciAoYW4gaW50ZWdlciBpbiByYW5nZSAwLTY1NTM1KS4gIFRoZSBwYXJhbWV0ZXIg ImNmIiBpcyB0aGUgaW50ZWdlciBkZWZpbmluZyB0aGUgQ29BUCBjb250ZW50IGZvcm1hdC48L3Q+ CgogICAgICAgIDx0PlR5cGUgbmFtZTogYXBwbGljYXRpb248L3Q+CiAgICAgICAgPHQ+U3VidHlw ZSBuYW1lOiBjb2FwLXBheWxvYWQ8L3Q+CgogICAgICAgIDx0PlJlcXVpcmVkIHBhcmFtZXRlcnM6 PC90PgogICAgICAgIDx0PmNmIC0gQ29BUCBDb250ZW50LUZvcm1hdCBpbnRlZ2VyIGluIHJhbmdl IDAtNjU1MzUgZGVub3RpbmcgdGhlIGNvbnRlbnQgZm9ybWF0IG9mIHRoZSBDb0FQIHBheWxvYWQg Y2FycmllZC48L3Q+CgogICAgICAgIDx0Pk9wdGlvbmFsIHBhcmFtZXRlcnM6IE5vbmU8L3Q+Cgog ICAgICAgIDx0PkVuY29kaW5nIGNvbnNpZGVyYXRpb25zOjwvdD4KICAgICAgICA8dD5UaGUgc3Bl Y2lmaWMgQ29BUCBjb250ZW50IGZvcm1hdCBlbmNvZGluZyBjb25zaWRlcmF0aW9ucyBmb3IgdGhl IHNlbGVjdGVkIENvbnRlbnQtRm9ybWF0IChjZiBwYXJhbWV0ZXIpIGFwcGx5LjwvdD4KCiAgICAg ICAgPHQ+U2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6PC90PgogICAgICAgIDx0PlRoZSBzcGVjaWZp YyBDb0FQIGNvbnRlbnQgZm9ybWF0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGUgc2Vs ZWN0ZWQgQ29udGVudC1Gb3JtYXQgKGNmIHBhcmFtZXRlcikgYXBwbHkuPC90PgoKICAgICAgICA8 dD5JbnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRpb25zOjwvdD4KICAgICAgICA8dD5QdWJsaXNo ZWQgc3BlY2lmaWNhdGlvbjogKHRoaXMgSS1EIC0gVEJEKTwvdD4KCiAgICAgICAgPHQ+QXBwbGlj YXRpb25zIHRoYXQgdXNlIHRoaXMgbWVkaWEgdHlwZTo8L3Q+CiAgICAgICAgPHQ+SFRUUC10by1D b0FQIFByb3hpZXMuPC90PgoKICAgICAgICA8dD5GcmFnbWVudCBpZGVudGlmaWVyIGNvbnNpZGVy YXRpb25zOiBOL0E8L3Q+CgogICAgICAgIDx0PkFkZGl0aW9uYWwgaW5mb3JtYXRpb246CiAgICAg ICAgICA8bGlzdCBzdHlsZT0iaGFuZ2luZyI+CiAgICAgICAgICAgIDx0PkRlcHJlY2F0ZWQgYWxp YXMgbmFtZXMgZm9yIHRoaXMgdHlwZTogTi9BPC90PgogICAgICAgICAgICA8dD5NYWdpYyBudW1i ZXIocyk6IE4vQTwvdD4KICAgICAgICAgICAgPHQ+RmlsZSBleHRlbnNpb24ocyk6IE4vQTwvdD4K ICAgICAgICAgICAgPHQ+TWFjaW50b3NoIGZpbGUgdHlwZSBjb2RlKHMpOiBOL0E8L3Q+CiAgICAg ICAgICA8L2xpc3Q+CiAgICAgICAgPC90PgoKICAgICAgICA8dD5QZXJzb24gYW5kIGVtYWlsIGFk ZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoKICAgICAgICAgIDxsaXN0 IHN0eWxlPSJoYW5naW5nIj4KICAgICAgICAgICAgPHQ+RXNrbyBEaWprICgiZXNrb0BpZWVlLm9y ZyIpPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KICAgICAgICA8dD5JbnRlbmRl ZCB1c2FnZTogQ09NTU9OPC90PgogICAgICAgIDx0PlJlc3RyaWN0aW9ucyBvbiB1c2FnZTo8L3Q+ CiAgICAgICAgPHQ+QW4gYXBwbGljYXRpb24gKG9yIHVzZXIpIGNhbiBvbmx5IHVzZSB0aGlzIG1l ZGlhIHR5cGUgaWYgaXQgaGFzIHRvIHJlcHJlc2VudCBhIENvQVAgcGF5bG9hZCBvZiB3aGljaCB0 aGUgc3BlY2lmaWVkIENvQVAgQ29udGVudC1Gb3JtYXQgaXMgYW4gdW5yZWNvZ25pemVkIG51bWJl cjsgc3VjaCB0aGF0IGEgcHJvcGVyIHRyYW5zbGF0aW9uIGRpcmVjdGx5IHRvIHRoZSBlcXVpdmFs ZW50IEhUVFAgbWVkaWEgdHlwZSBpcyBub3QgcG9zc2libGUuPC90PgogICAgICAgIDx0PkF1dGhv cjogQ29SRSBXRzwvdD4KICAgICAgICA8dD5DaGFuZ2UgY29udHJvbGxlcjogSUVURjwvdD4KICAg ICAgICA8dD5Qcm92aXNpb25hbCByZWdpc3RyYXRpb24/IChzdGFuZGFyZHMgdHJlZSBvbmx5KTog Ti9BPC90PgogICAgICA8L3NlY3Rpb24+ICA8IS0tICJOZXcgJ2NvYXAtcGF5bG9hZCcgSW50ZXJu ZXQgTWVkaWEgVHlwZSIgLS0+CiAgICA8L3NlY3Rpb24+ICA8IS0tIElBTkEgQ29uc2lkZXJhdGlv bnMgLS0+CgogICAgPCEtLSAqKioqKioqKioqKioqKioqKioqIE1BSU4gU0VDVElPTiAqKioqKioq KioqKioqKioqKioqKiAtLT4KICAgIDxzZWN0aW9uIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyIgYW5jaG9yPSJzZWMiPgogICAgICA8dD5UaGUgc2VjdXJpdHkgY29uY2VybnMgcmFpc2Vk IGluIFNlY3Rpb24gOS4yIG9mIFtSRkM3MjMwXSBhbHNvIGFwcGx5IHRvIHRoZSBIQyBwcm94eSBz Y2VuYXJpby48L3Q+CgogICAgICA8dD5BIEhDIHByb3h5IGRlcGxveWVkIGF0IHRoZSBib3VuZGFy eSBvZiBhIGNvbnN0cmFpbmVkIG5ldHdvcmsgaXMgYW4gZWFzeSBzaW5nbGUgcG9pbnQgb2YgZmFp bHVyZSBmb3IgcmVkdWNpbmcgYXZhaWxhYmlsaXR5LiAgQXMgc3VjaCwgc3BlY2lhbCBjYXJlIHNo b3VsZCBiZSB0YWtlbiBpbiBkZXNpZ25pbmcsIGRldmVsb3BpbmcgYW5kIG9wZXJhdGluZyBpdCwg a2VlcGluZyBpbiBtaW5kIHRoYXQsIGluIG1vc3QgY2FzZXMsIGl0IGhhcyBmZXdlciBsaW1pdGF0 aW9ucyB0aGFuIHRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIGl0IGlzIHNlcnZpbmcuPC90PgoKICAg ICAgPHQ+VGhlIGZvbGxvd2luZyBzdWIgcGFyYWdyYXBocyBjYXRlZ29yaXplIGFuZCBkaXNjdXNz IGEgc2V0IG9mIHNwZWNpZmljIHNlY3VyaXR5IGlzc3VlcyByZWxhdGVkIHRvIHRoZSB0cmFuc2xh dGlvbiwgY2FjaGluZyBhbmQgZm9yd2FyZGluZyBmdW5jdGlvbmFsaXR5IGV4cG9zZWQgYnkgYSBI QyBwcm94eS48L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iTXVsdGljYXN0IiBhbmNob3I9InNl Yy5tdWx0aWNhc3QiPgogICAgICA8dD5NdWx0aWNhc3QgcmVxdWVzdHMgaW1wb3NlIGEgbm9uIHRy aXZpYWwgY29zdCBvbiB0aGUgY29uc3RyYWluZWQgbmV0d29yayBhbmQgZW5kcG9pbnRzLCBhbmQg bWlnaHQgYmUgZXhwbG9pdGVkIGFzIGEgRG9TIGF0dGFjayB2ZWN0b3IgKHNlZSBhbHNvIDx4cmVm IHRhcmdldD0ic2VjLnRyYWZmaWMtb3ZlcmZsb3ciLz4pLiAgRnJvbSBhIHByaXZhY3kgcGVyc3Bl Y3RpdmUsIHRoZXkgY2FuIGJlIHVzZWQgdG8gZ2F0aGVyIGRldGFpbGVkIGluZm9ybWF0aW9uIGFi b3V0IHRoZSByZXNvdXJjZXMgaG9zdGVkIGluIHRoZSBjb25zdHJhaW5lZCBuZXR3b3JrLiAgRm9y IHRoZXNlIHJlYXNvbnMsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgcmVxdWVzdHMgdG8gbXVsdGlj YXN0IHJlc291cmNlcyBhcmUgYWNjZXNzIGNvbnRyb2xsZWQgd2l0aCBhIGRlZmF1bHQtZGVueSBw b2xpY3kuICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSByZXF1ZXN0b3Igb2YgYSBtdWx0aWNh c3QgcmVzb3VyY2UgaXMgc3Ryb25nbHkgYXV0aGVudGljYXRlZC4gIElmIHByaXZhY3kgaXMgYSBj b25jZXJuLCBmb3IgZXhhbXBsZSB3aGVuZXZlciB0aGUgSFRUUCByZXF1ZXN0IHRyYW5zaXRzIHRo cm91Z2ggdGhlIHB1YmxpYyBJbnRlcm5ldCwgdGhlIHJlcXVlc3QgU0hPVUxEIGJlIHRyYW5zcG9y dGVkIG92ZXIgYSBtdXR1YWxseSBhdXRoZW50aWNhdGVkIGFuZCBlbmNyeXB0ZWQgVExTIGNvbm5l Y3Rpb24uPC90PgogICAgICA8L3NlY3Rpb24+ICA8IS0tIE11bHRpY2FzdCAtLT4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPSJUcmFmZmljIE92ZXJmbG93IiBhbmNob3I9InNlYy50cmFmZmljLW92ZXJm bG93Ij4KICAgICAgICA8dD5EdWUgdG8gdGhlIHR5cGljYWxseSBjb25zdHJhaW5lZCBuYXR1cmUg b2YgQ29BUCBub2RlcywgcGFydGljdWxhciBhdHRlbnRpb24gc2hvdWxkIGJlIGdpdmVuIHRvIHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiB0cmFmZmljIHJlZHVjdGlvbiBtZWNoYW5pc21zIChzZWUgPHhy ZWYgdGFyZ2V0PSJoYy1jYWNoaW5nIi8+KSwgYmVjYXVzZSBpbmVmZmljaWVudCBwcm94eSBpbXBs ZW1lbnRhdGlvbnMgY2FuIGJlIHRhcmdldGVkIGJ5IHVuY29uc3RyYWluZWQgSW50ZXJuZXQgYXR0 YWNrZXJzLiAgQmFuZHdpZHRoIG9yIGNvbXBsZXhpdHkgaW52b2x2ZWQgaW4gc3VjaCBhdHRhY2tz IGlzIHZlcnkgbG93LjwvdD4KCiAgICAgICAgPHQ+QW4gYW1wbGlmaWNhdGlvbiBhdHRhY2sgdG8g dGhlIGNvbnN0cmFpbmVkIG5ldHdvcmsgbWF5IGJlIHRyaWdnZXJlZCBieSBhIG11bHRpY2FzdCBy ZXF1ZXN0IGdlbmVyYXRlZCBieSBhIHNpbmdsZSBIVFRQIHJlcXVlc3Qgd2hpY2ggaXMgbWFwcGVk IHRvIGEgQ29BUCBtdWx0aWNhc3QgcmVzb3VyY2UsIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDEx LjMgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjUyIi8+LjwvdD4KCiAgICAgICAgPHQ+VGhlIHJpc2sg bGlrZWxpaG9vZCBvZiB0aGlzIGFtcGxpZmljYXRpb24gdGVjaG5pcXVlIGlzIGhpZ2hlciB0aGFu IGFuIGFtcGxpZmljYXRpb24gYXR0YWNrIGNhcnJpZWQgb3V0IGJ5IGEgbWFsaWNpb3VzIGNvbnN0 cmFpbmVkIGRldmljZSAoZS5nLiBJQ01QdjYgZmxvb2RpbmcsIGxpa2UgUGFja2V0IFRvbyBCaWcs IG9yIFBhcmFtZXRlciBQcm9ibGVtIG9uIGEgbXVsdGljYXN0IGRlc3RpbmF0aW9uIDx4cmVmIHRh cmdldD0iUkZDNDczMiIvPiksIHNpbmNlIGl0IGRvZXMgbm90IHJlcXVpcmUgZGlyZWN0IGFjY2Vz cyB0byB0aGUgY29uc3RyYWluZWQgbmV0d29yay48L3Q+CgogICAgICAgIDx0PlRoZSBmZWFzaWJp bGl0eSBvZiB0aGlzIGF0dGFjayB3aGljaCBkaXNydXB0cyBhdmFpbGFiaWxpdHkgb2YgdGhlIHRh cmdldGVkIENvQVAgc2VydmVyIGNhbiBiZSBsaW1pdGVkIGJ5IGFjY2VzcyBjb250cm9sbGluZyB0 aGUgZXhwb3NlZCBtdWx0aWNhc3QgcmVzb3VyY2VzLCBzbyB0aGF0IG9ubHkga25vd24vYXV0aG9y aXplZCB1c2VycyBjYW4gYWNjZXNzIHN1Y2ggVVJJcy48L3Q+CiAgICAgIDwvc2VjdGlvbj4gIDwh LS0gVHJhZmZpYyBPdmVyZmxvdyAtLT4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJIYW5kbGluZyBT ZWN1cmVkIEV4Y2hhbmdlcyIgYW5jaG9yPSJzZWMtZXhjaGFuZ2VzIj4KICAgICAgICA8dD5BbiBI VFRQIHJlcXVlc3QgY2FuIGJlIHNlbnQgdG8gdGhlIEhDIHByb3h5IG92ZXIgYSBzZWN1cmVkIGNv bm5lY3Rpb24uICBIb3dldmVyLCB0aGVyZSBtYXkgbm90IGFsd2F5cyBleGlzdCBhIHNlY3VyZSBj b25uZWN0aW9uIG1hcHBpbmcgdG8gQ29BUC4gIEZvciBleGFtcGxlLCBhIHNlY3VyZSBkaXN0cmli dXRpb24gbWV0aG9kIGZvciBtdWx0aWNhc3QgdHJhZmZpYyBpcyBjb21wbGV4IGFuZCBtYXkgbm90 IGJlIGltcGxlbWVudGVkIChzZWUgW1JGQzczOTBdKS48L3Q+CgogICAgICAgIDx0PkEgSEMgcHJv eHkgc2hvdWxkIGltcGxlbWVudCBydWxlcyBmb3Igc2VjdXJpdHkgY29udGV4dCB0cmFuc2xhdGlv bnMuICBGb3IgZXhhbXBsZSBhbGwgImh0dHBzIiB1bmljYXN0IHJlcXVlc3RzIGFyZSB0cmFuc2xh dGVkIHRvICJjb2FwcyIgcmVxdWVzdHMsIG9yICJodHRwcyIgcmVxdWVzdHMgYXJlIHRyYW5zbGF0 ZWQgdG8gdW5zZWN1cmVkICJjb2FwIiByZXF1ZXN0cy4gIEFub3RoZXIgcnVsZSBjb3VsZCBzcGVj aWZ5IHRoZSBzZWN1cml0eSBwb2xpY3kgYW5kIHBhcmFtZXRlcnMgdXNlZCBmb3IgRFRMUyBjb25u ZWN0aW9ucy4gU3VjaCBydWxlcyB3aWxsIGxhcmdlbHkgZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlv biBhbmQgbmV0d29yayBjb250ZXh0IGluIHdoaWNoIHRoZSBIQyBwcm94eSBvcGVyYXRlcy4gIFRo ZXNlIHJ1bGVzIHNob3VsZCBiZSBjb25maWd1cmFibGUuPC90PgoKICAgICAgICA8dD5JdCBpcyBS RUNPTU1FTkRFRCB0aGF0LCBieSBkZWZhdWx0LCBhY2Nlc3NpbmcgYSAiY29hcHMiIFVSSSBpcyBv bmx5IGFsbG93ZWQgZnJvbSBhIGNvcnJlc3BvbmRpbmcgImh0dHBzIiBVUkkuPC90PgoKICAgICAg ICA8dD5CeSBkZWZhdWx0LCBhIEhDIHByb3h5IFNIT1VMRCByZWplY3QgYW55IHNlY3VyZWQgY2xp ZW50IHJlcXVlc3QgaWYgdGhlcmUgaXMgbm8gY29uZmlndXJlZCBzZWN1cml0eSBwb2xpY3kgbWFw cGluZy4gIFRoaXMgcmVjb21tZW5kYXRpb24gbWF5IGJlIHJlbGF4ZWQgaW4gY2FzZSB0aGUgZGVz dGluYXRpb24gbmV0d29yayBpcyBiZWxpZXZlZCB0byBiZSBzZWN1cmVkIGJ5IG90aGVyIG1lYW5z LiAgQXNzdW1pbmcgdGhhdCBDb0FQIG5vZGVzIGFyZSBpc29sYXRlZCBiZWhpbmQgYSBmaXJld2Fs bCBhcyBpbiB0aGUgSEMgcHJveHkgZGVwbG95bWVudCBzaG93biBpbiA8eHJlZiB0YXJnZXQ9ImZp Zy1odHRwLWNvYXAtZGVwbG95bWVudCIvPiwgdGhlIEhDIHByb3h5IG1heSBiZSBjb25maWd1cmVk IHRvIHRyYW5zbGF0ZSB0aGUgaW5jb21pbmcgSFRUUFMgcmVxdWVzdCB1c2luZyBwbGFpbiBDb0FQ IChOb1NlYyBtb2RlKS48L3Q+CiAKICAgICAgPC9zZWN0aW9uPiAgPCEtLSBIYW5kbGluZyBTZWN1 cmVkIEV4Y2hhbmdlcyAtLT4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJVUkkgTWFwcGluZyI+CiAg ICAgICAgPHQ+VGhlIGZvbGxvd2luZyByaXNrcyByZWxhdGVkIHRvIHRoZSBVUkkgbWFwcGluZyBk ZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJVUkktbWFwcGluZyIvPiBhbmQgaXRzIHVzZSBieSBI QyBwcm94aWVzIGhhdmUgYmVlbiBpZGVudGlmaWVkOgogICAgICAgICAgPGxpc3Qgc3R5bGU9Imhh bmdpbmciPgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iRG9TIGF0dGFjayBvbiB0aGUgY29uc3Ry YWluZWQvQ29BUCBuZXR3b3JrLiI+PHZzcGFjZS8+TWl0aWdhdGlvbjogYnkgZGVmYXVsdCBkZW55 IGFueSBUYXJnZXQgQ29BUCBVUkkgd2hvc2UgYXV0aG9yaXR5IGlzIChvciBtYXBzIHRvKSBhIG11 bHRpY2FzdCBhZGRyZXNzLiAgVGhlbiBleHBsaWNpdGx5IHdoaXRlLWxpc3QgbXVsdGljYXN0IHJl c291cmNlcy9hdXRob3JpdGllcyB0aGF0IGFyZSBhbGxvd2VkIHRvIGJlIGRlLXJlZmVyZW5jZWQu IFNlZSBhbHNvIDx4cmVmIHRhcmdldD0iaGMtbXVsdGljYXN0Ii8+LjwvdD4KICAgICAgICAgICAg PHQgaGFuZ1RleHQ9IkxlYWtpbmcgaW5mb3JtYXRpb24gb24gdGhlIGNvbnN0cmFpbmVkL0NvQVAg bmV0d29yayByZXNvdXJjZXMgYW5kIHRvcG9sb2d5LiI+PHZzcGFjZS8+TWl0aWdhdGlvbjogYnkg ZGVmYXVsdCBkZW55IGFueSBUYXJnZXQgQ29BUCBVUkkgKGVzcGVjaWFsbHkgLy53ZWxsLWtub3du L2NvcmUgaXMgYSByZXNvdXJjZSB0byBiZSBwcm90ZWN0ZWQpLCBhbmQgdGhlbiBleHBsaWNpdGx5 IHdoaXRlLWxpc3QgcmVzb3VyY2VzIHRoYXQgYXJlIGFsbG93ZWQgdG8gYmUgc2VlbiBmcm9tIG91 dHNpZGUuPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iVGhlIGludGVybmFsIENvQVAgVGFy Z2V0IHJlc291cmNlIGlzIHRvdGFsbHkgdHJhbnNwYXJlbnQgZnJvbSBvdXRzaWRlLiI+PHZzcGFj ZS8+TWl0aWdhdGlvbjogaW1wbGVtZW50IGEgSFRUUFMtb25seSBpbnRlcmZhY2UsIHdoaWNoIG1h a2VzIHRoZSBUYXJnZXQgQ29BUCBVUkkgdG90YWxseSBvcGFxdWUgdG8gYSBwYXNzaXZlIGF0dGFj a2VyLjwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4g PCEtLSBTZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBmb3IgIlVSSSBNYXBwaW5n IiAtLT4KICAgIDwvc2VjdGlvbj4gIDwhLS0gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLS0+Cgog ICAgPHNlY3Rpb24gdGl0bGU9IkFja25vd2xlZGdlbWVudHMiPgogICAgICA8dD5BbiBpbml0aWFs IHZlcnNpb24gb2YgPHhyZWYgdGFyZ2V0PSJ0YWItaHR0cC1jb2FwIi8+IGluIDx4cmVmIHRhcmdl dD0iaGMtcmVzcCIvPiBoYXMgYmVlbiBwcm92aWRlZCBpbiByZXZpc2lvbiAtMDUgb2YgdGhlIENv UkUgQ29BUCBJLUQuICBTcGVjaWFsIHRoYW5rcyB0byBQZXRlciB2YW4gZGVyIFN0b2sgZm9yIGNv dW50bGVzcyBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbnMgb24gdGhpcyBkb2N1bWVudCwgdGhhdCBj b250cmlidXRlZCB0byBpdHMgY3VycmVudCBzdHJ1Y3R1cmUgYW5kIHRleHQuPC90PgoKICAgICAg PHQ+VGhhbmtzIHRvCiAgICAgIEFiaGlqYW4gQmhhdHRhY2hhcnl5YSwKICAgICAgQnJpYW4gRnJh bmssCiAgICAgIENhcnN0ZW4gQm9ybWFubiwKICAgICAgQ2hyaXN0aWFuIEFtc3VzcywKICAgICAg Q2hyaXN0aWFuIEdyb3ZlcywKICAgICAgQ3VsbGVuIEplbm5pbmdzLAogICAgICBEb3JvdGh5IEdl bGxlcnQsCiAgICAgIEZyYW5jZXNjbyBDb3JhenphLAogICAgICBIYW5uZXMgVHNjaG9mZW5pZywK ICAgICAgSmFpbWUgSmltZW5leiwKICAgICAgS2VwZW5nIExpLAogICAgICBLZXJyeSBMeW5uLAog ICAgICBLbGF1cyBIYXJ0a2UsCiAgICAgIExpbnlpIFRpYW4sCiAgICAgIE1pY2hlbGUgUm9zc2ks CiAgICAgIE1pY2hlbGUgWm9yemksCiAgICAgIE5pY29sYSBCdWksCiAgICAgIFBldGVyIFNhaW50 LUFuZHJlLAogICAgICBaYWNoIFNoZWxieQogICAgICBmb3IgaGVscGZ1bCBjb21tZW50cyBhbmQg ZGlzY3Vzc2lvbnMgdGhhdCBoYXZlIHNoYXBlZCB0aGUgZG9jdW1lbnQuPC90PgogCiAgICAgIDx0 PlRoZSByZXNlYXJjaCBsZWFkaW5nIHRvIHRoZXNlIHJlc3VsdHMgaGFzIHJlY2VpdmVkIGZ1bmRp bmcgZnJvbSB0aGUgRXVyb3BlYW4gQ29tbXVuaXR5J3MgU2V2ZW50aCBGcmFtZXdvcmsgUHJvZ3Jh bW1lIFtGUDcvMjAwNy0yMDEzXSB1bmRlciBncmFudCBhZ3JlZW1lbnQgbi4yNTE1NTcuPC90Pgog ICAgPC9zZWN0aW9uPgogIDwvbWlkZGxlPgoKICA8YmFjaz4KICAgIDxyZWZlcmVuY2VzIHRpdGxl PSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAgICAgICZSRkMyMTE5OwogICAgICAmUkZDMzk4NjsK ICAgICAgJlJGQzUyMzQ7CiAgICAgICZSRkM2NTcwOwogICAgICAmUkZDNjY5MDsKICAgICAgJlJG QzcyMzA7CiAgICAgICZSRkM3MjMxOwogICAgICAmUkZDNzIzMjsKICAgICAgJlJGQzcyMzU7CiAg ICAgICZSRkM3MjUyOwogICAgICAmUkZDNzY0MTsKICAgICAgJkktRC5pZXRmLWNvcmUtYmxvY2s7 CiAgICA8L3JlZmVyZW5jZXM+CiAgICA8cmVmZXJlbmNlcyB0aXRsZT0iSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcyI+CiAgICAgICZSRkMyNjE2OwogICAgICAmUkZDMzA0MDsKICAgICAgJlJGQzQ3MzI7 CiAgICAgICZSRkM3MDQ5OwogICAgICAmUkZDNzM5MDsKICAgICAgJkktRC5pZXRmLWNvcmUtcmVz b3VyY2UtZGlyZWN0b3J5OwogICAgICAmSS1ELmlldGYtY29yZS1saW5rcy1qc29uOwogICAgPC9y ZWZlcmVuY2VzPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJDaGFuZ2UgTG9nIj4KICAgICAgPHQ+W05v dGUgdG8gUkZDIEVkaXRvcjogUGxlYXNlIHJlbW92ZSB0aGlzIHNlY3Rpb24gYmVmb3JlIHB1Ymxp Y2F0aW9uLl08L3Q+CgogICAgICA8dD5DaGFuZ2VzIGZyb20gaWV0Zi0xMiB0byBpZXRmLTEzIChD aHJpc3RpYW4gQW1zdXNzJyBjb21tZW50cyk6CiAgICAgICAgPGxpc3Qgc3R5bGU9InN5bWJvbHMi PgogICAgICAgICAgPHQ+TW9yZSBtaXNzaW5nIHNsYXNoZXMgaW4gVVJJIG1hcHBpbmcgdGVtcGxh dGUgZXhhbXBsZXMuPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+Q2hh bmdlcyBmcm9tIGlldGYtMTEgdG8gaWV0Zi0xMiAoMm5kIFdHTEMpOgogICAgICAgIDxsaXN0IHN0 eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PkFkZHJlc3NlZCBhIGZldyBlZGl0b3JpYWwgaXNz dWVzIChpbmNsdWRpbmcgYSBjbGFyaWZpY2F0aW9uIG9uIHdoZW4gdG8gdXNlIHFxIHZzIHEgaW4g dGhlIFVSSSBtYXBwaW5nIHRlbXBsYXRlKS48L3Q+CiAgICAgICAgICA8dD5GaXhlZCBtaXNzaW5n IHNsYXNoIGluIG9uZSB0ZW1wbGF0ZSBleGFtcGxlLjwvdD4KICAgICAgICAgIDx0PkFkZGVkIHBh cmEgYWJvdXQgdGhlIG5lZWQgZm9yIGZ1dHVyZSBDb0FQIHByb3RvY29sIGVsZW1lbnRzIHRvIGRl ZmluZSB0aGVpciBvd24gSFRUUCBtYXBwaW5ncy48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8 L3Q+CgogICAgICA8dD5DaGFuZ2VzIGZyb20gaWV0Zi0xMCB0byBpZXRmLTExIChDaGFpciByZXZp ZXcpOgogICAgICAgIDxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PlJlbW92ZWQg Y3Uvc3UgZGlzdGluY3Rpb24gZnJvbSB0aGUgVVJJIG1hcHBpbmcgdGVtcGxhdGUuPC90PgogICAg ICAgICAgPHQ+QWRkcmVzc2VkIGEgZmV3IGVkaXRvcmlhbCBpc3N1ZXMuPC90PgogICAgICAgIDwv bGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+Q2hhbmdlcyBmcm9tIGlldGYtMDkgdG8gaWV0Zi0x MDoKICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICA8dD5BZGRyZXNzZWQg VGlja2V0ICM0MDEgLSBDbGFyaWZpZWQgdGhhdCBkcmFmdCBjb3ZlcnMgbm90IG9ubHkgUmV2ZXJz ZSBIQyBQcm94eSBidXQgdGhhdCBtYW55IHBhcnRzIGFsc28gYXBwbHkgdG8gRm9yd2FyZCBhbmQg SW50ZXJjZXB0aW9uIFByb3hpZXMuPC90PgoJCSAgPHQ+Q2xhcmlmaWVkIHRoYXQgZHJhZnQgY29u Y2VudHJhdGVzIG9uIHRoZSBIVFRQLXRvLUNvQVAgbWFwcGluZyBkaXJlY3Rpb24gKGkuZS4gdGhl IEhDIHByb3h5IGlzIGEgSFRUUCBzZXJ2ZXIgYW5kIGEgQ29BUCBjbGllbnQpLjwvdD4KCQkgIDx0 PkNsYXJpZmllZCB0aGUgIm51bGwgbWFwcGluZyIgY2FzZSB3aGVyZSBubyBDb0FQIFVSSSBpbmZv cm1hdGlvbiBpcyBlbWJlZGRlZCBpbiB0aGUgSFRUUCByZXF1ZXN0IFVSSS48L3Q+CgkJICA8dD5N b3ZlZCBtdWx0aWNhc3QgcmVsYXRlZCBzZWN1cml0eSB0ZXh0IHRvIHRoZSAiU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMiIHRvIGNvbnNvbGlkYXRlIGFsbCBzZWN1cml0eSBpbmZvcm1hdGlvbiBpbiBv bmUgbG9jYXRpb24uPC90PgoJCSAgPHQ+UmVtb3ZlZCByZWZlcmVuY2VzIHRvICJwbGFjZW1lbnQi IG9mIHByb3h5IChlLmcuIHNlcnZlci1zaWRlIHZzIGNsaWVudC1zaWRlKSBhcyBpcyBjb25mdXNp bmcgYW5kIHByb3ZpZGVzIGxpdHRsZSBhZGRlZCB2YWx1ZS48L3Q+CgkJICA8dD5GaXhlZCB2ZXJz aW9uIG51bWJlcnMgb24gcmVmZXJlbmNlcyB0aGF0IHdlcmUgY29ycnVwdGVkIGluIGxhc3QgcmV2 aXNpb24gZHVlIHRvIG91dGRhdGVkIHhtbDJyZmMgY29udmVyc2lvbiB0b29sIGxvY2FsIGNhY2hl LjwvdD4KCQkgIDx0PlZhcmlvdXMgZWRpdG9yaWFsIGltcHJvdmVtZW50cy48L3Q+CiAgICAgICAg PC9saXN0PgogICAgICA8L3Q+CgogICAgICA8dD5DaGFuZ2VzIGZyb20gaWV0Zi0wOCB0byBpZXRm LTA5OgogICAgICAgIDxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PkNsZWFuIHVw IHJlcXVpcmVtZW50cyBsYW5ndWFnZSBhcyBwZXIgS2xhdXMnIGNvbW1lbnQuPC90PgogICAgICAg IDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+Q2hhbmdlcyBmcm9tIGlldGYtMDcgdG8gaWV0 Zi0wODoKICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICA8dD5BZGRyZXNz ZWQgV0dMQyByZXZpZXcgY29tbWVudHMgZnJvbSBLbGF1cyBIYXJ0a2UgYXMgcGVyIHRoZSBjb3Jy ZXNwb25kZW5jZSBvZiBNYXJjaCA5LCAyMDE2IG9uIHRoZSBDT1JFIFdHIG1haWxpbmcgbGlzdC4g PC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+Q2hhbmdlcyBmcm9tIGll dGYtMDYgdG8gaWV0Zi0wNzoKICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAg ICA8dD5BZGRyZXNzZWQgVGlja2V0ICMzODQgLSBTZWN0aW9uIDUuNC4xIGRlc2NyaWJlcyBicmll Zmx5IChpbmZvcm1hdGl2ZSkgaG93IHRvIGRpc2NvdmVyIENvQVAgcmVzb3VyY2VzIGZyb20gYW4g SFRUUCBjbGllbnQuPC90PgogICAgICAgICAgPHQ+QWRkcmVzc2VkIFRpY2tldCAjMzc4IC0gRm9y IEhUVFAgbWVkaWEgdHlwZSB0byBDb0FQIGNvbnRlbnQgZm9ybWF0IG1hcHBpbmcgYW5kIHZpY2Ug dmVyc2E6IGEgbmV3IGRyYWZ0IChUQkQpIG1heSBiZSBwcm9wb3NlZCBpbiBDb1JFIHdoaWNoIGRl c2NyaWJlcyBhbiBhcHByb2FjaCBmb3IgYXV0b21hdGljIHVwZGF0aW5nIG9mIHRoZSBtZWRpYSB0 eXBlIG1hcHBpbmcuICBUaGlzIHdhcyBub3RlZCBpbiBTZWN0aW9uIDYuMSBidXQgaXMgb3RoZXJ3 aXNlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuPC90PgogICAgICAgICAgPHQ+QWRk cmVzc2VkIFRpY2tldCAjMzc3IC0gQWRkZWQgSUFOQSBzZWN0aW9uIHRoYXQgZGVmaW5lcyBhIG5l dyBIVFRQIG1lZGlhIHR5cGUgImFwcGxpY2F0aW9uL2NvYXAtcGF5bG9hZCIgYW5kIGNyZWF0ZWQg bmV3IDx4cmVmIHRhcmdldD0ic2VjLWFwcGxpY2F0aW9uLWNvYXAtcGF5bG9hZCIvPiBvbiBob3cg dG8gdXNlIGl0LjwvdD4KICAgICAgICAgIDx0PkFkZHJlc3NlZCBUaWNrZXQgIzM3NiAtIFVwZGF0 ZWQgVGFibGUgMiAoYW5kIGNvcnJlc3BvbmRpbmcgbm90ZSA3KSB0byBpbmRpY2F0ZSB0aGF0IGEg Q29BUCA0LjA1IChNZXRob2QgTm90IEFsbG93ZWQpIFJlc3BvbnNlIENvZGUgc2hvdWxkIGJlIG1h cHBlZCB0byBhIEhUVFAgNDAwIChCYWQgUmVxdWVzdCkuPC90PgogICAgICAgICAgPHQ+QWRkZWQg bm90ZSB0byBjb21wbHkgdG8gQUJORiB3aGVuIHRyYW5zbGF0aW5nIENvQVAgZGlhZ25vc3RpYyBw YXlsb2FkIHRvIHJlYXNvbi1waHJhc2UgaW4gPHhyZWYgdGFyZ2V0PSJzZWMtZGlhZ25vc3RpYyIv Pi48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CgogICAgICA8dD5DaGFuZ2VzIGZyb20g aWV0Zi0wNSB0byBpZXRmLTA2OgogICAgICAgIDxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAg ICAgIDx0PkZ1bGx5IHJlc3RydWN0dXJlZCB0aGUgZHJhZnQsIGJyaW5naW5nIGludHJvZHVjdG9y eSB0ZXh0IG1vcmUgdG8gdGhlIGZyb250IGFuZCBhbGxvY2F0aW5nIG1haW4gc2VjdGlvbnMgdG8g ZWFjaCBvZiB0aGUga2V5IHRvcGljczsgYWRkcmVzc2luZyBUaWNrZXQgIzM3OTs8L3Q+CiAgICAg ICAgICA8dD5BZGRyZXNzZWQgVGlja2V0ICMzODIsIGZpeCBvZiBlbmhhbmNlZCBmb3JtIFVSSSB0 ZW1wbGF0ZSBkZWZpbml0aW9uIG9mIHEgaW4gU2VjdGlvbiA1LjMuMjs8L3Q+CiAgICAgICAgICA8 dD5BZGRyZXNzZWQgVGlja2V0ICMzODEsIGZvdW5kIGEgbWFwcGluZyA0LjAxIHRvIDQwMSBVbmF1 dGhvcml6ZWQgaW4gU2VjdGlvbiA3OzwvdD4KICAgICAgICAgIDx0PkFkZHJlc3NlZCBUaWNrZXQg IzM4MCAoQWRkIElBTkEgcmVnaXN0cmF0aW9uIGZvciAiY29yZS5oYyIgUmVzb3VyY2UgVHlwZSkg aW4gU2VjdGlvbiA5OzwvdD4KICAgICAgICAgIDx0PkFkZHJlc3NlZCBUaWNrZXQgIzM3NiAoQ29B UCA0LjA1IHJlc3BvbnNlIGNhbid0IGJlIHRyYW5zbGF0ZWQgdG8gSFRUUCA0MDUgYnkgSEMgcHJv eHkpIGluIFNlY3Rpb24gNyBieSB1c2Ugb2YgZW1wdHkgJ0FsbG93JyBoZWFkZXI7PC90PgogICAg ICAgICAgPHQ+UmVtb3ZlZCBkZXRhaWxzIG9uIHRoZSBwcm9zIGFuZCBjb25zIG9mIEhDIHByb3h5 IHBsYWNlbWVudCBvcHRpb25zOzwvdD4KICAgICAgICAgIDx0PkFkZHJlc3NlZCByZXZpZXcgY29t bWVudHMgb2YgQ2Fyc3RlbiBCb3JtYW5uOzwvdD4KICAgICAgICAgIDx0PkNsYXJpZmllZCBmYWls dXJlIGluIG1hcHBpbmcgb2YgSFRUUCBBY2NlcHQgaGVhZGVycyAoU2VjdGlvbiA2LjMpOzwvdD4K ICAgICAgICAgIDx0PkNsYXJpZmllZCBkZXRlY3Rpb24gb2YgQ29BUCBzZXJ2ZXJzIG5vdCBzdXBw b3J0aW5nIGJsb2Nrd2lzZSAoU2VjdGlvbiA4LjMpOzwvdD4KICAgICAgICAgIDx0PkNoYW5nZWQg Q29BUCByZXF1ZXN0IHRpbWVvdXQgbWluIHZhbHVlIHRvIE1BWF9SVFQgKyBNQVhfU0VSVkVSX1JF U1BPTlNFX0RFTEFZIChTZWN0aW9uIDguNik7PC90PgogICAgICAgICAgPHQ+QWRkZWQgc2VjdXJp dHkgc2VjdGlvbiBpdGVtIChTZWN0aW9uIDEwLjMpIHJlbGF0ZWQgdG8gdXNlIG9mIENvQVAgYmxv Y2t3aXNlIHRyYW5zZmVyczs8L3Q+CiAgICAgICAgICA8dD5NYW55IGVkaXRvcmlhbCBpbXByb3Zl bWVudHMuPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+Q2hhbmdlcyBm cm9tIGlldGYtMDQgdG8gaWV0Zi0wNToKICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAg ICAgICAgICA8dD5BZGRyZXNzZWQgVGlja2V0ICMzNjYgKE1hcHBpbmcgb2YgQ29SRSBMaW5rIEZv cm1hdCBwYXlsb2FkcyB0byBiZSB2YWxpZCBpbiBIVFRQIERvbWFpbj8pIGluIFNlY3Rpb24gNi4z LjMuMiAoQ29udGVudCBUcmFuc2NvZGluZyAtIENPUkUgTGluayBGb3JtYXQpOzwvdD4KICAgICAg ICAgIDx0PkFkZHJlc3NlZCBUaWNrZXQgIzM3NSAoQWRkIHJlcXVpcmVtZW50IG9uIG1hcHBpbmcg b2YgQ29BUCBkaWFnbm9zdGljIHBheWxvYWQpIGluIFNlY3Rpb24gNi4zLjMuMyAoQ29udGVudCBU cmFuc2NvZGluZyAtIERpYWdub3N0aWMgTWVzc2FnZXMpOzwvdD4KICAgICAgICAgIDx0PkFkZHJl c3NlZCBjb21tZW50IGZyb20gWXVzdWtlIChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvY29yZS9jdXJyZW50L21zZzA1NDkxLmh0bWwpIGluIFNlY3Rpb24gNi4zLjMuMSAoQ29u dGVudCBUcmFuc2NvZGluZyAtIEdlbmVyYWwpOzwvdD4KICAgICAgICAgIDx0PlZhcmlvdXMgZWRp dG9yaWFsIGltcHJvdmVtZW50cy48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CgogICAg ICA8dD5DaGFuZ2VzIGZyb20gaWV0Zi0wMyB0byBpZXRmLTA0OgogICAgICAgIDxsaXN0IHN0eWxl PSJzeW1ib2xzIj4KICAgICAgICAgIDx0PkV4cGFuZGVkIHVzZSBjYXNlIGRlc2NyaXB0aW9ucyBp biBTZWN0aW9uIDQ7PC90PgogICAgICAgICAgPHQ+Rml4ZWQvZW5oYW5jZWQgZGlzY292ZXJ5IGV4 YW1wbGVzIGluIFNlY3Rpb24gNS40LjE7PC90PgogICAgICAgICAgPHQ+QWRkcmVzc2VkIFRpY2tl dCAjMzY1IChBZGQgdGV4dCBvbiBtZWRpYSB0eXBlIGNvbnZlcnNpb24gYnkgSFRUUC1Db0FQIHBy b3h5KSBpbiBuZXcgU2VjdGlvbiA2LjMuMSAoR2VuZXJhbGl6ZWQgbWVkaWEgdHlwZSBtYXBwaW5n KSBhbmQgbmV3IFNlY3Rpb24gNi4zLjIgKENvbnRlbnQgdHJhbnNsYXRpb24pOzwvdD4KICAgICAg ICAgIDx0PlVwZGF0ZWQgSFRUUEJpcyBXRyBkcmFmdCByZWZlcmVuY2VzIHRvIHJlY2VudGx5IHB1 Ymxpc2hlZCBSRkMgbnVtYmVycy48L3Q+CiAgICAgICAgICA8dD5WYXJpb3VzIGVkaXRvcmlhbCBp bXByb3ZlbWVudHMuPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+Q2hh bmdlcyBmcm9tIGlldGYtMDIgdG8gaWV0Zi0wMzoKICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9s cyI+CiAgICAgICAgICA8dD5DbG9zZWQgVGlja2V0ICMzNTEgIkFkZCBzZWN1cml0eSBpbXBsaWNh dGlvbnMgb2YgcHJvcG9zZWQgZGVmYXVsdCBIVFRQLUNvQVAgVVJJIG1hcHBpbmciOzwvdD4KICAg ICAgICAgIDx0PkNsb3NlZCBUaWNrZXQgIzM2MyAiUmVtb3ZlIENvQVAgc2NoZW1lIGluIGRlZmF1 bHQgSFRUUC1Db0FQIFVSSSBtYXBwaW5nIjs8L3Q+CiAgICAgICAgICA8dD5DbG9zZWQgVGlja2V0 ICMzNjQgICJBZGQgZGlzY292ZXJ5IG9mIEhUVFAtQ29BUCBtYXBwaW5nIHJlc291cmNlKHMpIi48 L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CgogICAgICA8dD5DaGFuZ2VzIGZyb20gaWV0 Zi0wMSB0byBpZXRmLTAyOgogICAgICAgIDxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAg IDx0PlNlbGVjdGlvbiBvZiBzaW5nbGUgZGVmYXVsdCBVUkkgbWFwcGluZyBwcm9wb3NhbCBhcyBw cm9wb3NlZCB0byBXRyBtYWlsaW5nIGxpc3QgMjAxMy0xMC0wOS48L3Q+CiAgICAgICAgPC9saXN0 PgogICAgICA8L3Q+CgogICAgICA8dD5DaGFuZ2VzIGZyb20gaWV0Zi0wMCB0byBpZXRmLTAxOgog ICAgICAgIDxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PkFkZGVkIFVSSSBtYXBw aW5nIHByb3Bvc2FscyB0byBTZWN0aW9uIDQgYXMgcGVyIHRoZSBFbWFpbCBwcm9wb3NhbHMgdG8g V0cgbWFpbGluZyBsaXN0IGZyb20gRXNrby48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+ CiAgICA8L3NlY3Rpb24+CiAgPC9iYWNrPgo8L3JmYz4KPCEtLSBMb2NhbFdvcmRzOiB4cmVmIENE QVRBIGV4cGxvZGVycyBCVUEgLS0+Cg== --_002_D3B4FA5B6E2D1thomasfossatialcatellucentcom_-- From nobody Wed Jul 20 01:55:42 2016 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 C5F1912D0B8 for ; Wed, 20 Jul 2016 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 DYT3jZvQ6ZuW for ; Wed, 20 Jul 2016 01:55:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 033F312B061 for ; Wed, 20 Jul 2016 01:55:38 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 938B81D85BFD0; Wed, 20 Jul 2016 08:55:35 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6K8tb0S008658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2016 08:55:37 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6K8tOIV003306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Jul 2016 10:55:36 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 20 Jul 2016 10:55:24 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) Thread-Index: AQHR4NhAO3WSUM7yWUK2lnZ7h2obv6AfsQuAgABBZACAADxAAIAAx8OA Date: Wed, 20 Jul 2016 08:55:24 +0000 Message-ID: References: <20160718003849.GC19248@hephaistos.amsuess.com> <20160718090615.GB12256@hephaistos.amsuess.com> <20160719143043.GC26784@hephaistos.amsuess.com> <20160719220024.GD7974@hephaistos.amsuess.com> In-Reply-To: <20160719220024.GD7974@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] anchor for http hc in coap (was: Re: draft-ietf-core-http-mapping-12) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 08:55:41 -0000 On 19/07/2016 23:00, "Christian Ams=FCss" wrote: >On Tue, Jul 19, 2016 at 05:24:49PM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> I've found the missing piece :-) >>=20 >> RFC6690 Section 2.2 says the following about the "hosts" relationship: >> "The target URI MUST be a relative URI of the context URI for this >> relation type." > >Good catch, I would have missed that. > >As the language in the section is not strong ("the link [...] needs an >explicit anchor" instead of "MUST be anchored"), I think this issue is >closed. Good. From nobody Wed Jul 20 03:17:35 2016 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 D284612D58E for ; Wed, 20 Jul 2016 03:17:32 -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 yrVbylDopU2W for ; Wed, 20 Jul 2016 03:17:31 -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 04BA812D0A5 for ; Wed, 20 Jul 2016 03:17:29 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id AD6BB42F19; Wed, 20 Jul 2016 12:17:27 +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 1355B4A; Wed, 20 Jul 2016 12:17:26 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8DF5744; Wed, 20 Jul 2016 12:17:25 +0200 (CEST) Received: (nullmailer pid 10536 invoked by uid 1000); Wed, 20 Jul 2016 10:17:23 -0000 Date: Wed, 20 Jul 2016 12:17:23 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160720101723.GI7974@hephaistos.amsuess.com> References: <20160719151717.GD26784@hephaistos.amsuess.com> <20160719215027.GE26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BFVE2HhgxTpCzM8t" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 10:17:33 -0000 --BFVE2HhgxTpCzM8t Content-Type: multipart/mixed; boundary="yr/DzoowOgTDcSCF" Content-Disposition: inline --yr/DzoowOgTDcSCF Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 08:54:34AM +0000, Fossati, Thomas (Nokia - GB) wrot= e: > Excellent. I've attached my working copy. You hold the edit lock now. Attached, you'll find my modified version; thereby returning the edit lock to you. The bulk examples now all use the /hc/ Proxy URI like the intro examples, often producing a /hc/?foo=3D pattern in the Hosting HTTP URI (which may not be fully widespread but is neither wrong nor bad). Only one example would have ended up with a double slash, so another path component was introduced in the Mapping Template (/hc/ + forward/{+tu}), otherwise the example would become completely moot (dropping it would be an option too IMO). During writing I've utilized the xml2rfc tool to generate HTML previews, and noted that in 5.4.1.1, the enumerated example headlines did appear below the example blocks. This might be a bug only in the xml2rfc version I'm using, but you might want to have a brief look at if it works for you. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --yr/DzoowOgTDcSCF Content-Type: application/xml Content-Disposition: attachment; filename="draft-ietf-core-http-mapping-13.xml" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A<= !ENTITY RFC7641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference= =2ERFC.7641.xml">=0A=0A=0A=0A]>=0A=0A=0A=0A<= ?rfc tocdepth=3D"3"?>=0A=0A= =0A=0A=0A=0A <= front>=0A =0A Guidelines for = HTTP-to-CoAP Mapping Implementations=0A =0A =0A = University of Padova=0A
=0A = =0A Via Gradenigo 6/B=0A 35131=0A Padova=0A Italy<= /country>=0A =0A angelo@castellani.net=0A
=0A =0A =0A Ericsson=0A
=0A =0A Hirs= alantie 11=0A 02420=0A Jorvas= =0A Finland=0A =0A = salvatore.loreto@ericsson.com=0A
=0A =0A =0A InterDigital Communications, LLC=0A
=0A =0A 1000 Sherbrooke= Street West=0A Montreal=0A H= 3A 3G4=0A Canada=0A =0A = +1 514 585 0761=0A Akbar.Rahman@InterDi= gital.com=0A
=0A =0A =0A Nokia=0A
=0A =0A <= street>3 Ely Road=0A Milton, Cambridge=0A = CB24 6DD=0A UK=0A =0A thomas.fossati@nokia.com=0A =0A =0A =0A Philips Lighting=0A =
=0A =0A High Tech Campus 34=0A Eindhoven=0A 5656 AE= =0A The Netherlands=0A =0A = esko.dijk@philips.com=0A
=0A = =0A =0A APP=0A CoRE W= orking Group=0A CoAP=0A HTTP-= CoAP mapping=0A HTTP-CoAP translation=0A = proxy implementation=0A =0A This d= ocument provides reference information for implementing a cross-protocol ne= twork proxy that performs translation from the HTTP protocol to the CoAP pr= otocol. This will enable a HTTP client to access resources on a CoAP serve= r through the proxy. This document describes how a HTTP request is mapped = to a CoAP request, and then how a CoAP response is mapped back to a HTTP re= sponse. This includes guidelines for URI mapping, media type mapping and a= dditional proxy implementation issues. This document covers the Reverse, F= orward and Interception cross-protocol proxy cases.=0A = =0A =0A =0A
=0A <= t>CoAP has been designed with the twofold aim to= be an application protocol specialized for constrained environments and to= be easily used in Representational State Transfer (REST) based architectur= es such as the Web. The latter goal has led to defining CoAP to easily int= eroperate with HTTP through an intermediary prox= y which performs cross-protocol conversion.=0A=0A Section 10 of= describes the fundamentals of the CoAP-to-HTTP = and the HTTP-to-CoAP cross-protocol mapping process. However, focuses on the basic mapping of request methods and simple r= esponse code mapping between HTTP and CoAP, and it leaves many details of t= he cross-protocol proxy for future definition. Therefore, a primary goal o= f this informational document is to define a consistent set of guidelines t= hat an HTTP-to-CoAP proxy implementation should adhere to. The key benefit = to adhering to such guidelines is to reduce variation between proxy impleme= ntations, thereby increasing interoperability between an HTTP client and a = CoAP server independent of the proxy that implements the cross-protocol map= ping. (For example, a proxy conforming to these guidelines made by vendor A= can be easily replaced by a proxy from vendor B that also conforms to the = guidelines.) =0A=0A This document describes HTTP mappings that = apply to protocol elements defined in the base CoAP specification . It is up to CoAP protocol extensions (new methods, resp= onse codes, options, content-formats) to describe their own HTTP mappings, = if applicable.=0A=0A This document is organized as follows:=0A = =0A defines proxy terminology;=0A intr= oduces the HTTP-to-CoAP proxy;=0A lists use cases in which HTTP clients need to contact CoAP servers;= =0A introduces a null, default a= nd advanced HTTP-to-CoAP URI mapping syntax;=0A describes how to map HTTP media types to CoAP content form= ats and vice versa;=0A describes= how to map CoAP responses to HTTP responses;=0A describes additional mapping guidelines related to c= aching, congestion, timeouts, etc.;=0A discusses possible security impact of HTTP-to-CoAP protocol mapping.= =0A =0A =0A
=0A=0A =0A =0A
=0A = The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH= OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL= " in this document are to be interpreted as described in .=0A=0A HC Proxy: a proxy performing a cross-protocol m= apping, in the context of this document an HTTP-to-CoAP (HC) mapping. Speci= fically, the HC proxy acts as an HTTP server and a CoAP client. The HC Pro= xy can take on the role of a Forward, Reverse or Interception Proxy.=0A= =0A Forward Proxy (or Forward HC Proxy): a message forwarding agent= that is selected by the HTTP client, usually via local configuration rules= , to receive requests for some type(s) of absolute URI and to attempt to sa= tisfy those requests via translation to the protocol indicated by the absol= ute URI. The user decides (is willing) to use the proxy as the forwarding/= de-referencing agent for a predefined subset of the URI space. In this is called a Proxy. defin= es Forward-Proxy similarly.=0A=0A Reverse Proxy (or Reverse HC = Proxy): as in , a receiving agent that acts as a = layer above some other server(s) and translates the received requests to th= e underlying server's protocol. A Reverse HC Proxy behaves as an origin (H= TTP) server on its connection from the HTTP client. The HTTP client uses t= he "origin-form" (Section 5.3.1 of ) as a request= -target URI.=0A=0A Interception Proxy (or Interception HC Proxy= ) : a proxy that receives inbound HTTP traffic fl= ows through the process of traffic redirection; transparent to the HTTP cli= ent.=0A=0A Note that a Reverse Proxy appears to an HTTP client = as an origin server while a Forward Proxy does not. So, when communicating = with a Reverse Proxy a client may be unaware it is communicating with a pro= xy at all.=0A
=0A=0A =0A =0A A HC proxy is = accessed by an HTTP client which wants to access a resource on a CoAP serve= r. The HC proxy handles the HTTP request by mapping it to the equivalent C= oAP request, which is then forwarded to the appropriate CoAP server. The r= eceived CoAP response is then mapped to an appropriate HTTP response and fi= nally sent back to the originating HTTP client.=0A=0A =0A=0A See for an example deployment scenario. Here a HC proxy is loca= ted at the boundary of the Constrained Network domain, to avoid sending any= HTTP traffic into the Constrained Network and to avoid any (unsecured) CoA= P multicast traffic outside the Constrained Network. A DNS server (not sho= wn) is used by the HTTP Client to resolve the IP address of the HC proxy an= d optionally also used by the HC proxy to resolve IP addresses of CoAP serv= ers.=0A=0A
=0A =0A = |H= TTP-to-CoAP|----------->| CoAP | ||=0A | Client |<----------------| Pr= oxy |<-----------|Server| ||=0A '--------' HTTP Response '---------= ---' CoAP Resp '------' ||=0A || = ||=0A || .--= ----. ||=0A || | CoAP = | ||=0A \ |server| .= ------. /=0A \ '------' | CoAP= | /=0A \ |server| /= =0A \ '------' /=0A = '-----------------'=0A ]]= >=0A =0A
=0A=0A=0A Normative req= uirements on the translation of HTTP requests to CoAP requests and of the C= oAP responses back to HTTP responses are defined in Section 10.2 of . However, focuses on the ba= sic mapping of request methods and simple response code mapping between HTT= P and CoAP, and leaves many details of the cross-protocol HC proxy for futu= re definition. This document provides additional guidelines and more detai= ls for the implementation of a HC Proxy, which should be followed in additi= on to the normative requirements. Note that the guidelines apply to all for= ms of an HC proxy (i.e. Reverse, Forward, Intercepting) unless explicitly o= therwise noted.=0A =0A=0A=0A =0A
=0A To illustrate the situations HTTP to CoAP prot= ocol translation may be used, three use cases are described below.=0A= =0A 1. Legacy building control application without CoAP: A building= control application that uses HTTP but not CoAP can check the status of Co= AP sensors and/or control actuators via a HC proxy.=0A=0A 2. Ma= king sensor data available to 3rd parties on the Web: For demonstration or = public interest purposes, a HC proxy may be configured to expose the conten= ts of a CoAP sensor to the world via the web (HTTP and/or HTTPS). Some sen= sors may only accept secure 'coaps' requests, therefore the proxy is config= ured to translate request to those devices accordingly. The HC proxy is fu= rthermore configured to only pass through GET requests in order to protect = the constrained network.=0A=0A 3. Smartphone and home sensor: A sm= artphone can access directly a CoAP home sensor using a mutually authentica= ted 'https' request, provided its home router runs a HC proxy and is config= ured with the appropriate certificate. An HTML5 application on the smartph= one can provide a friendly UI using the standard (HTTP) networking function= s of HTML5.=0A=0A A key point in the above use cases is the expect= ed nature of the URI to be used by the HTTP client initiating the HTTP requ= est to the HC proxy. Specifically, in use case #1, there will be no "coap"= or "coaps" related information embedded in the HTTP URI as it is a legacy = HTTP client sending the request. Use case #2 is also expected to be similar= =2E In contrast, in use case #3, it is expected that the HTTP client will = specifically embed "coap" or "coaps" related information in the HTTP URI of= the HTTP request to the HC proxy.=0A=0A
=0A=0A =0A
=0A Though, in principle, = a CoAP URI could be directly used by a HTTP client to de-reference a CoAP r= esource through a HC proxy, the reality is that all major web browsers, net= working libraries and command line tools do not allow making HTTP requests = using URIs with a scheme "coap" or "coaps".=0A=0A Thus, there i= s a need for web applications to embed or "pack" a CoAP URI into a HTTP URI= so that it can be (non-destructively) transported from the HTTP client to = the HC proxy. The HC proxy can then "unpack" the CoAP URI and finally de-r= eference it via a CoAP request to the target Server.=0A=0A URI = Mapping is the term used in the document to describe the process through wh= ich the URI of a CoAP resource is transformed into an HTTP URI so that:=0A = =0A the requesting HTTP client c= an handle it;=0A the receiving HC proxy can extract the int= ended CoAP URI unambiguously.=0A =0A =0A=0A = To this end, the remainder of this section will identify:=0A =0A the default mechanism to map a CoAP UR= I into a HTTP URI;=0A the URI template format to express a = class of CoAP-HTTP URI mapping functions;=0A the discovery = mechanism based on CoRE Link Format through whic= h clients of a HC proxy can dynamically discover information about the supp= orted URI Mapping Template(s), as well as the URI where the HC proxy functi= on is anchored.=0A =0A =0A=0A
=0A In the remainder of this section, the f= ollowing terms will be used with a distinctive meaning:=0A =0A URI which refers to the HC proxy function. It conforms to syn= tax defined in Section 2.7 of .=0A = URI which refers to the (final) = CoAP resource that has to be de-referenced. It conforms to syntax defined = in Section 6 of . Specifically, its scheme is ei= ther "coap" or "coaps".=0A URI that conforms to syntax in Section 2.7 of . Its authority component refers to a HC proxy, whereas path (and q= uery) component(s) embed the information used by a HC proxy to extract the = Target CoAP URI.=0A =0A =0A
= =0A=0A
=0A The null mapping is the case where there is no Target CoAP U= RI appended to the HC Proxy URI. In other words, it is a "pure" HTTP URI t= hat is sent to the HC Proxy. This would typically occur in situations like= Use Case #1 described in , and the Proxy would = typically be a Reverse Proxy. In this scenario, the HC Proxy will determine= through its own proprietary algorithms what the Target CoAP URI should be.= =0A
=0A=0A
=0A The default mapping is for the = Target CoAP URI to be appended as-is to the HC Proxy URI, to form the Hosti= ng HTTP URI. This is the URI that will then be sent by the HTTP client in = the HTTP request to the HC proxy.=0A=0A For example: given a = HC Proxy URI http://p.example.com/hc/ and a Target CoAP URI coap://s.exampl= e.com/light, the resulting Hosting HTTP URI would be http://p.example.com/h= c/coap://s.example.com/light.=0A=0A Provided a correct Target= CoAP URI, the Hosting HTTP URI resulting from the default mapping is alway= s syntactically correct. Furthermore, the Target CoAP URI can always be ex= tracted unambiguously from the Hosting HTTP URI. Also, it is worth noting = that, using the default mapping, a query component in the target CoAP resou= rce URI is naturally encoded into the query component of the Hosting URI, e= =2Eg.: coap://s.example.com/light?dim=3D5 becomes http://p.example.com/hc/c= oap://s.example.com/light?dim=3D5.=0A=0A There is no default = for the HC Proxy URI. Therefore, it is either known in advance, e.g. as a = configuration preset, or dynamically discovered using the mechanism describ= ed in .=0A=0A The default= URI mapping function SHOULD be implemented and activated by default in a H= C proxy, unless there are valid reasons, e.g. application specific, to use = a different mapping function.=0A=0A
=0A When fou= nd in a Hosting HTTP URI, the scheme (i.e., "coap" or "coaps"), the scheme = component delimiter (":"), and the double slash ("//") preceding the author= ity MAY be omitted. In such case, a local default - not defined by this do= cument - applies.=0A=0A So, http://p.example.com/hc/s.coap.= example.com/foo could either represent the target coap://s.coap.example.com= /foo or coaps://s.coap.example.com/foo depending on application specific pr= esets.=0A
=0A=0A =0A = When the authority of the Target CoAP URI is given as an IPv6addres= s, then the surrounding square brackets must be percent-encoded in the Host= ing HTTP URI, in order to comply with the syntax defined in Section 3.3. of= for a URI path segment. E.g.: coap://[2001:db8= ::1]/light?on becomes http://p.example.com/hc/coap://%5B2001:db8::1%5D/ligh= t?on.=0A Everything else can be safely copied verbatim from= the Target CoAP URI to the Hosting HTTP URI.=0A
=0A
=0A=0A =
=0A This section define= s a format for the URI template used by a HC pro= xy to inform its clients about the expected syntax for the Hosting HTTP URI= =2E This will then be used by the HTTP client to construct the URI to be s= ent in the HTTP request to the HC proxy.=0A=0A When instantia= ted, an URI Mapping Template is always concatenated to a HC Proxy URI provi= ded by the HC proxy via discovery (see = ), or by other means.=0A=0A A simple form () and an enhanced form () are provided to fit different users' requirements.=0A=0A = Both forms are expressed as level 2 URI templates to take care of the expansion of values that are allowed to includ= e reserved URI characters. The syntax of all URI formats is specified in t= his section in Augmented Backus-Naur Form (ABNF) = =2E=0A=0A
=0A The simple form MUST be used for mappings where the= Target CoAP URI is going to be copied (using rules of ) at some fixed position into the Hosting HTTP URI.<= /t>=0A=0A The "tu" template variable is intended to be used in = a template definition to represent a Target CoAP URI:=0A =0A =0A tu =3D coap-URI / coaps-URI ; from [RFC7= 252], Section 6.1 and 6.2=0A =0A =0A The same considerations as in apply, in that the CoAP scheme may be omitted from the Hosting = HTTP URI.=0A=0A
=0A All the= following examples (given as a specific URI mapping template, a Target CoA= P URI, and the produced Hosting HTTP URI) use http://p.example.com/hc/ as t= he HC Proxy URI. Note that these examples all define mapping templates tha= t deviate from the default template of to be able to illustrate the use of the above template variables.=0A =0A =0A = Target CoAP URI is a query argument of the Hosting HTTP URI:=0A =
=0A =0A = =0A <= /artwork>=0A
=0A =0A=0A = Target CoAP URI in the path component of the Hosting HTTP URI:= =0A
=0A =0A = =0A = =0A
=0A =0A=0A = "coap" URI is a query argument of the Hosting HTTP URI; client decides t= o omit scheme because a default scheme is agreed beforehand between client = and proxy:=0A
=0A =0A = =0A =0A =
=0A =0A =0A = =0A
=0A
=0A=0A
=0A The enhanced form can be used to express more = sophisticated mappings of the Target CoAP URI into the Hosting HTTP URI, i.= e., mappings that do not fit into the simple form.=0A There= MUST be at most one instance of each of the following template variables i= n a template definition:=0A
=0A = =0A =0A =0A
=0A = =0A The qq form is used when the path and the (optional)= query components are to be copied verbatim from the Target CoAP URI into t= he Hosting HTTP URI, i.e. as "{+p}{+qq}". Instead, the q form is used when= the query and path are mapped as separate entities, e.g. as in "coap_path= =3D{+p}&coap_query=3D{+q}".=0A=0A
=0A All the following examples (given as a specific URI mapping = template, a Target CoAP URI, and the produced Hosting HTTP URI) use http://= p.example.com/hc/ as the HC Proxy URI.=0A =0A = =0A Target CoAP URI components = in path segments, and optional query in query component:=0A =
=0A =0A =0A =0A =
=0A =0A=0A Tar= get CoAP URI components split in individual query arguments:=0A =
=0A =0A =0A =0A =
=0A =0A =0A = =0A
=0A
=0A
=0A=0A =
=0A In = order to accommodate site specific needs while allowing third parties to di= scover the proxy function, the HC proxy SHOULD publish information related = to the location and syntax of the HC proxy function using the CoRE Link For= mat interface.=0A=0A To this aim a= new Resource Type, "core.hc", is defined in this document. It can be used = as the value for the "rt" attribute in a query to the /.well-known/core in = order to locate the URI where the HC proxy function is anchored, i.e. the H= C Proxy URI.=0A =0A Along with it, the new target attribute = "hct" is defined in this document. This attribute MAY be returned in a "cor= e.hc" link to provide the URI Mapping Template associated to the mapping re= source. The default template given in , i.e., {+tu}, MUST be assumed if no "hct" attribute is found in the = returned link. If a "hct" attribute is present in the returned link, then = a client MUST use it to create the Hosting HTTP URI.=0A=0A Th= e URI mapping SHOULD be discoverable (as specified in [RFC6690]) on both th= e HTTP and the CoAP side of the HC proxy, with one important difference: on= the CoAP side the link associated to the "core.hc" resource needs an expli= cit anchor referring to the HTTP origin, while on the HTTP interface the li= nk context is already the HTTP origin carried in the request's Host header,= and doesn't have to be made explicit.=0A=0A=0A
=0A =0A =0A = The first example exercises the CoAP interface, and assumes t= hat the default template, {+tu}, is used. For example, in use case #3 in s= ection , the smartphone may discover the public = HC proxy before leaving the home network. Then when outside the home netwo= rk, the smartphone will be able to query the appropriate home sensor.=0A =
=0A =0A <= ![CDATA[=0A Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.hc=0A= =0A Res: 2.05 Content=0A ;anchor=3D"http://p.example.com= ";rt=3D"core.hc"=0A ]]>=0A = =0A
=0A =0A =0A Th= e second example - also on the CoAP side of the HC proxy - uses a custom te= mplate, i.e., one where the CoAP URI is carried inside the query component,= thus the returned link carries the URI template to be used in an explicit = "hct" attribute:=0A
=0A = =0A ;anchor= =3D"http://p.example.com";=0A rt=3D"core.hc";hct=3D"?uri=3D{+tu}"= =0A ]]>=0A =0A =
=0A =0A =0A=0A On the H= TTP side, link information can be serialized in more than one way:=0A = =0A using the 'application/li= nk-format' content type:=0A
=0A =0A ;rt=3D"core.hc"=0A ]]= >=0A =0A
=0A = =0A =0A using the 'application/link-format+js= on' content type as defined in := =0A
=0A =0A = = =0A =0A
=0A = =0A =0A using the Link header:=0A =0A =0A ;rt=3D"core.hc"= =0A ]]>=0A =0A = =0A =0A =0A =0A =
=0A
=0A= =0A=0A=0A =0A
=0A
=0A A HC proxy needs to translate HTTP media types (Section 3.1.1.1 of ) and content encodings (Section 3.1.2.2 of ) into CoAP content formats (Section 12.3 of ) and vice versa.=0A Media type translation can hap= pen in GET, PUT or POST requests going from HTTP to CoAP, and in 2.xx (i.e.= , successful) responses going from CoAP to HTTP. Specifically, PUT and POS= T need to map both the Content-Type and Content-Encoding HTTP headers into = a single CoAP Content-Format option, whereas GET needs to map Accept and Ac= cept-Encoding HTTP headers into a single CoAP Accept option. To generate t= he HTTP response, the CoAP Content-Format option is mapped back to a suitab= le HTTP Content-Type and Content-Encoding combination.=0A=0A = An HTTP request carrying a Content-Type and Content-Encoding combination wh= ich the HC proxy is unable to map to an equivalent CoAP Content-Format, SHA= LL elicit a 415 (Unsupported Media Type) response by the HC proxy.=0A= =0A On the content negotiation side, failure to map Accept and Ac= cept-* headers SHOULD be silently ignored: the HC proxy SHOULD therefore fo= rward as a CoAP request with no Accept option. The HC proxy thus disregard= s the Accept/Accept-* header fields by treating the response as if it is no= t subject to content negotiation, as mentioned in Sections 5.3.* of . However, a HC proxy implementation is free to attempt= mapping a single Accept header in a GET request to multiple CoAP GET reque= sts, each with a single Accept option, which are then tried in sequence unt= il one succeeds. Note that an HTTP Accept */* MUST be mapped to a CoAP req= uest without Accept option.=0A=0A While the CoAP to HTTP dire= ction has always a well defined mapping (with the exception examined in ), the HTTP to CoAP direction i= s more problematic because the source set, i.e., potentially 1000+ IANA reg= istered media types, is much bigger than the destination set, i.e., the mer= e 6 values initially defined in Section 12.3 of .= =0A=0A Depending on the tight/loose coupling with the applica= tion(s) for which it proxies, the HC proxy could implement different media = type mappings.=0A=0A When tightly coupled, the HC proxy knows= exactly which content formats are supported by the applications, and can b= e strict when enforcing its forwarding policies in general, and the media t= ype mapping in particular.=0A=0A On the other side, when the = HC proxy is a general purpose application layer gateway, being too strict c= ould significantly reduce the amount of traffic that it would be able to su= ccessfully forward. In this case, the "loose" media type mapping detailed = in MAY be implemented.=0A=0A = =0A The latter grants m= ore evolution of the surrounding ecosystem, at the cost of allowing more at= tack surface. In fact, as a result of such strategy, payloads would be for= warded more liberally across the unconstrained/constrained network boundary= of the communication path. Therefore, when applied, other forms of access= control must be set in place to avoid unauthorized users to deplete or abu= se systems and network resources.=0A
= =0A=0A
=0A If the HC proxy receives a = CoAP response with a Content-Format that it does not recognize (e.g. becaus= e the value has been registered after the proxy has been deployed, or the C= oAP server uses an experimental value which is not registered), then the HC= proxy SHALL return a generic "application/coap-payload" media type with nu= meric parameter "cf" as defined in .= =0A=0A For example, the CoAP content format '60' ("applicatio= n/cbor") would be represented by "application/coap-payload;cf=3D60", if the= HC Proxy doesn't recognize the content format '60'.=0A=0A A = HTTP client may use the media type "application/coap-payload" as a means to= send a specific content format to a CoAP server via a HC Proxy if the clie= nt has determined that the HC Proxy does not directly support the type mapp= ing it needs. This case may happen when dealing for example with newly regi= stered, yet to be registered, or experimental CoAP content formats.=0A =
=0A=0A <= section title=3D"Loose Media Type Mapping" anchor=3D"sec-loose-mt-mapping">= =0A By structuring the type information in a super-class (e.g. "t= ext") followed by a finer grained sub-class (e.g. "html"), and optional par= ameters (e.g. "charset=3Dutf-8"), Internet media types provide a rich and s= calable framework for encoding the type of any given entity.=0A=0A = This approach is not applicable to CoAP, where Content Formats confla= te an Internet media type (potentially with specific parameters) and a cont= ent encoding into one small integer value.=0A=0A To remedy th= is loss of flexibility, we introduce the concept of a "loose" media type ma= pping, where media types that are specializations of a more generic media t= ype can be aliased to their super-class and then mapped (if possible) to on= e of the CoAP content formats. For example, "application/soap+xml" can be = aliased to "application/xml", which has a known conversion to CoAP. In the= context of this "loose" media type mapping, "application/octet-stream" can= be used as a fallback when no better alias is found for a specific media t= ype.=0A=0A defines the = default lookup table for the "loose" media type mapping. Given an input me= dia type, the table returns its best generalized media type using the most = specific match i.e. the table entries are compared to the input in top to b= ottom order until an entry matches.=0A=0A =0A = Internet media type=0A Generalized media type=0A application/*+= xml=0A application/xml=0A application/*+jso= n=0A application/json=0A text/xml=0A = application/xml=0A text/*=0A text= /plain=0A */*=0A application/octet-stream=0A =0A The "loose" media type mapping is an= OPTIONAL feature. Implementations supporting this kind of mapping should = provide a flexible way to define the set of media type generalizations allo= wed.=0A
=0A=0A <= section title=3D"Media Type to Content Format Mapping Algorithm" anchor=3D"= sec-mt2cf">=0A This section defines the algorithm used to map an = HTTP Internet media type to its correspondent CoAP content format.=0A= =0A The algorithm uses the mapping table defined in Section 12.3 = of plus, possibly, any locally defined extension= of it. Optionally, the table and lookup mechanism described in can be used if the implementation chooses so.= =0A=0A Note that the algorithm may have side effects on the a= ssociated representation (see also ).=0A=0A In the following:=0A = =0A C-T, C-E, and C-F stand for the values of the Content-Typ= e (or Accept) HTTP header, Content-Encoding (or Accept-Encoding) HTTP heade= r, and Content-Format CoAP option respectively.=0A If C-E= is not given it is assumed to be "identity".=0A MAP is t= he mandatory lookup table, GMAP is the optional generalized table.=0A = =0A =0A
=0A = =0A INPUT: C-T and C-E=0A OUTPUT: C-F or Fa= il=0A=0A 1. if no C-T: return Fail=0A 2. C-F =3D MAP[C-T, C= -E]=0A 3. if C-F is not None: return C-F=0A 4. if C-E is no= t "identity":=0A 5. if C-E is supported (e.g. gzip):=0A 6.= decode the representation accordingly=0A 7. set C-E to "i= dentity"=0A 8. else:=0A 9. return Fail=0A 10. = repeat steps 2. and 3.=0A 11. if C-T allows a non-lossy transformati= on into \=0A 12. one of the supported C-F:=0A 13. tra= nscode the representation accordingly=0A 14. return C-F=0A = 15. if GMAP is defined:=0A 16. C-F =3D GMAP[C-T]=0A 17. = if C-F is not None: return C-F=0A 18. return Fail=0A =0A
=0A =0A =0A =0A=0A
=0A
=0A Payload content transcoding (e.g. see step= s 11-14 of ) is an OPTIONAL feature. Implement= ations supporting this feature should provide a flexible way to define the = set of transcodings allowed.=0A=0A As noted in , the process of mapping the media type can have side effec= ts on the forwarded entity body. This may be caused by the removal or addi= tion of a specific content encoding, or because the HC proxy decides to tra= nscode the representation to a different (compatible) format. The latter p= roves useful when an optimized version of a specific format exists. For ex= ample an XML-encoded resource could be transcoded to Efficient XML Intercha= nge (EXI) format, or a JSON-encoded resource into CBOR , effectively achieving compression without losing any information.=0A=0A However, it should be noted that in certain cases, tra= nscoding can lose information in a non-obvious manner. For example, encodi= ng an XML document using schema-informed EXI encoding leads to a loss of in= formation when the destination does not know the exact schema version used = by the encoder, which means that whenever the HC proxy transcodes an applic= ation/XML to application/EXI in-band metadata could be lost. Therefore, th= e implementer should always carefully verify such lossy payload transformat= ions before triggering the transcoding.=0A
=0A=0A
=0A Th= e CoRE Link Format is a set of links (i.e., URIs= and their formal relationships) which is carried as content payload in a C= oAP response. These links usually include CoAP URIs that might be translat= ed by the HC proxy to the correspondent HTTP URIs using the implemented URI= mapping function (see ). Such a process wou= ld inspect the forwarded traffic and attempt to re-write the body of resour= ces with an application/link-format media type, mapping the embedded CoAP U= RIs to their HTTP counterparts. Some potential issues with this approach a= re:=0A =0A The client ma= y be interested to retrieve original (unaltered) CoAP payloads through the = HC proxy, not modified versions.=0A Tampering with payl= oads is incompatible with resources that are integrity protected (although = this is a problem with transcoding in general).=0A The = HC proxy needs to fully understand syntax and se= mantics, otherwise there is an inherent risk to corrupt the payloads.= =0A =0A Therefore, CoRE Link Format payload sh= ould only be transcoded at the risk and discretion of the proxy implementer= =2E=0A
=0A=0A =0A = CoAP responses may, in certain error cases, contain a diagnostic message in= the payload explaining the error situation, as described in Section 5.5.2 = of . If present, the CoAP response diagnostic pa= yload SHOULD be copied in the HTTP response body. The CoAP diagnostic mess= age MUST NOT be copied into the HTTP reason-phrase, since it potentially co= ntains CR-LF characters which are incompatible with HTTP reason-phrase synt= ax.=0A
=0A =0A = =0A
=0A = defines the HTTP response status codes= to which each CoAP response code SHOULD be mapped. Multiple appearances o= f a HTTP status code in the second column indicates multiple equivalent HTT= P responses are possible based on the same CoAP response code, depending on= the conditions cited in the Notes (third column and text below table).= =0A=0A =0A CoAP Response Code= =0A HTTP Status Code=0A Notes=0A 2.01 Created = =0A 201 Created =0A 1=0A = 2.02 Deleted =0A 200 OK = =0A 2=0A =0A= 204 No Content =0A 2=0A 2.03 Valid =0A 304 Not Modified = =0A 3=0A =0A = 200 OK =0A 4=0A 2.= 04 Changed =0A 200 OK =0A 2=0A =0A = 204 No Content =0A 2=0A 2.05 = Content =0A 200 OK = =0A =0A 4.00 Bad Request =0A = 400 Bad Request =0A =0A 4.01 U= nauthorized =0A 403 Forbidden =0A= 5=0A 4.02 Bad Option =0A 400 Bad Request =0A 6=0A 4.02 Bad = Option =0A 500 Internal Server Error =0A = 6=0A 4.03 Forbidden =0A 40= 3 Forbidden =0A =0A 4.04 Not Fou= nd =0A 404 Not Found =0A = =0A 4.05 Method Not Allowed =0A 400 B= ad Request =0A 7=0A 4.06 Not Accept= able =0A 406 Not Acceptable =0A <= c> =0A 4.12 Precondition Failed =0A 412 Prec= ondition Failed =0A =0A 4.13 Request Ent. = Too Large =0A 413 Request Repr. Too Large =0A = =0A 4.15 Unsupported Media Type =0A 415 Unsuppo= rted Media Type =0A =0A 5.00 Internal Server = Error =0A 500 Internal Server Error =0A =0A 5.01 Not Implemented =0A 501 Not Implem= ented =0A =0A 5.02 Bad Gateway = =0A 502 Bad Gateway =0A = =0A 5.03 Service Unavailable =0A 503 Service Una= vailable =0A 8=0A 5.04 Gateway Timeout = =0A 504 Gateway Timeout =0A =0A= 5.05 Proxying Not Supported =0A 502 Bad Gateway = =0A 9=0A =0A Notes:=0A= =0A A CoAP server may return an= arbitrary format payload along with this response. If present, this payloa= d MUST be returned as entity in the HTTP 201 response. Section 7.3.2 of does not put any requirement on the format of the e= ntity. (In the past, did.)=0A=0A The HTTP code is 200 or 204 respectively for the case that a CoAP server r= eturns a payload or not. Section 5.3 requires co= de 200 in case a representation of the action result is returned for DELETE= /POST/PUT, and code 204 if not. Hence, a proxy MUST transfer any CoAP paylo= ad contained in a CoAP 2.02 response to the HTTP client using a 200 OK resp= onse.=0A =0A HTTP code 304 (Not Modified) is sent if the HT= TP client performed a conditional HTTP request and the CoAP server responde= d with 2.03 (Valid) to the corresponding CoAP validation request. Note that= Section 4.1 of puts some requirements on header= fields that must be present in the HTTP 304 response.=0A =0A = A 200 response to a CoAP 2.03 occurs only when the HC proxy, for efficie= ncy reasons, is running a local cache. An unconditional HTTP GET which pro= duces a cache-hit, could trigger a re-validation (i.e. a conditional GET) o= n the CoAP side. The proxy receiving 2.03 updates the freshness of its cac= hed representation and returns it to the HTTP client.=0A =0A <= t>A HTTP 401 Unauthorized (Section 3.1 of ) respo= nse is not applicable because there is no equivalent in CoAP of WWW-Authent= icate which is mandatory in a HTTP 401 response.=0A =0A If = the proxy has a way to determine that the Bad Option is due to the straight= forward mapping of a client request header into a CoAP option, then returni= ng HTTP 400 (Bad Request) is appropriate. In all other cases, the proxy MU= ST return HTTP 500 (Internal Server Error) stating its inability to provide= a suitable translation to the client's request.=0A=0A A Co= AP 4.05 (Method Not Allowed) response SHOULD normally be mapped to a HTTP 4= 00 (Bad Request) code, because the HTTP 405 response would require specifyi= ng the supported methods - which are generally unknown. In this case the H= C Proxy SHOULD also return a HTTP reason-phrase in the HTTP status line tha= t starts with the string "CoAP server returned 4.05" in order to facilitate= troubleshooting. However, if the HC proxy has more granular information a= bout the supported methods for the requested resource (e.g. via a Resource = Directory ()) then it MA= Y send back a HTTP 405 (Method Not Allowed) with a properly filled in "Allo= w" response-header field (Section 7.4.1 of ).= =0A=0A The value of the HTTP "Retry-After" response-header fiel= d is taken from the value of the CoAP Max-Age Option, if present.=0A=0A= This CoAP response can only happen if the proxy itself is conf= igured to use a CoAP forward-proxy (Section 5.7 of ) to execute some, or all, of its CoAP requests.=0A =0A= =0A
=0A=0A =0A
=0A
=0A =0A A HC proxy should cache CoAP resp= onses, and reply whenever applicable with a cached representation of the re= quested resource.=0A=0A =0A=0A If the HTTP client drops = the connection after the HTTP request was made, a HC proxy should wait for = the associated CoAP response and cache it if possible. Subsequent requests= to the HC proxy for the same resource can use the result present in cache,= or, if a response has still to come, the HTTP requests will wait on the op= en CoAP request.=0A=0A According to , a proxy must limit the number of outstanding requests to a given CoAP se= rver to NSTART. To limit the amount of aggregate traffic to a constrained n= etwork, the HC proxy should also put a limit on the number of concurrent Co= AP requests pending on the same constrained network; further incoming reque= sts may either be queued or dropped (returning 503 Service Unavailable). Th= is limit and the proxy queueing/dropping behavior should be configurable.=0A=0A Highly volatile resources that are being frequently requ= ested may be observed by the HC proxy to keep th= eir cached representation fresh while minimizing the amount of CoAP traffic= in the constrained network. See .=0A
=0A=0A <= section title=3D"Cache Refresh via Observe" anchor=3D"refresh_via_observe">= =0A There are cases where using the CoAP observe protocol to handle proxy cache refresh is preferable to the vali= dation mechanism based on ETag as defined in . S= uch scenarios include, but are not limited to, sleepy CoAP nodes -- with po= ssibly high variance in requests' distribution -- which would greatly benef= it from a server driven cache update mechanism. Ideal candidates for CoAP = observe are also crowded or very low throughput networks, where reduction o= f the total number of exchanged messages is an important requirement.= =0A=0A This subsection aims at providing a practical evaluation m= ethod to decide whether refreshing a cached resource R is more efficiently = handled via ETag validation or by establishing an observation on R.=0A= =0A Let T_R be the mean time between two client requests to resou= rce R, let T_C be the mean time between two representation changes of R, an= d let M_R be the mean number of CoAP messages per second exchanged to and f= rom resource R. If we assume that the initial cost for establishing the ob= servation is negligible, an observation on R reduces M_R if and only if T_R= < 2*T_C with respect to using ETag validation, that is if and only if t= he mean arrival rate of requests for resource R is greater than half the ch= ange rate of R.=0A=0A When observing the resource R, M_R is a= lways upper bounded by 2/T_C.=0A
=0A=0A
=0A A HC proxy SHOULD support CoAP blockwise = transfers to allow transport of larg= e CoAP payloads while avoiding excessive link-layer fragmentation in constr= ained networks, and to cope with small datagram buffers in CoAP end-points = as described in Section 4.6.=0A=0A A HC proxy SHOULD attempt to retry a payload-carrying CoAP PUT or POST req= uest with blockwise transfer if the destination CoAP server responded with = 4.13 (Request Entity Too Large) to the original request. A HC proxy SHOULD= attempt to use blockwise transfer when sending a CoAP PUT or POST request = message that is larger than BLOCKWISE_THRESHOLD bytes. The value of BLOCKWI= SE_THRESHOLD is implementation-specific, for example it can be:=0A = =0A calculated based on a known or t= ypical UDP datagram buffer size for CoAP end-points, or=0A <= t>set to N times the known size of a link-layer frame in a constrained netw= ork where e.g. N=3D5, or=0A preset to a known IP MTU valu= e, or=0A set to a known Path MTU value.=0A <= /list>=0A The value BLOCKWISE_THRESHOLD, or the parameters from wh= ich it is calculated, should be configurable in a proxy implementation. The= maximum block size the proxy will attempt to use in CoAP requests should a= lso be configurable.=0A=0A The HC proxy SHOULD detect CoAP en= d-points not supporting blockwise transfers. This can be done by checking = for a 4.02 (Bad Option) response returned by an end-point in response to a = CoAP request with a Block* Option, and subsequent absence of the 4.02 in re= sponse to the same request without Block* Options. This allows the HC prox= y to be more efficient, not attempting repeated blockwise transfers to CoAP= servers that do not support it.=0A=0A
=0A=0A
=0A A HC proxy MAY support CoAP multicast. If = it does, the HC proxy sends out a multicast CoAP request if the Target CoAP= URI's authority is a multicast IP literal or resolves to a multicast IP ad= dress. If the HC proxy does not support CoAP multicast, it SHOULD respond = 403 (Forbidden) to any valid HTTP request that maps to a CoAP multicast req= uest.=0A=0A Details related to supporting CoAP multicast are = currently out of scope of this document since in a proxy scenario a HTTP cl= ient typically expects to receive a single response, not multiple. However= , a HC proxy that implements CoAP multicast may include application-specifi= c functions to aggregate multiple CoAP responses into a single HTTP respons= e. We suggest using the "application/http" internet media type (Section 8.= 3.2 of ) to enclose a set of one or more HTTP res= ponse messages, each representing the mapping of one CoAP response.=0A= =0A For further considerations related to the handling of multica= st requests, see .=0A
= =0A=0A
=0A If the CoAP server takes a long time in respondin= g, the HTTP client or any other proxy in between may timeout. Further disc= ussion of timeouts in HTTP is available in Section 6.2.4 of .=0A=0A A HC proxy MUST define an internal timeout= for each pending CoAP request, because the CoAP server may silently die be= fore completing the request. Assuming the Proxy uses confirmable CoAP requ= ests, such timeout value T SHOULD be at least=0A=0A T =3D MAX= _RTT + MAX_SERVER_RESPONSE_DELAY=0A=0A where MAX_RTT is defin= ed in [RFC7252] and MAX_SERVER_RESPONSE_DELAY is defined in .=0A
=0A=0A = =0A=0A =0A
=0A
=0A This document registers a new Resource = Type (rt=3D) Link Target Attribute, 'core.hc', in the "Resource Type (rt=3D= ) Link Target Attribute Values" subregistry under the "Constrained RESTful = Environments (CoRE) Parameters" registry.=0A=0A Attribute Val= ue: core.hc=0A Description: HTTP to CoAP mapping base resourc= e.=0A Reference: See .=0A
=0A=0A =0A This document defines the "application/coap-payload= " media type with a single parameter "cf". This media type represents any p= ayload that a CoAP message can carry, having a content format that can be i= dentified by a CoAP Content-Format parameter (an integer in range 0-65535).= The parameter "cf" is the integer defining the CoAP content format.= =0A=0A Type name: application=0A Subtype name: coap= -payload=0A=0A Required parameters:=0A cf - CoA= P Content-Format integer in range 0-65535 denoting the content format of th= e CoAP payload carried.=0A=0A Optional parameters: None= =0A=0A Encoding considerations:=0A The specific CoA= P content format encoding considerations for the selected Content-Format (c= f parameter) apply.=0A=0A Security considerations:=0A = The specific CoAP content format security considerations for the sel= ected Content-Format (cf parameter) apply.=0A=0A Interoperabi= lity considerations:=0A Published specification: (this I-D - = TBD)=0A=0A Applications that use this media type:=0A = HTTP-to-CoAP Proxies.=0A=0A Fragment identifier conside= rations: N/A=0A=0A Additional information:=0A =0A Deprecated alias names for this type: N= /A=0A Magic number(s): N/A=0A File exte= nsion(s): N/A=0A Macintosh file type code(s): N/A=0A = =0A =0A=0A Person and email address to= contact for further information:=0A =0A = Esko Dijk ("esko@ieee.org")=0A =0A = =0A Intended usage: COMMON=0A Restrictions on u= sage:=0A An application (or user) can only use this media typ= e if it has to represent a CoAP payload of which the specified CoAP Content= -Format is an unrecognized number; such that a proper translation directly = to the equivalent HTTP media type is not possible.=0A Author:= CoRE WG=0A Change controller: IETF=0A Provisio= nal registration? (standards tree only): N/A=0A
=0A =0A=0A =0A
=0A The security concerns raised in Section 9.2 of [RFC7230] also= apply to the HC proxy scenario.=0A=0A A HC proxy deployed at t= he boundary of a constrained network is an easy single point of failure for= reducing availability. As such, special care should be taken in designing= , developing and operating it, keeping in mind that, in most cases, it has = fewer limitations than the constrained devices it is serving.=0A=0A = The following sub paragraphs categorize and discuss a set of specific = security issues related to the translation, caching and forwarding function= ality exposed by a HC proxy.=0A=0A
=0A Multicast requests impose a non trivial = cost on the constrained network and endpoints, and might be exploited as a = DoS attack vector (see also ). From= a privacy perspective, they can be used to gather detailed information abo= ut the resources hosted in the constrained network. For these reasons, it = is RECOMMENDED that requests to multicast resources are access controlled w= ith a default-deny policy. It is RECOMMENDED that the requestor of a multi= cast resource is strongly authenticated. If privacy is a concern, for exam= ple whenever the HTTP request transits through the public Internet, the req= uest SHOULD be transported over a mutually authenticated and encrypted TLS = connection.=0A
=0A=0A
=0A Du= e to the typically constrained nature of CoAP nodes, particular attention s= hould be given to the implementation of traffic reduction mechanisms (see <= xref target=3D"hc-caching"/>), because inefficient proxy implementations ca= n be targeted by unconstrained Internet attackers. Bandwidth or complexity= involved in such attacks is very low.=0A=0A An amplification= attack to the constrained network may be triggered by a multicast request = generated by a single HTTP request which is mapped to a CoAP multicast reso= urce, as discussed in Section 11.3 of .=0A=0A= The risk likelihood of this amplification technique is higher th= an an amplification attack carried out by a malicious constrained device (e= =2Eg. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a multi= cast destination ), since it does not require dir= ect access to the constrained network.=0A=0A The feasibility = of this attack which disrupts availability of the targeted CoAP server can = be limited by access controlling the exposed multicast resources, so that o= nly known/authorized users can access such URIs.=0A
=0A=0A
=0A An HTTP request can be sent to= the HC proxy over a secured connection. However, there may not always exi= st a secure connection mapping to CoAP. For example, a secure distribution= method for multicast traffic is complex and may not be implemented (see [R= FC7390]).=0A=0A A HC proxy should implement rules for securit= y context translations. For example all "https" unicast requests are trans= lated to "coaps" requests, or "https" requests are translated to unsecured = "coap" requests. Another rule could specify the security policy and parame= ters used for DTLS connections. Such rules will largely depend on the appli= cation and network context in which the HC proxy operates. These rules sho= uld be configurable.=0A=0A It is RECOMMENDED that, by default= , accessing a "coaps" URI is only allowed from a corresponding "https" URI.= =0A=0A By default, a HC proxy SHOULD reject any secured clien= t request if there is no configured security policy mapping. This recommen= dation may be relaxed in case the destination network is believed to be sec= ured by other means. Assuming that CoAP nodes are isolated behind a firewa= ll as in the HC proxy deployment shown in , the HC proxy may be configured to translate the incoming HTTPS = request using plain CoAP (NoSec mode).=0A =0A
=0A=0A
=0A = The following risks related to the URI mapping described in and its use by HC proxies have been identified:=0A= =0A Mitigation: by default deny any = Target CoAP URI whose authority is (or maps to) a multicast address. Then = explicitly white-list multicast resources/authorities that are allowed to b= e de-referenced. See also .=0A = Mitigation: by default deny any Target CoAP URI= (especially /.well-known/core is a resource to be protected), and then exp= licitly white-list resources that are allowed to be seen from outside.= =0A Mitigation: implement a HTTPS-only inte= rface, which makes the Target CoAP URI totally opaque to a passive attacker= =2E=0A =0A =0A
=0A
=0A=0A
=0A = An initial version of in has been provided in revision -05 of the CoRE CoAP I-D. = Special thanks to Peter van der Stok for countless comments and discussions= on this document, that contributed to its current structure and text.= =0A=0A Thanks to=0A Abhijan Bhattacharyya,=0A Brian Frank= ,=0A Carsten Bormann,=0A Christian Amsuss,=0A Christian Grov= es,=0A Cullen Jennings,=0A Dorothy Gellert,=0A Francesco Cor= azza,=0A Hannes Tschofenig,=0A Jaime Jimenez,=0A Kepeng Li,= =0A Kerry Lynn,=0A Klaus Hartke,=0A Linyi Tian,=0A Mich= ele Rossi,=0A Michele Zorzi,=0A Nicola Bui,=0A Peter Saint-A= ndre,=0A Zach Shelby=0A for helpful comments and discussions that= have shaped the document.=0A =0A The research leading to these= results has received funding from the European Community's Seventh Framewo= rk Programme [FP7/2007-2013] under grant agreement n.251557.=0A =0A =0A=0A =0A =0A &RFC2119;=0A &RFC3986;=0A &RFC5234;=0A &RF= C6570;=0A &RFC6690;=0A &RFC7230;=0A &RFC7231;=0A &RFC72= 32;=0A &RFC7235;=0A &RFC7252;=0A &RFC7641;=0A &I-D.ietf= -core-block;=0A =0A =0A &RFC2616;=0A &RFC3040;=0A &RFC4732;=0A &RF= C7049;=0A &RFC7390;=0A &I-D.ietf-core-resource-directory;=0A = &I-D.ietf-core-links-json;=0A =0A=0A
=0A [Note to RFC Editor: Please remove this section bef= ore publication.]=0A=0A Changes from ietf-12 to ietf-13 (Christ= ian Amsuss' comments):=0A =0A Mo= re missing slashes in URI mapping template examples.=0A = =0A =0A=0A Changes from ietf-11 to ietf-12 (2nd WGLC):=0A = =0A Addressed a few editorial is= sues (including a clarification on when to use qq vs q in the URI mapping t= emplate).=0A Fixed missing slash in one template example.=0A Added para about the need for future CoAP protocol elemen= ts to define their own HTTP mappings.=0A =0A =0A= =0A Changes from ietf-10 to ietf-11 (Chair review):=0A =0A Removed cu/su distinction from the URI m= apping template.=0A Addressed a few editorial issues.= =0A =0A =0A=0A Changes from ietf-09 to ietf-= 10:=0A =0A Addressed Ticket #401= - Clarified that draft covers not only Reverse HC Proxy but that many part= s also apply to Forward and Interception Proxies.=0A Clarified th= at draft concentrates on the HTTP-to-CoAP mapping direction (i.e. the HC pr= oxy is a HTTP server and a CoAP client).=0A Clarified the "null m= apping" case where no CoAP URI information is embedded in the HTTP request = URI.=0A Moved multicast related security text to the "Security Co= nsiderations" to consolidate all security information in one location.= =0A Removed references to "placement" of proxy (e.g. server-side vs c= lient-side) as is confusing and provides little added value.=0A F= ixed version numbers on references that were corrupted in last revision due= to outdated xml2rfc conversion tool local cache.=0A Various edit= orial improvements.=0A =0A =0A=0A Change= s from ietf-08 to ietf-09:=0A =0A <= t>Clean up requirements language as per Klaus' comment.=0A =0A =0A=0A Changes from ietf-07 to ietf-08:=0A =0A Addressed WGLC review comments from K= laus Hartke as per the correspondence of March 9, 2016 on the CORE WG maili= ng list. =0A =0A =0A=0A Changes from iet= f-06 to ietf-07:=0A =0A Addresse= d Ticket #384 - Section 5.4.1 describes briefly (informative) how to discov= er CoAP resources from an HTTP client.=0A Addressed Ticket = #378 - For HTTP media type to CoAP content format mapping and vice versa: a= new draft (TBD) may be proposed in CoRE which describes an approach for au= tomatic updating of the media type mapping. This was noted in Section 6.1 = but is otherwise outside the scope of this draft.=0A Addres= sed Ticket #377 - Added IANA section that defines a new HTTP media type "ap= plication/coap-payload" and created new on how to use it.=0A Addressed Ticket #376 - U= pdated Table 2 (and corresponding note 7) to indicate that a CoAP 4.05 (Met= hod Not Allowed) Response Code should be mapped to a HTTP 400 (Bad Request)= =2E=0A Added note to comply to ABNF when translating CoAP d= iagnostic payload to reason-phrase in .=0A =0A =0A=0A Changes from ietf-05 to ietf= -06:=0A =0A Fully restructured t= he draft, bringing introductory text more to the front and allocating main = sections to each of the key topics; addressing Ticket #379;=0A = Addressed Ticket #382, fix of enhanced form URI template definition of = q in Section 5.3.2;=0A Addressed Ticket #381, found a mappi= ng 4.01 to 401 Unauthorized in Section 7;=0A Addressed Tick= et #380 (Add IANA registration for "core.hc" Resource Type) in Section 9;=0A Addressed Ticket #376 (CoAP 4.05 response can't be transl= ated to HTTP 405 by HC proxy) in Section 7 by use of empty 'Allow' header;<= /t>=0A Removed details on the pros and cons of HC proxy placeme= nt options;=0A Addressed review comments of Carsten Bormann= ;=0A Clarified failure in mapping of HTTP Accept headers (S= ection 6.3);=0A Clarified detection of CoAP servers not sup= porting blockwise (Section 8.3);=0A Changed CoAP request ti= meout min value to MAX_RTT + MAX_SERVER_RESPONSE_DELAY (Section 8.6);= =0A Added security section item (Section 10.3) related to use o= f CoAP blockwise transfers;=0A Many editorial improvements.= =0A =0A =0A=0A Changes from ietf-04 to i= etf-05:=0A =0A Addressed Ticket = #366 (Mapping of CoRE Link Format payloads to be valid in HTTP Domain?) in = Section 6.3.3.2 (Content Transcoding - CORE Link Format);=0A <= t>Addressed Ticket #375 (Add requirement on mapping of CoAP diagnostic payl= oad) in Section 6.3.3.3 (Content Transcoding - Diagnostic Messages);=0A= Addressed comment from Yusuke (http://www.ietf.org/mail-archiv= e/web/core/current/msg05491.html) in Section 6.3.3.1 (Content Transcoding -= General);=0A Various editorial improvements.=0A = =0A =0A=0A Changes from ietf-03 to ietf-04:=0A = =0A Expanded use case descriptions = in Section 4;=0A Fixed/enhanced discovery examples in Secti= on 5.4.1;=0A Addressed Ticket #365 (Add text on media type = conversion by HTTP-CoAP proxy) in new Section 6.3.1 (Generalized media type= mapping) and new Section 6.3.2 (Content translation);=0A U= pdated HTTPBis WG draft references to recently published RFC numbers.= =0A Various editorial improvements.=0A =0A = =0A=0A Changes from ietf-02 to ietf-03:=0A =0A Closed Ticket #351 "Add security implications= of proposed default HTTP-CoAP URI mapping";=0A Closed Tick= et #363 "Remove CoAP scheme in default HTTP-CoAP URI mapping";=0A = Closed Ticket #364 "Add discovery of HTTP-CoAP mapping resource(s)"= =2E=0A =0A =0A=0A Changes from ietf-01 t= o ietf-02:=0A =0A Selection of s= ingle default URI mapping proposal as proposed to WG mailing list 2013-10-0= 9.=0A =0A =0A=0A Changes from ietf-00 to= ietf-01:=0A =0A Added URI mappi= ng proposals to Section 4 as per the Email proposals to WG mailing list fro= m Esko.=0A =0A =0A
=0A =0A<= /rfc>=0A=0A --yr/DzoowOgTDcSCF-- --BFVE2HhgxTpCzM8t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj0+wAAoJEDmNERLTpL3hyOAQAIwwMtWVRMXigxHP9dTRxDBK D6HREvrWC8glGvxP9HRd0+czOeZI4TzrAJG9s6ukbN+6pRLOzx74pmVh5i/5snrM GNPZtyhf9L68JPL9t0cgypZPHTLZM+CM6Yuf4acdwcSo6hbb36l2tFW0CzyStHSW Zk0bqV7os+x67SDeby7Afejkpiq8W1cwvyGKK+xcrVr6zKglnPl3onI+eIeIRAGu GUzTXiuhUfXz7RFBo9/FzLpEaxm5dE45muiHwv5eQpjn0/4h4/nsUgqP81e7Gmvp pNZ2ClwFxmYQLQCbyRgFcZc9liTfcrxEcE41JzKXevuFKpgSs/wA8lVuYkO3dhiU JTuPXVzZXen1CykYFT9l7gRdQMqUudr4EUGM7Kp1kbBNeC4R89/wm0qNKoo4hbZx qSiqGcwtTenmwrba4ycbay45IJXO6LXHUsH6JKey+oTtL2OaDPRQlbnwDGSwdy/f Gx+IXxcaF/OJL8Tckr5d7PnJiy2ZhNMNii3WmHVAYZENwG5RO8BP+e4V5eOhLcn2 7p346yWVlDN+1EZnxLn+w1iypDT3NPVVKmC6srHdwFDdqPQklHj+wY1hseGKJVb/ KfaOz06r8TE2WKO9CvsGRSOi63FYFZLfQ2gGc+HZTHo3XKt6S/fVXdBQdZFhXUjv keNs9IKHGyP31DGxmSZc =aJKp -----END PGP SIGNATURE----- --BFVE2HhgxTpCzM8t-- From nobody Wed Jul 20 04:17:16 2016 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 E9CFC12DBB1 for ; Wed, 20 Jul 2016 04:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=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 FYNhDN7pj8SL for ; Wed, 20 Jul 2016 04:17:10 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 C2F7012DB9D for ; Wed, 20 Jul 2016 04:17:05 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 45EEDAAB30775; Wed, 20 Jul 2016 11:17:00 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6KBH1J1017835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2016 11:17:02 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6KBH01Y012464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Jul 2016 13:17:01 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 20 Jul 2016 13:17:00 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] draft-ietf-core-http-mapping-12 Thread-Index: AQHR4dCjIchJ9i6EKkafmJ9U3Wo34KAf8i4AgAA3yICAAMpPAIAABmKAgAAhZAA= Date: Wed, 20 Jul 2016 11:17:00 +0000 Message-ID: References: <20160719151717.GD26784@hephaistos.amsuess.com> <20160719215027.GE26784@hephaistos.amsuess.com> <20160720101723.GI7974@hephaistos.amsuess.com> In-Reply-To: <20160720101723.GI7974@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: multipart/mixed; boundary="_002_D3B518B96E345thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-http-mapping-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 11:17:14 -0000 --_002_D3B518B96E345thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5C025BC129EBCE4482EDA34F169C7B71@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable Hi Christian, thanks very much! On 20/07/2016 11:17, "Christian Ams=FCss" wrote: >On Wed, Jul 20, 2016 at 08:54:34AM +0000, Fossati, Thomas (Nokia - GB) >wrote: >> Excellent. I've attached my working copy. You hold the edit lock now. > >Attached, you'll find my modified version; thereby returning the edit >lock to you. > >The bulk examples now all use the /hc/ Proxy URI like the intro >examples, often producing a /hc/?foo=3D pattern in the Hosting HTTP URI >(which may not be fully widespread but is neither wrong nor bad). Only >one example would have ended up with a double slash, so another path >component was introduced in the Mapping Template (/hc/ + forward/{+tu}), >otherwise the example would become completely moot (dropping it would be >an option too IMO). OK. >During writing I've utilized the xml2rfc tool to generate HTML previews, >and noted that in 5.4.1.1, the enumerated example headlines did appear >below the example blocks. This might be a bug only in the xml2rfc >version I'm using, but you might want to have a brief look at if it >works for you. It renders as expected using my xml2rfc (2.5.1). (What version are you using?) I have attached the newest diff including Christian's edits. If everyone is happy with it I'm going to submit it by tonight. Cheers, t --_002_D3B518B96E345thomasfossatialcatellucentcom_ Content-Type: text/html; name="draft-ietf-core-http-mapping-13-from-2.diff.html" Content-Description: draft-ietf-core-http-mapping-13-from-2.diff.html Content-Disposition: attachment; filename="draft-ietf-core-http-mapping-13-from-2.diff.html"; size=77365; creation-date="Wed, 20 Jul 2016 11:16:59 GMT"; modification-date="Wed, 20 Jul 2016 11:16:59 GMT" Content-ID: <1CE5CF87FB12FD45A87128EFC8076D27@exchange.lucent.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQyOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogRGFyd2luIGJvbmdvIDE0LjUuMCBEYXJ3aW4gS2VybmVs IFZlcnNpb24gMTQuNS4wOiBNb24gSmFuIDExIDE4OjQ4OjM1IFBTVCAyMDE2OyByb290OnhudS0y NzgyLjUwLjJ+MS9SRUxFQVNFX1g4Nl82NCB4ODZfNjQgLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vz ci9sb2NhbC9iaW4vZ2F3azogR05VIEF3ayA0LjEuMSwgQVBJOiAxLjEgLS0+IAo8IS0tIFVzaW5n IGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDIuOC4xIC0tPiAKPCEt LSBVc2luZyB3ZGlmZjogL3Vzci9sb2NhbC9iaW4vd2RpZmY6IHdkaWZmIChHTlUgd2RpZmYpIDEu Mi4yIC0tPiAKPGh0bWw+IAo8aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSIgLz4gCiAgPG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRp dGxlPkRpZmY6IGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMTIudHh0IC0gZHJhZnQtaWV0 Zi1jb3JlLWh0dHAtbWFwcGluZy0xMy50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9j c3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0g CiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBmb250LWZh bWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAuODZlbTt9 IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7IGZvbnQt c2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RUVFOyB9IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlm ZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0g CiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6 ICNGRkI7IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5s aW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiBy ZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246 IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9y OiAjQUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IAog ICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5sYmxvY2sg LmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJh Y2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFE OyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogIDwvc3R5bGU+IAo8L2hlYWQ+IAo8Ym9keSA+IAog IDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0 ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRmLWNvcmUtaHR0 cC1tYXBwaW5nLTEyLnR4dCZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRm LWNvcmUtaHR0cC1tYXBwaW5nLTEzLnR4dCZuYnNwOzwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29SRSBXb3JraW5nIEdyb3VwICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDYXN0ZWxsYW5pPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29SRSBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDYXN0ZWxsYW5pPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2ZXJzaXR5IG9mIFBhZG92YTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBVbml2ZXJzaXR5IG9mIFBhZG92YTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6 IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBMb3JldG88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0 aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBMb3JldG88L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDAxIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogSmFudWFyeSA8c3Bh biBjbGFzcz0iZGVsZXRlIj4xOTwvc3Bhbj4sIDIwMTcgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5F eHBpcmVzOiBKYW51YXJ5IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjIxPC9zcGFuPiwgMjAxNyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIFJhaG1hbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIFJhaG1hbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSW50ZXJEaWdpdGFsIENvbW11bmljYXRpb25zLCBM TEM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSW50ZXJEaWdpdGFsIENvbW11bmljYXRpb25zLCBMTEM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBG b3NzYXRpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBGb3NzYXRpPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOb2tpYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb2tp YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEUuIERpams8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUu IERpams8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBQaGlsaXBzIExpZ2h0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsaXBz IExpZ2h0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SnVseSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xODwvc3Bhbj4sIDIwMTY8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBKdWx5IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjIwPC9zcGFuPiwg MjAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIEd1aWRlbGluZXMgZm9y IEhUVFAtdG8tQ29BUCBNYXBwaW5nIEltcGxlbWVudGF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICBHdWlkZWxpbmVzIGZvciBIVFRQLXRvLUNvQVAgTWFwcGlu ZyBJbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAzIiAvPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTE8 c3BhbiBjbGFzcz0iZGVsZXRlIj4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMTxz cGFuIGNsYXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5B YnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHJlZmVyZW5jZSBp bmZvcm1hdGlvbiBmb3IgaW1wbGVtZW50aW5nIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHJlZmVyZW5jZSBpbmZvcm1hdGlvbiBmb3Ig aW1wbGVtZW50aW5nIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgY3Jvc3MtcHJvdG9jb2wgbmV0d29yayBwcm94eSB0aGF0IHBlcmZvcm1z IHRyYW5zbGF0aW9uIGZyb20gdGhlIEhUVFA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBjcm9zcy1wcm90b2NvbCBuZXR3b3JrIHByb3h5IHRoYXQgcGVyZm9ybXMgdHJhbnNsYXRp b24gZnJvbSB0aGUgSFRUUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBwcm90b2NvbCB0byB0aGUgQ29BUCBwcm90b2NvbC4gIFRoaXMgd2ls bCBlbmFibGUgYSBIVFRQIGNsaWVudCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHByb3RvY29sIHRvIHRoZSBDb0FQIHByb3RvY29sLiAgVGhpcyB3aWxsIGVuYWJsZSBhIEhU VFAgY2xpZW50IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGFjY2VzcyByZXNvdXJjZXMgb24gYSBDb0FQIHNlcnZlciB0aHJvdWdoIHRo ZSBwcm94eS4gIFRoaXMgZG9jdW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBhY2Nlc3MgcmVzb3VyY2VzIG9uIGEgQ29BUCBzZXJ2ZXIgdGhyb3VnaCB0aGUgcHJveHkuICBU aGlzIGRvY3VtZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGRlc2NyaWJlcyBob3cgYSBIVFRQIHJlcXVlc3QgaXMgbWFwcGVkIHRvIGEg Q29BUCByZXF1ZXN0LCBhbmQgdGhlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGRlc2NyaWJlcyBob3cgYSBIVFRQIHJlcXVlc3QgaXMgbWFwcGVkIHRvIGEgQ29BUCByZXF1ZXN0 LCBhbmQgdGhlbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBob3cgYSBDb0FQIHJlc3BvbnNlIGlzIG1hcHBlZCBiYWNrIHRvIGEgSFRUUCBy ZXNwb25zZS4gIFRoaXMgaW5jbHVkZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBob3cgYSBDb0FQIHJlc3BvbnNlIGlzIG1hcHBlZCBiYWNrIHRvIGEgSFRUUCByZXNwb25zZS4g IFRoaXMgaW5jbHVkZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZ3VpZGVsaW5lcyBmb3IgVVJJIG1hcHBpbmcsIG1lZGlhIHR5cGUgbWFw cGluZyBhbmQgYWRkaXRpb25hbCBwcm94eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGd1aWRlbGluZXMgZm9yIFVSSSBtYXBwaW5nLCBtZWRpYSB0eXBlIG1hcHBpbmcgYW5kIGFk ZGl0aW9uYWwgcHJveHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9 InBhcnQtbDIiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdl IDEsIGxpbmUgNDU8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyIiAvPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDQ1PC9l bT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMg b2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0 IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBv ZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBE cmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQg ZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHBy b2dyZXNzLiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAwNCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSmFudWFyeSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xOTwvc3Bhbj4sIDIwMTcuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gSmFudWFyeSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yMTwvc3Bhbj4sIDIwMTcu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25z IGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29w eXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2Vy dmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJq ZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3Vt ZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRp bmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m bykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9u IHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3 IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyIgLz48c21h bGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgOSwgbGluZSA1PC9lbT48 L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMyIgLz48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgOSwgbGluZSA1PC9lbT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB3aWxsIGRldGVybWluZSB0aHJvdWdoIGl0cyBvd24gcHJvcHJpZXRhcnkg YWxnb3JpdGhtcyB3aGF0IHRoZSBUYXJnZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB3aWxsIGRldGVybWluZSB0aHJvdWdoIGl0cyBvd24gcHJvcHJpZXRhcnkgYWxnb3JpdGht cyB3aGF0IHRoZSBUYXJnZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgQ29BUCBVUkkgc2hvdWxkIGJlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIENvQVAgVVJJIHNob3VsZCBiZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjUuMy4gIERlZmF1bHQgTWFwcGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjUuMy4gIERlZmF1bHQgTWFwcGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGhlIGRlZmF1bHQgbWFwcGluZyBpcyBmb3IgdGhlIFRhcmdldCBDb0FQIFVSSSB0byBiZSBhcHBl bmRlZCBhcy1pczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBkZWZhdWx0 IG1hcHBpbmcgaXMgZm9yIHRoZSBUYXJnZXQgQ29BUCBVUkkgdG8gYmUgYXBwZW5kZWQgYXMtaXM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dG8gdGhlIEhDIFByb3h5IFVSSSwgdG8gZm9ybSB0aGUgSG9zdGluZyBIVFRQIFVSSS4gIFRoaXMg aXMgdGhlIFVSSTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHRoZSBIQyBQ cm94eSBVUkksIHRvIGZvcm0gdGhlIEhvc3RpbmcgSFRUUCBVUkkuICBUaGlzIGlzIHRoZSBVUkk8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dGhhdCB3aWxsIHRoZW4gYmUgc2VudCBieSB0aGUgSFRUUCBjbGllbnQgaW4gdGhlIEhUVFAgcmVx dWVzdCB0byB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGF0IHdpbGwg dGhlbiBiZSBzZW50IGJ5IHRoZSBIVFRQIGNsaWVudCBpbiB0aGUgSFRUUCByZXF1ZXN0IHRvIHRo ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBIQyBwcm94eS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBIQyBwcm94eS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNSIgLz48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIEZvciBleGFtcGxlOiBnaXZlbiBhIEhDIFByb3h5IFVSSSBo dHRwOi8vcC5leGFtcGxlLmNvbS9oYyBhbmQgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBGb3IgZXhhbXBsZTogZ2l2ZW4gYSBIQyBQcm94eSBVUkkgaHR0cDovL3AuZXhhbXBs ZS5jb20vaGM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4vPC9zcGFuPiBhbmQgYTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXJnZXQgQ29BUCBV UkkgY29hcDovL3MuZXhhbXBsZS5jb20vbGlnaHQsIHRoZSByZXN1bHRpbmcgSG9zdGluZzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRhcmdldCBDb0FQIFVSSSBjb2FwOi8vcy5l eGFtcGxlLmNvbS9saWdodCwgdGhlIHJlc3VsdGluZyBIb3N0aW5nPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEhUVFAgVVJJIHdvdWxkIGJl IGh0dHA6Ly9wLmV4YW1wbGUuY29tL2hjL2NvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0LjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhUVFAgVVJJIHdvdWxkIGJlIGh0dHA6Ly9w LmV4YW1wbGUuY29tL2hjL2NvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0LjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlkZWQgYSBjb3JyZWN0IFRhcmdldCBDb0FQIFVSSSwgdGhl IEhvc3RpbmcgSFRUUCBVUkkgcmVzdWx0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgUHJvdmlkZWQgYSBjb3JyZWN0IFRhcmdldCBDb0FQIFVSSSwgdGhlIEhvc3RpbmcgSFRU UCBVUkkgcmVzdWx0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGZyb20gdGhlIGRlZmF1bHQgbWFwcGluZyBpcyBhbHdheXMgc3ludGFj dGljYWxseSBjb3JyZWN0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZyb20g dGhlIGRlZmF1bHQgbWFwcGluZyBpcyBhbHdheXMgc3ludGFjdGljYWxseSBjb3JyZWN0LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGdXJ0 aGVybW9yZSwgdGhlIFRhcmdldCBDb0FQIFVSSSBjYW4gYWx3YXlzIGJlIGV4dHJhY3RlZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZ1cnRoZXJtb3JlLCB0aGUgVGFyZ2V0IENv QVAgVVJJIGNhbiBhbHdheXMgYmUgZXh0cmFjdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVuYW1iaWd1b3VzbHkgZnJvbSB0aGUgSG9z dGluZyBIVFRQIFVSSS4gIEFsc28sIGl0IGlzIHdvcnRoIG5vdGluZzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHVuYW1iaWd1b3VzbHkgZnJvbSB0aGUgSG9zdGluZyBIVFRQIFVS SS4gIEFsc28sIGl0IGlzIHdvcnRoIG5vdGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0LCB1c2luZyB0aGUgZGVmYXVsdCBtYXBw aW5nLCBhIHF1ZXJ5IGNvbXBvbmVudCBpbiB0aGUgdGFyZ2V0IENvQVA8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGF0LCB1c2luZyB0aGUgZGVmYXVsdCBtYXBwaW5nLCBhIHF1 ZXJ5IGNvbXBvbmVudCBpbiB0aGUgdGFyZ2V0IENvQVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVzb3VyY2UgVVJJIGlzIG5hdHVyYWxs eSBlbmNvZGVkIGludG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICByZXNvdXJjZSBVUkkgaXMgbmF0dXJhbGx5IGVuY29kZWQgaW50 byB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBIb3N0aW5nIFVSSSwgZS5nLjogY29hcDovL3Mu ZXhhbXBsZS5jb20vbGlnaHQ/ZGltPTUgYmVjb21lczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEhvc3RpbmcgVVJJLCBlLmcuOiBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodD9k aW09NSBiZWNvbWVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJw YXJ0LWw0IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAx MCwgbGluZSA0MjwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjQiIC8+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEwLCBsaW5lIDQyPC9l bT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgIHR1ID0gY29hcC1VUkkgLyBjb2Fwcy1VUkkgIDsgZnJvbSBbUkZDNzI1Ml0sIFNl Y3Rpb24gNi4xIGFuZCA2LjI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg dHUgPSBjb2FwLVVSSSAvIGNvYXBzLVVSSSAgOyBmcm9tIFtSRkM3MjUyXSwgU2VjdGlvbiA2LjEg YW5kIDYuMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNhbWUgY29uc2lkZXJh dGlvbnMgYXMgaW4gU2VjdGlvbiA1LjMuMSBhcHBseSwgaW4gdGhhdCB0aGUgQ29BUDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBzYW1lIGNvbnNpZGVyYXRpb25zIGFzIGlu IFNlY3Rpb24gNS4zLjEgYXBwbHksIGluIHRoYXQgdGhlIENvQVA8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2NoZW1lIG1heSBiZSBvbWl0 dGVkIGZyb20gdGhlIEhvc3RpbmcgSFRUUCBVUkkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgc2NoZW1lIG1heSBiZSBvbWl0dGVkIGZyb20gdGhlIEhvc3RpbmcgSFRUUCBVUkku PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjQuMS4xLiAgRXhhbXBsZXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij41LjQuMS4xLiAgRXhhbXBsZXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEFsbCB0aGUgZm9sbG93aW5nIGV4YW1wbGVzIChnaXZlbiBhcyBhIHNw ZWNpZmljIFVSSSBtYXBwaW5nIHRlbXBsYXRlLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIEFsbCB0aGUgZm9sbG93aW5nIGV4YW1wbGVzIChnaXZlbiBhcyBhIHNwZWNpZmljIFVS SSBtYXBwaW5nIHRlbXBsYXRlLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBhIFRhcmdldCBDb0FQIFVSSSwgYW5kIHRoZSBwcm9kdWNlZCBI b3N0aW5nIEhUVFAgVVJJKSB1c2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh IFRhcmdldCBDb0FQIFVSSSwgYW5kIHRoZSBwcm9kdWNlZCBIb3N0aW5nIEhUVFAgVVJJKSB1c2U8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDA2IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaHR0cDovL3Au ZXhhbXBsZS5jb20vaGMgYXMgdGhlIEhDIFByb3h5IFVSSS4gIE5vdGUgdGhhdCB0aGVzZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYzxz cGFuIGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+IGFzIHRoZSBIQyBQcm94eSBVUkkuICBOb3RlIHRo YXQgdGhlc2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZXhhbXBsZXMgYWxsIGRlZmluZSBtYXBwaW5nIHRlbXBsYXRlcyB0aGF0IGRldmlh dGUgZnJvbSB0aGUgZGVmYXVsdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4 YW1wbGVzIGFsbCBkZWZpbmUgbWFwcGluZyB0ZW1wbGF0ZXMgdGhhdCBkZXZpYXRlIGZyb20gdGhl IGRlZmF1bHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdGVtcGxhdGUgb2YgU2VjdGlvbiA1LjMgdG8gYmUgYWJsZSB0byBpbGx1c3RyYXRl IHRoZSB1c2Ugb2YgdGhlIGFib3ZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg dGVtcGxhdGUgb2YgU2VjdGlvbiA1LjMgdG8gYmUgYWJsZSB0byBpbGx1c3RyYXRlIHRoZSB1c2Ug b2YgdGhlIGFib3ZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHRlbXBsYXRlIHZhcmlhYmxlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0ZW1wbGF0ZSB2YXJpYWJsZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAxLiAgVGFyZ2V0IENvQVAgVVJJIGlzIGEgcXVlcnkgYXJndW1lbnQgb2YgdGhlIEhvc3Rp bmcgSFRUUCBVUkk6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMS4gIFRhcmdl dCBDb0FQIFVSSSBpcyBhIHF1ZXJ5IGFyZ3VtZW50IG9mIHRoZSBIb3N0aW5nIEhUVFAgVVJJOjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgP3RhcmdldF91cmk9eyt0dX08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA/dGFyZ2V0X3VyaT17K3R1fTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgY29hcDovL3MuZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA3IiAvPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGM/dGFyZ2V0X3VyaT1jb2FwOi8v cy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBo dHRwOi8vcC5leGFtcGxlLmNvbS9oYzxzcGFuIGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+P3Rhcmdl dF91cmk9Y29hcDovL3MuZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3I8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvYXBzOi8vcy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvYXBzOi8vcy5leGFtcGxlLmNvbS9saWdodDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA4IiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGM/dGFyZ2V0X3VyaT1j b2FwczovL3MuZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4vPC9zcGFu Pj90YXJnZXRfdXJpPWNvYXBzOi8vcy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA5IiAvPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgMi4gIFRhcmdldCBDb0FQIFVSSSBpbiB0aGUgcGF0aCBjb21wb25lbnQgb2YgdGhlIEhv c3RpbmcgSFRUUCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5VUkk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDIuICBUYXJnZXQgQ29BUCBVUkkgaW4gdGhlIHBhdGggY29t cG9uZW50IG9mIHRoZSBIb3N0aW5nIEhUVFAgPHNwYW4gY2xhc3M9Imluc2VydCI+VVJJOjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgKGkuZS4sIHRoZSBkZWZhdWx0IFVSSSBNYXBw aW5nIHRlbXBsYXRlKTo8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEwIiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgL3srdHV9PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmZvcndhcmQ8L3NwYW4+L3srdHV9PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTEiIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYy9jb2FwOi8vcy5leGFt cGxlLmNvbS9saWdodDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBodHRwOi8v cC5leGFtcGxlLmNvbS9oYy88c3BhbiBjbGFzcz0iaW5zZXJ0Ij5mb3J3YXJkLzwvc3Bhbj5jb2Fw Oi8vcy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3I8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgY29hcHM6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgY29hcHM6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTIiIC8+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYy9jb2FwczovL3MuZXhhbXBsZS5jb20v bGlnaHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaHR0cDovL3AuZXhhbXBs ZS5jb20vaGMvPHNwYW4gY2xhc3M9Imluc2VydCI+Zm9yd2FyZC88L3NwYW4+Y29hcHM6Ly9zLmV4 YW1wbGUuY29tL2xpZ2h0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAzLiAgImNvYXAi IFVSSSBpcyBhIHF1ZXJ5IGFyZ3VtZW50IG9mIHRoZSBIb3N0aW5nIEhUVFAgVVJJOyBjbGllbnQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgImNvYXAiIFVSSSBpcyBhIHF1 ZXJ5IGFyZ3VtZW50IG9mIHRoZSBIb3N0aW5nIEhUVFAgVVJJOyBjbGllbnQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIGRlY2lkZXMg dG8gb21pdCBzY2hlbWUgYmVjYXVzZSBhIGRlZmF1bHQgc2NoZW1lIGlzIGFncmVlZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBkZWNpZGVzIHRvIG9taXQgc2NoZW1lIGJl Y2F1c2UgYSBkZWZhdWx0IHNjaGVtZSBpcyBhZ3JlZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIGJlZm9yZWhhbmQgYmV0d2VlbiBj bGllbnQgYW5kIHByb3h5OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBi ZWZvcmVoYW5kIGJldHdlZW4gY2xpZW50IGFuZCBwcm94eTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgID9jb2FwX3VyaT17K3R1fTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgID9jb2FwX3VyaT17K3R1fTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29hcDov L3MuZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBj b2FwOi8vcy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDEzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaHR0cDovL3Au ZXhhbXBsZS5jb20vaGM/Y29hcF91cmk9cy5leGFtcGxlLmNvbS9saWdodDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYzxzcGFuIGNsYXNz PSJpbnNlcnQiPi88L3NwYW4+P2NvYXBfdXJpPXMuZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjUuNC4yLiAgRW5oYW5jZWQgRm9ybTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjUuNC4yLiAgRW5oYW5jZWQgRm9ybTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhlIGVuaGFuY2VkIGZvcm0gY2FuIGJlIHVzZWQgdG8gZXhwcmVzcyBtb3Jl IHNvcGhpc3RpY2F0ZWQgbWFwcGluZ3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUaGUgZW5oYW5jZWQgZm9ybSBjYW4gYmUgdXNlZCB0byBleHByZXNzIG1vcmUgc29waGlzdGlj YXRlZCBtYXBwaW5nczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBvZiB0aGUgVGFyZ2V0IENvQVAgVVJJIGludG8gdGhlIEhvc3RpbmcgSFRU UCBVUkksIGkuZS4sIG1hcHBpbmdzIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvZiB0aGUgVGFyZ2V0IENvQVAgVVJJIGludG8gdGhlIEhvc3RpbmcgSFRUUCBVUkksIGku ZS4sIG1hcHBpbmdzIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgZG8gbm90IGZpdCBpbnRvIHRoZSBzaW1wbGUgZm9ybS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkbyBub3QgZml0IGludG8gdGhlIHNpbXBsZSBm b3JtLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlcmUgTVVTVCBiZSBhdCBtb3N0 IG9uZSBpbnN0YW5jZSBvZiBlYWNoIG9mIHRoZSBmb2xsb3dpbmcgdGVtcGxhdGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGVyZSBNVVNUIGJlIGF0IG1vc3Qgb25lIGluc3Rh bmNlIG9mIGVhY2ggb2YgdGhlIGZvbGxvd2luZyB0ZW1wbGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB2YXJpYWJsZXMgaW4gYSB0ZW1w bGF0ZSBkZWZpbml0aW9uOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHZhcmlh YmxlcyBpbiBhIHRlbXBsYXRlIGRlZmluaXRpb246PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNSIg Lz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTIsIGxpbmUg MjQ8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI1IiAvPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxMiwgbGluZSAyNDwvZW0+PC90aD48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHFxIGZvcm0gaXMgdXNlZCB3aGVuIHRoZSBwYXRo IGFuZCB0aGUgKG9wdGlvbmFsKSBxdWVyeSBjb21wb25lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhlIHFxIGZvcm0gaXMgdXNlZCB3aGVuIHRoZSBwYXRoIGFuZCB0aGUg KG9wdGlvbmFsKSBxdWVyeSBjb21wb25lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFyZSB0byBiZSBjb3BpZWQgdmVyYmF0aW0gZnJv bSB0aGUgVGFyZ2V0IENvQVAgVVJJIGludG8gdGhlIEhvc3Rpbmc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBhcmUgdG8gYmUgY29waWVkIHZlcmJhdGltIGZyb20gdGhlIFRhcmdl dCBDb0FQIFVSSSBpbnRvIHRoZSBIb3N0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEhUVFAgVVJJLCBpLmUuIGFzICJ7K3B9eytxcX0i LiAgSW5zdGVhZCwgdGhlIHEgZm9ybSBpcyB1c2VkIHdoZW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgSFRUUCBVUkksIGkuZS4gYXMgInsrcH17K3FxfSIuICBJbnN0ZWFk LCB0aGUgcSBmb3JtIGlzIHVzZWQgd2hlbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcXVlcnkgYW5kIHBhdGggYXJlIG1hcHBlZCBh cyBzZXBhcmF0ZSBlbnRpdGllcywgZS5nLiBhcyBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHF1ZXJ5IGFuZCBwYXRoIGFyZSBtYXBwZWQgYXMgc2VwYXJhdGUgZW50aXRpZXMs IGUuZy4gYXMgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgImNvYXBfcGF0aD17K3B9JmFtcDtjb2FwX3F1ZXJ5PXsrcX0iLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJjb2FwX3BhdGg9eytwfSZhbXA7Y29hcF9xdWVy eT17K3F9Ii48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjUuNC4yLjEuICBFeGFtcGxlczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuNC4yLjEuICBFeGFtcGxlczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQWxsIHRoZSBmb2xsb3dpbmcgZXhhbXBsZXMgKGdpdmVu IGFzIGEgc3BlY2lmaWMgVVJJIG1hcHBpbmcgdGVtcGxhdGUsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgQWxsIHRoZSBmb2xsb3dpbmcgZXhhbXBsZXMgKGdpdmVuIGFzIGEgc3Bl Y2lmaWMgVVJJIG1hcHBpbmcgdGVtcGxhdGUsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGEgVGFyZ2V0IENvQVAgVVJJLCBhbmQgdGhlIHBy b2R1Y2VkIEhvc3RpbmcgSFRUUCBVUkkpIHVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGEgVGFyZ2V0IENvQVAgVVJJLCBhbmQgdGhlIHByb2R1Y2VkIEhvc3RpbmcgSFRUUCBV UkkpIHVzZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBo dHRwOi8vcC5leGFtcGxlLmNvbS9oYyBhcyB0aGUgSEMgUHJveHkgVVJJLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYzxzcGFuIGNsYXNz PSJpbnNlcnQiPi88L3NwYW4+IGFzIHRoZSBIQyBQcm94eSBVUkkuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAxLiAgVGFyZ2V0IENvQVAgVVJJIGNvbXBvbmVudHMgaW4gcGF0aCBzZWdt ZW50cywgYW5kIG9wdGlvbmFsIHF1ZXJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgMS4gIFRhcmdldCBDb0FQIFVSSSBjb21wb25lbnRzIGluIHBhdGggc2VnbWVudHMsIGFuZCBv cHRpb25hbCBxdWVyeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgaW4gcXVlcnkgY29tcG9uZW50OjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICBpbiBxdWVyeSBjb21wb25lbnQ6PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTUiIC8+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Lzwvc3Bhbj57K3N9L3sraHB9eytwfXsrcXF9 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICB7K3N9L3sraHB9eytwfXsr cXF9PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgY29hcDovL3MuZXhhbXBsZS5j b20vbGlnaHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgY29hcDovL3Mu ZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBodHRw Oi8vcC5leGFtcGxlLmNvbS9oYy9jb2FwL3MuZXhhbXBsZS5jb20vbGlnaHQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGMvY29hcC9z LmV4YW1wbGUuY29tL2xpZ2h0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgb3I8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgb3I8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdodD9vbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBjb2FwOi8vcy5leGFtcGxlLmNvbS9saWdo dD9vbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIGh0dHA6Ly9wLmV4YW1wbGUu Y29tL2hjL2NvYXAvcy5leGFtcGxlLmNvbS9saWdodD9vbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYy9jb2FwL3MuZXhhbXBsZS5j b20vbGlnaHQ/b248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBUYXJnZXQgQ29B UCBVUkkgY29tcG9uZW50cyBzcGxpdCBpbiBpbmRpdmlkdWFsIHF1ZXJ5IGFyZ3VtZW50czo8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAyLiAgVGFyZ2V0IENvQVAgVVJJIGNvbXBv bmVudHMgc3BsaXQgaW4gaW5kaXZpZHVhbCBxdWVyeSBhcmd1bWVudHM6PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgP3M9eytzfSZhbXA7aHA9eytocH0mYW1wO3A9eytwfSZhbXA7 cT17K3F9PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgID9zPXsrc30mYW1w O2hwPXsraHB9JmFtcDtwPXsrcH0mYW1wO3E9eytxfTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgIGNvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgIGNvYXA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTYiIC8+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGM/cz1jb2FwJmFtcDtocD1zLmV4 YW1wbGUuY29tJmFtcDtwPS9saWdodCZhbXA7cT08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgIGh0dHA6Ly9wLmV4YW1wbGUuY29tL2hjPHNwYW4gY2xhc3M9Imluc2VydCI+ Lzwvc3Bhbj4/cz1jb2FwJmFtcDtocD1zLmV4YW1wbGUuY29tJmFtcDtwPS9saWdodCZhbXA7cT08 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg IGNvYXBzOi8vcy5leGFtcGxlLmNvbS9saWdodD9vbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICBjb2FwczovL3MuZXhhbXBsZS5jb20vbGlnaHQ/b248L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNyIgLz48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICAgICBodHRwOi8vcC5leGFtcGxlLmNvbS9oYz9zPWNvYXBzJmFtcDtocD1zLmV4 YW1wbGUuY29tJmFtcDtwPS9saWdodCZhbXA7cT1vbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgaHR0cDovL3AuZXhhbXBsZS5jb20vaGM8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4vPC9zcGFuPj9zPWNvYXBzJmFtcDtocD1zLmV4YW1wbGUuY29tJmFtcDtwPS9saWdodCZhbXA7 cT1vbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NS41LiAgRGlzY292ZXJ5PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NS41LiAgRGlzY292ZXJ5PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBJbiBvcmRlciB0byBhY2NvbW1vZGF0ZSBzaXRlIHNwZWNpZmljIG5lZWRz IHdoaWxlIGFsbG93aW5nIHRoaXJkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg SW4gb3JkZXIgdG8gYWNjb21tb2RhdGUgc2l0ZSBzcGVjaWZpYyBuZWVkcyB3aGlsZSBhbGxvd2lu ZyB0aGlyZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBwYXJ0aWVzIHRvIGRpc2NvdmVyIHRoZSBwcm94eSBmdW5jdGlvbiwgdGhlIEhDIHBy b3h5IFNIT1VMRCBwdWJsaXNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcGFy dGllcyB0byBkaXNjb3ZlciB0aGUgcHJveHkgZnVuY3Rpb24sIHRoZSBIQyBwcm94eSBTSE9VTEQg cHVibGlzaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBsb2NhdGlvbiBhbmQgc3ludGF4IG9m IHRoZSBIQyBwcm94eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluZm9ybWF0 aW9uIHJlbGF0ZWQgdG8gdGhlIGxvY2F0aW9uIGFuZCBzeW50YXggb2YgdGhlIEhDIHByb3h5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZ1 bmN0aW9uIHVzaW5nIHRoZSBDb1JFIExpbmsgRm9ybWF0IFtSRkM2NjkwXSBpbnRlcmZhY2UuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZnVuY3Rpb24gdXNpbmcgdGhlIENvUkUg TGluayBGb3JtYXQgW1JGQzY2OTBdIGludGVyZmFjZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFRvIHRoaXMgYWltIGEgbmV3IFJlc291cmNlIFR5cGUsICJjb3JlLmhjIiwgaXMgZGVm aW5lZCBpbiB0aGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVG8gdGhpcyBh aW0gYSBuZXcgUmVzb3VyY2UgVHlwZSwgImNvcmUuaGMiLCBpcyBkZWZpbmVkIGluIHRoaXM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9j dW1lbnQuICBJdCBjYW4gYmUgdXNlZCBhcyB0aGUgdmFsdWUgZm9yIHRoZSAicnQiIGF0dHJpYnV0 ZSBpbiBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQuICBJdCBj YW4gYmUgdXNlZCBhcyB0aGUgdmFsdWUgZm9yIHRoZSAicnQiIGF0dHJpYnV0ZSBpbiBhPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg Ymdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw2IiAvPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxNCwgbGluZSAxMDwvZW0+PC90 aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjYiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDE0LCBsaW5lIDEwPC9lbT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBvICBUaGUgZmlyc3QgZXhhbXBsZSBleGVyY2lzZXMgdGhlIENvQVAgaW50 ZXJmYWNlLCBhbmQgYXNzdW1lcyB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbyAgVGhlIGZpcnN0IGV4YW1wbGUgZXhlcmNpc2VzIHRoZSBDb0FQIGludGVyZmFjZSwgYW5k IGFzc3VtZXMgdGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICB0aGUgZGVmYXVsdCB0ZW1wbGF0ZSwgeyt0dX0sIGlzIHVzZWQuICBG b3IgZXhhbXBsZSwgaW4gdXNlIGNhc2UgIzM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICB0aGUgZGVmYXVsdCB0ZW1wbGF0ZSwgeyt0dX0sIGlzIHVzZWQuICBGb3IgZXhhbXBs ZSwgaW4gdXNlIGNhc2UgIzM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgaW4gc2VjdGlvbiBTZWN0aW9uIDQsIHRoZSBzbWFydHBob25l IG1heSBkaXNjb3ZlciB0aGUgcHVibGljIEhDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgaW4gc2VjdGlvbiBTZWN0aW9uIDQsIHRoZSBzbWFydHBob25lIG1heSBkaXNjb3Zl ciB0aGUgcHVibGljIEhDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIHByb3h5IGJlZm9yZSBsZWF2aW5nIHRoZSBob21lIG5ldHdvcmsu ICBUaGVuIHdoZW4gb3V0c2lkZSB0aGUgaG9tZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgIHByb3h5IGJlZm9yZSBsZWF2aW5nIHRoZSBob21lIG5ldHdvcmsuICBUaGVuIHdo ZW4gb3V0c2lkZSB0aGUgaG9tZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBuZXR3b3JrLCB0aGUgc21hcnRwaG9uZSB3aWxsIGJlIGFi bGUgdG8gcXVlcnkgdGhlIGFwcHJvcHJpYXRlIGhvbWU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBuZXR3b3JrLCB0aGUgc21hcnRwaG9uZSB3aWxsIGJlIGFibGUgdG8gcXVl cnkgdGhlIGFwcHJvcHJpYXRlIGhvbWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgc2Vuc29yLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIHNlbnNvci48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICBSZXE6ICBHRVQgY29hcDovL1tmZjAyOjoxXS8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUuaGM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVxOiAgR0VUIGNvYXA6Ly9b ZmYwMjo6MV0vLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgUmVzOiAgMi4wNSBDb250ZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgIFJlczogIDIuMDUgQ29udGVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgi IC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgJmx0Oy9oYyZndDs7YW5jaG9yPSJo dHRwOi8vcC5leGFtcGxlLmNvbSI7cnQ9ImNvcmUuaGMiPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgICAgICAgICAmbHQ7L2hjPHNwYW4gY2xhc3M9Imluc2VydCI+Lzwvc3Bh bj4mZ3Q7O2FuY2hvcj0iaHR0cDovL3AuZXhhbXBsZS5jb20iO3J0PSJjb3JlLmhjIjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgVGhlIHNlY29uZCBleGFtcGxlIC0gYWxzbyBvbiB0 aGUgQ29BUCBzaWRlIG9mIHRoZSBIQyBwcm94eSAtIHVzZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBvICBUaGUgc2Vjb25kIGV4YW1wbGUgLSBhbHNvIG9uIHRoZSBDb0FQIHNp ZGUgb2YgdGhlIEhDIHByb3h5IC0gdXNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBhIGN1c3RvbSB0ZW1wbGF0ZSwgaS5lLiwgb25l IHdoZXJlIHRoZSBDb0FQIFVSSSBpcyBjYXJyaWVkIGluc2lkZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIGEgY3VzdG9tIHRlbXBsYXRlLCBpLmUuLCBvbmUgd2hlcmUgdGhl IENvQVAgVVJJIGlzIGNhcnJpZWQgaW5zaWRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRoZSBxdWVyeSBjb21wb25lbnQsIHRodXMg dGhlIHJldHVybmVkIGxpbmsgY2FycmllcyB0aGUgVVJJPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgdGhlIHF1ZXJ5IGNvbXBvbmVudCwgdGh1cyB0aGUgcmV0dXJuZWQgbGlu ayBjYXJyaWVzIHRoZSBVUkk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgdGVtcGxhdGUgdG8gYmUgdXNlZCBpbiBhbiBleHBsaWNpdCAi aGN0IiBhdHRyaWJ1dGU6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdGVt cGxhdGUgdG8gYmUgdXNlZCBpbiBhbiBleHBsaWNpdCAiaGN0IiBhdHRyaWJ1dGU6PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgUmVxOiAgR0VUIGNvYXA6Ly9bZmYwMjo6MV0vLndl bGwta25vd24vY29yZT9ydD1jb3JlLmhjPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgIFJlcTogIEdFVCBjb2FwOi8vW2ZmMDI6OjFdLy53ZWxsLWtub3duL2NvcmU/cnQ9Y29y ZS5oYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlczogIDIuMDUgQ29udGVu dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBSZXM6ICAyLjA1IENvbnRl bnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE5IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAg ICAgICZsdDsvaGMmZ3Q7O2FuY2hvcj0iaHR0cDovL3AuZXhhbXBsZS5jb20iOzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgJmx0Oy9oYzxzcGFuIGNsYXNzPSJp bnNlcnQiPi88L3NwYW4+Jmd0OzthbmNob3I9Imh0dHA6Ly9wLmV4YW1wbGUuY29tIjs8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgIHJ0PSJjb3JlLmhjIjtoY3Q9Ij91cmk9eyt0dX0iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgIHJ0PSJjb3JlLmhjIjtoY3Q9Ij91cmk9eyt0dX0iPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPbiB0aGUgSFRUUCBzaWRlLCBsaW5rIGluZm9ybWF0 aW9uIGNhbiBiZSBzZXJpYWxpemVkIGluIG1vcmUgdGhhbiBvbmU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBPbiB0aGUgSFRUUCBzaWRlLCBsaW5rIGluZm9ybWF0aW9uIGNhbiBi ZSBzZXJpYWxpemVkIGluIG1vcmUgdGhhbiBvbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2F5OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHdheTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIHVzaW5n IHRoZSAnYXBwbGljYXRpb24vbGluay1mb3JtYXQnIGNvbnRlbnQgdHlwZTo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICB1c2luZyB0aGUgJ2FwcGxpY2F0aW9uL2xpbmstZm9y bWF0JyBjb250ZW50IHR5cGU6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgUmVx OiAgR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUuaGMgSFRUUC8xLjE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVxOiAgR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0 PWNvcmUuaGMgSFRUUC8xLjE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgIEhvc3Q6IHAuZXhhbXBsZS5jb208L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgSG9zdDogcC5leGFtcGxlLmNvbTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlczogIEhUVFAvMS4xIDIwMCBPSzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBSZXM6ICBIVFRQLzEuMSAyMDAg T0s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vbGluay1mb3JtYXQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi9saW5rLWZvcm1hdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgQ29udGVudC1MZW5ndGg6IDE4PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgIENvbnRlbnQtTGVuZ3RoOiAxODwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDIwIiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICZsdDsvaGMmZ3Q7O3J0PSJjb3JlLmhjIjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgJmx0Oy9oYzxzcGFu IGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+Jmd0OztydD0iY29yZS5oYyI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG8gIHVzaW5nIHRoZSAnYXBwbGljYXRpb24vbGluay1mb3JtYXQranNv bicgY29udGVudCB0eXBlIGFzIGRlZmluZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvICB1c2luZyB0aGUgJ2FwcGxpY2F0aW9uL2xpbmstZm9ybWF0K2pzb24nIGNvbnRlbnQg dHlwZSBhcyBkZWZpbmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIGluIFtJLUQuaWV0Zi1jb3JlLWxpbmtzLWpzb25dOjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGluIFtJLUQuaWV0Zi1jb3JlLWxpbmtzLWpz b25dOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlcTogIEdFVCAvLndlbGwt a25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgIFJlcTogIEdFVCAvLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAv MS4xPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICBIb3N0OiBwLmV4YW1wbGUuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgIEhvc3Q6IHAuZXhhbXBsZS5jb208L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICBSZXM6ICBIVFRQLzEuMSAyMDAgT0s8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgUmVzOiAgSFRUUC8xLjEgMjAwIE9LPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2xpbmstZm9ybWF0K2pzb248L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9s aW5rLWZvcm1hdCtqc29uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICBDb250ZW50LUxlbmd0aDogMzE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgQ29udGVudC1MZW5ndGg6IDMxPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjEiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgW3siaHJlZiI6Ii9oYyIsInJ0IjoiY29yZS5oYyJ9 XTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgW3siaHJlZiI6 Ii9oYzxzcGFuIGNsYXNzPSJpbnNlcnQiPi88L3NwYW4+IiwicnQiOiJjb3JlLmhjIn1dPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICB1c2luZyB0aGUgTGluayBoZWFkZXI6PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgdXNpbmcgdGhlIExpbmsgaGVhZGVyOjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIFJlcTogIEdFVCAvLndlbGwta25vd24v Y29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgIFJlcTogIEdFVCAvLndlbGwta25vd24vY29yZT9ydD1jb3JlLmhjIEhUVFAvMS4xPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICBIb3N0OiBwLmV4YW1wbGUuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgIEhvc3Q6IHAuZXhhbXBsZS5jb208L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICBSZXM6ICBIVFRQLzEuMSAyMDAgT0s8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgUmVzOiAgSFRUUC8xLjEgMjAwIE9LPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAyMiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICBMaW5rOiAmbHQ7L2hjJmd0 OztydD0iY29yZS5oYyI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAg ICAgIExpbms6ICZsdDsvaGM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4vPC9zcGFuPiZndDs7cnQ9ImNv cmUuaGMiPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgTWVkaWEgVHlwZSBNYXBwaW5n PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIE1lZGlhIFR5cGUgTWFwcGluZzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4xLiAgT3ZlcnZpZXc8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij42LjEuICBPdmVydmlldzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQSBIQyBwcm94eSBuZWVkcyB0byB0cmFuc2xhdGUgSFRUUCBtZWRpYSB0eXBlcyAoU2Vj dGlvbiAzLjEuMS4xIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSBIQyBw cm94eSBuZWVkcyB0byB0cmFuc2xhdGUgSFRUUCBtZWRpYSB0eXBlcyAoU2VjdGlvbiAzLjEuMS4x IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtSRkM3MjMxXSkgYW5kIGNvbnRlbnQgZW5jb2RpbmdzIChTZWN0aW9uIDMuMS4yLjIgb2Yg W1JGQzcyMzFdKSBpbnRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzcy MzFdKSBhbmQgY29udGVudCBlbmNvZGluZ3MgKFNlY3Rpb24gMy4xLjIuMiBvZiBbUkZDNzIzMV0p IGludG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQ29BUCBjb250ZW50IGZvcm1hdHMgKFNlY3Rpb24gMTIuMyBvZiBbUkZDNzI1Ml0pIGFu ZCB2aWNlIHZlcnNhLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvQVAgY29u dGVudCBmb3JtYXRzIChTZWN0aW9uIDEyLjMgb2YgW1JGQzcyNTJdKSBhbmQgdmljZSB2ZXJzYS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1lZGlhIHR5cGUgdHJhbnNsYXRpb24gY2Fu IGhhcHBlbiBpbiBHRVQsIFBVVCBvciBQT1NUIHJlcXVlc3RzIGdvaW5nPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgTWVkaWEgdHlwZSB0cmFuc2xhdGlvbiBjYW4gaGFwcGVuIGlu IEdFVCwgUFVUIG9yIFBPU1QgcmVxdWVzdHMgZ29pbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRk PjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDciIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDI2LCBsaW5lIDEzPC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEg bmFtZT0icGFydC1yNyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMjYsIGxpbmUgMTM8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF0dHJp YnV0ZSBWYWx1ZTogY29yZS5oYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF0 dHJpYnV0ZSBWYWx1ZTogY29yZS5oYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEZXNjcmlwdGlvbjogSFRUUCB0byBDb0FQIG1hcHBpbmcg YmFzZSByZXNvdXJjZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEZXNjcmlw dGlvbjogSFRUUCB0byBDb0FQIG1hcHBpbmcgYmFzZSByZXNvdXJjZS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFJlZmVyZW5jZTogU2VlIFNlY3Rpb24gNS41LjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlZmVyZW5jZTogU2VlIFNlY3Rpb24gNS41LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OS4yLiAgTmV3ICdjb2FwLXBheWxvYWQnIEludGVybmV0IE1l ZGlhIFR5cGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij45LjIuICBOZXcgJ2NvYXAt cGF5bG9hZCcgSW50ZXJuZXQgTWVkaWEgVHlwZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSAiYXBwbGljYXRpb24vY29hcC1wYXlsb2FkIiBt ZWRpYSB0eXBlIHdpdGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhlICJhcHBsaWNhdGlvbi9jb2FwLXBheWxvYWQiIG1lZGlhIHR5cGUg d2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBhIHNpbmdsZSBwYXJhbWV0ZXIgImNmIi4gIFRoaXMgbWVkaWEgdHlwZSByZXByZXNlbnRz IGFueSBwYXlsb2FkIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhIHNp bmdsZSBwYXJhbWV0ZXIgImNmIi4gIFRoaXMgbWVkaWEgdHlwZSByZXByZXNlbnRzIGFueSBwYXls b2FkIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgYSBDb0FQIG1lc3NhZ2UgY2FuIGNhcnJ5LCBoYXZpbmcgYSBjb250ZW50IGZvcm1h dCB0aGF0IGNhbiBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGEgQ29BUCBt ZXNzYWdlIGNhbiBjYXJyeSwgaGF2aW5nIGEgY29udGVudCBmb3JtYXQgdGhhdCBjYW4gYmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk PjxhIG5hbWU9ImRpZmYwMDIzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaWRlbnRpZmllZCBi eSBhIENvQVAgQ29udGVudC1Gb3JtYXQgcGFyYW1ldGVyIDxzcGFuIGNsYXNzPSJkZWxldGUiPihh biBpbnRlZ2VyIGluIHJhbmdlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBpZGVudGlmaWVkIGJ5IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmFuIGludGVnZXIgaW4gcmFu Z2UgMC02NTUzNSBjb3JyZXNwb25kaW5nIHRvPC9zcGFuPiBhIENvQVA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICAwLTY1NTM1KS48L3NwYW4+ICBUaGUgcGFyYW1ldGVyICJjZiIgaXMgdGhlIGludGVn ZXIgZGVmaW5pbmcgdGhlIENvQVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg Q29udGVudC1Gb3JtYXQgcGFyYW1ldGVyIDxzcGFuIGNsYXNzPSJpbnNlcnQiPihbUkZDNzI1Ml0s IFNlY3Rpb24gMTIuMikuPC9zcGFuPiAgVGhlIHBhcmFtZXRlcjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGNvbnRlbnQgZm9ybWF0Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAiY2YiIGlzIHRoZSBpbnRlZ2VyIGRl ZmluaW5nIHRoZSBDb0FQIGNvbnRlbnQgZm9ybWF0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVHlwZSBuYW1lOiBhcHBsaWNhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFR5cGUgbmFtZTogYXBwbGljYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFN1YnR5cGUgbmFtZTogY29hcC1wYXlsb2FkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgU3VidHlwZSBuYW1lOiBjb2FwLXBheWxvYWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFJlcXVpcmVkIHBhcmFtZXRlcnM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgUmVxdWlyZWQgcGFyYW1ldGVyczo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGNmIC0gQ29BUCBDb250ZW50LUZvcm1hdCBpbnRlZ2VyIGluIHJhbmdlIDAtNjU1MzUgZGVu b3RpbmcgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2YgLSBDb0FQIENv bnRlbnQtRm9ybWF0IGludGVnZXIgaW4gcmFuZ2UgMC02NTUzNSBkZW5vdGluZyB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udGVu dCBmb3JtYXQgb2YgdGhlIENvQVAgcGF5bG9hZCBjYXJyaWVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGNvbnRlbnQgZm9ybWF0IG9mIHRoZSBDb0FQIHBheWxvYWQgY2Fycmll ZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0 ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw4IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxlbT4gcGFnZSAyOSwgbGluZSA0MzwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxh IG5hbWU9InBhcnQtcjgiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVt PiBwYWdlIDI5LCBsaW5lIDQzPC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBN aXRpZ2F0aW9uOiBpbXBsZW1lbnQgYSBIVFRQUy1vbmx5IGludGVyZmFjZSwgd2hpY2ggbWFrZXMg dGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgTWl0aWdhdGlvbjogaW1w bGVtZW50IGEgSFRUUFMtb25seSBpbnRlcmZhY2UsIHdoaWNoIG1ha2VzIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUYXJnZXQg Q29BUCBVUkkgdG90YWxseSBvcGFxdWUgdG8gYSBwYXNzaXZlIGF0dGFja2VyLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRhcmdldCBDb0FQIFVSSSB0b3RhbGx5IG9wYXF1 ZSB0byBhIHBhc3NpdmUgYXR0YWNrZXIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMS4g IEFja25vd2xlZGdlbWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMS4gIEFj a25vd2xlZGdlbWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFuIGluaXRpYWwg dmVyc2lvbiBvZiBUYWJsZSAyIGluIFNlY3Rpb24gNyBoYXMgYmVlbiBwcm92aWRlZCBpbjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFuIGluaXRpYWwgdmVyc2lvbiBvZiBUYWJs ZSAyIGluIFNlY3Rpb24gNyBoYXMgYmVlbiBwcm92aWRlZCBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXZpc2lvbiAtMDUgb2YgdGhl IENvUkUgQ29BUCBJLUQuICBTcGVjaWFsIHRoYW5rcyB0byBQZXRlciB2YW4gZGVyPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmV2aXNpb24gLTA1IG9mIHRoZSBDb1JFIENvQVAg SS1ELiAgU3BlY2lhbCB0aGFua3MgdG8gUGV0ZXIgdmFuIGRlcjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBTdG9rIGZvciBjb3VudGxlc3Mg Y29tbWVudHMgYW5kIGRpc2N1c3Npb25zIG9uIHRoaXMgZG9jdW1lbnQsIHRoYXQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTdG9rIGZvciBjb3VudGxlc3MgY29tbWVudHMgYW5k IGRpc2N1c3Npb25zIG9uIHRoaXMgZG9jdW1lbnQsIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udHJpYnV0ZWQgdG8gaXRzIGN1 cnJlbnQgc3RydWN0dXJlIGFuZCB0ZXh0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGNvbnRyaWJ1dGVkIHRvIGl0cyBjdXJyZW50IHN0cnVjdHVyZSBhbmQgdGV4dC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyNCIgLz48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIFRoYW5rcyB0byBDYXJzdGVuIEJvcm1hbm4sIDxzcGFuIGNsYXNzPSJk ZWxldGUiPlphY2ggU2hlbGJ5LCBNaWNoZWxlIFJvc3NpLCBOaWNvbGEgQnVpLDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhhbmtzIHRvIDxzcGFuIGNsYXNzPSJp bnNlcnQiPkFiaGlqYW4gQmhhdHRhY2hhcnl5YSwgQnJpYW4gRnJhbmssPC9zcGFuPiBDYXJzdGVu IEJvcm1hbm4sPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgTWljaGVsZSBab3J6aSwgS2xhdXMgSGFy dGtlLDwvc3Bhbj4gQ3VsbGVuIEplbm5pbmdzLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5LZXBlbmcg TGksIEJyaWFuIEZyYW5rLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Q2hyaXN0aWFuIEFtc3VzcywgQ2hyaXN0aWFuIEdyb3Zl cyw8L3NwYW4+IEN1bGxlbiBKZW5uaW5ncywgRG9yb3RoeSBHZWxsZXJ0LDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgIFBldGVyIFNhaW50LUFuZHJlLCBLZXJyeSBMeW5uLCBMaW55aSBUaWFuLDwvc3Bh bj4gRG9yb3RoeSBHZWxsZXJ0LCBGcmFuY2VzY288L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgRnJhbmNlc2NvIENvcmF6emEsIEhhbm5lcyBUc2Nob2ZlbmlnLCBKYWltZSBKaW1l bmV6LCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5LZXBlbmcgTGksIEtlcnJ5PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIENvcmF6 emEsIEhhbm5lcyBUc2Nob2ZlbmlnLCBKYWltZSBKaW1lbmV6LCA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5BYmhpamFuIEJoYXR0YWNoYXJ5eWEgYW5kPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBMeW5uLCBLbGF1cyBIYXJ0a2UsIExp bnlpIFRpYW4sIE1pY2hlbGUgUm9zc2ksIE1pY2hlbGUgWm9yemksIE5pY29sYTwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBDaHJpc3RpYW4gR3JvdmVzPC9zcGFuPiBmb3IgaGVscGZ1bCBj b21tZW50cyBhbmQgZGlzY3Vzc2lvbnMgdGhhdCBoYXZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEJ1aSwgUGV0ZXIgU2FpbnQtQW5kcmUs IFphY2ggU2hlbGJ5PC9zcGFuPiBmb3IgaGVscGZ1bCBjb21tZW50cyBhbmQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzaGFwZWQgdGhl IGRvY3VtZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBkaXNjdXNzaW9u cyB0aGF0IGhhdmUgc2hhcGVkIHRoZSBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFRoZSByZXNlYXJjaCBsZWFkaW5nIHRvIHRoZXNlIHJlc3VsdHMgaGFzIHJlY2VpdmVk IGZ1bmRpbmcgZnJvbSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUg cmVzZWFyY2ggbGVhZGluZyB0byB0aGVzZSByZXN1bHRzIGhhcyByZWNlaXZlZCBmdW5kaW5nIGZy b20gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEV1cm9wZWFuIENvbW11bml0eSdzIFNldmVudGggRnJhbWV3b3JrIFByb2dyYW1tZSBb RlA3LzIwMDctMjAxM108L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFdXJvcGVh biBDb21tdW5pdHkncyBTZXZlbnRoIEZyYW1ld29yayBQcm9ncmFtbWUgW0ZQNy8yMDA3LTIwMTNd PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHVuZGVyIGdyYW50IGFncmVlbWVudCBuLjI1MTU1Ny48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB1bmRlciBncmFudCBhZ3JlZW1lbnQgbi4yNTE1NTcuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEyLjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEyLjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0kt RC5pZXRmLWNvcmUtYmxvY2tdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0kt RC5pZXRmLWNvcmUtYmxvY2tdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBu YW1lPSJwYXJ0LWw5IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4g cGFnZSAzMiwgbGluZSAxNDwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjki IC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDMyLCBsaW5l IDE0PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgW1JGQzczOTBdICBSYWhtYW4sIEEuLCBFZC4gYW5kIEUuIERpamssIEVkLiwg Ikdyb3VwIENvbW11bmljYXRpb24gZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgW1JGQzczOTBdICBSYWhtYW4sIEEuLCBFZC4gYW5kIEUuIERpamssIEVkLiwgIkdyb3VwIENv bW11bmljYXRpb24gZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFBy b3RvY29sIChDb0FQKSIsIFJGQyA3MzkwLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KSIsIFJGQyA3MzkwLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3MzkwLCBPY3RvYmVyIDIw MTQsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBET0kgMTAu MTc0ODcvUkZDNzM5MCwgT2N0b2JlciAyMDE0LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICZsdDtodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNzM5MCZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm YzczOTAmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QXBwZW5kaXggQS4gIENoYW5n ZSBMb2c8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BcHBlbmRpeCBBLiAgQ2hhbmdl IExvZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW05vdGUgdG8gUkZDIEVkaXRvcjog UGxlYXNlIHJlbW92ZSB0aGlzIHNlY3Rpb24gYmVmb3JlIHB1YmxpY2F0aW9uLl08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbTm90ZSB0byBSRkMgRWRpdG9yOiBQbGVhc2UgcmVt b3ZlIHRoaXMgc2VjdGlvbiBiZWZvcmUgcHVibGljYXRpb24uXTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDI1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQi PkNoYW5nZXMgZnJvbSBpZXRmLTEyIHRvIGlldGYtMTMgKENocmlzdGlhbiBBbXN1c3MnIGNvbW1l bnRzKTo8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgbyAgTW9yZSBtaXNzaW5nIHNsYXNoZXMgaW4gVVJJIG1hcHBpbmcg dGVtcGxhdGUgZXhhbXBsZXMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIENoYW5nZXMgZnJvbSBpZXRmLTExIHRvIGlldGYtMTIgKDJuZCBX R0xDKTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDaGFuZ2VzIGZyb20gaWV0 Zi0xMSB0byBpZXRmLTEyICgybmQgV0dMQyk6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICBBZGRyZXNzZWQgYSBmZXcgZWRpdG9yaWFsIGlzc3VlcyAoaW5jbHVkaW5nIGEgY2xhcmlm aWNhdGlvbiBvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEFkZHJlc3Nl ZCBhIGZldyBlZGl0b3JpYWwgaXNzdWVzIChpbmNsdWRpbmcgYSBjbGFyaWZpY2F0aW9uIG9uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IHdoZW4gdG8gdXNlIHFxIHZzIHEgaW4gdGhlIFVSSSBtYXBwaW5nIHRlbXBsYXRlKS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB3aGVuIHRvIHVzZSBxcSB2cyBxIGluIHRo ZSBVUkkgbWFwcGluZyB0ZW1wbGF0ZSkuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBv ICBGaXhlZCBtaXNzaW5nIHNsYXNoIGluIG9uZSB0ZW1wbGF0ZSBleGFtcGxlLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEZpeGVkIG1pc3Npbmcgc2xhc2ggaW4gb25lIHRl bXBsYXRlIGV4YW1wbGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBBZGRlZCBw YXJhIGFib3V0IHRoZSBuZWVkIGZvciBmdXR1cmUgQ29BUCBwcm90b2NvbCBlbGVtZW50cyB0bzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEFkZGVkIHBhcmEgYWJvdXQgdGhl IG5lZWQgZm9yIGZ1dHVyZSBDb0FQIHByb3RvY29sIGVsZW1lbnRzIHRvPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGRlZmluZSB0aGVp ciBvd24gSFRUUCBtYXBwaW5ncy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBkZWZpbmUgdGhlaXIgb3duIEhUVFAgbWFwcGluZ3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+Cgog ICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRo IGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVuZCI+Jm5ic3A7RW5kIG9mIGNo YW5nZXMuIDI1IGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwvdGg+PC90cj4KICAgICA8dHIgY2xh c3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+MzIgbGluZXMgY2hhbmdlZCBvciBkZWxldGVkPC9p PjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MzUgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwv aT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2Vu dGVyIiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJm Y2RpZmYgMS40Mi4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9 Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi8iID5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90YWJsZT4KICAgPC9i b2R5PgogICA8L2h0bWw+Cg== --_002_D3B518B96E345thomasfossatialcatellucentcom_-- From nobody Wed Jul 20 05:14:34 2016 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 C5AD312DBB0; Wed, 20 Jul 2016 05:14:32 -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 N768TmL4siHE; Wed, 20 Jul 2016 05:14:31 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A047412DBB9; Wed, 20 Jul 2016 05:14:30 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-15-578f6b24c180 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.F0.18043.42B6F875; Wed, 20 Jul 2016 14:14:28 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.150]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 14:14:27 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: SenML values and extensions in SenML Records Thread-Index: AQHR4oBCJUt9d1QCCkmFgFLTGNj39Q== Date: Wed, 20 Jul 2016 12:14:27 +0000 Message-ID: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@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: <2343BA2169C56D4385E22F1BDDAED3AD@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdT1cluz/coOOMiMW+t+uZLX6+W8Ls wOSxZMlPpgDGKC6blNSczLLUIn27BK6MlcvesRbMZKvYeXk3cwPjN5YuRk4OCQETideHvzJB 2GISF+6tZ+ti5OIQEjjCKHFz+ip2CGcJo8TMMy/AqtgE7CUmr/nICGKLCEhIdH7dzw5iMwu4 SvxeexMsLixgKnH+5l7mLkYOoBoriTW7LCDK9SQetjazgtgsAqoSJ6fdARvJCzTy/fM+MJsR 6Ijvp9YwQYwUl7j1ZD7UcQISS/acZ4awRSVePv7HCmErSaw9vJ0Fol5P4sbUKWwQtrXEgWcb oWxtiWULXzND7BKUODnzCcsERtFZSFbMQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSkl1qU mVxcnJ+nl5dasokRGDUHt/y22sF48LnjIUYBDkYlHl6F233hQqyJZcWVuYcYJTiYlUR4mVL6 w4V4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwrn7iFuW9 2KlxnsO7xHNMGdYvBTdIhZ805appXNbVpCjsLPQ2ZGb1+XSV9AmH+xmDJTYJn99SZ2bQZrvS o/nEZIuIK9qf+WNVXR/aqqw0Fl3CmCRzMMz/jvSvg09CX3N+3rrIMtHorMW/5DNHa2//LQpq 3rOzz5S1xiWJI8zfO0EgSdHF4ZISS3FGoqEWc1FxIgAk+D1clgIAAA== Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: [core] SenML values and extensions in SenML Records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 12:14:33 -0000 Hi, We are considering small changes to SenML draft to clarify use of values in= SenML Records and to facilitate value extensions. Currently the draft says that there must be exactly one of the defined valu= e labels {v, vb, vd, vs} in each SenML record unless there's a sum value. H= owever, if in future we define a new value label, currently it would mean y= ou could not have that alone in a Record. Therefore, we are suggesting to relax that rule to say that exactly one val= ue label (defined in the SenML document or in some future document) must be= in each record. The proposed text change can be seen in pull request #22: https://github.com/core-wg/senml-spec/pull/22/files Is anyone against doing this change? Other comments welcome too. Cheers, Ari From nobody Wed Jul 20 05:42:27 2016 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 51EF912D5F9; Wed, 20 Jul 2016 05:42:26 -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 KjMqdBVOU6Ar; Wed, 20 Jul 2016 05:42:23 -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 3924112D58A; Wed, 20 Jul 2016 05:42:23 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6045942F50; Wed, 20 Jul 2016 14:42:21 +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 7ED5B4A; Wed, 20 Jul 2016 14:42:19 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0685644; Wed, 20 Jul 2016 14:42:18 +0200 (CEST) Received: (nullmailer pid 29393 invoked by uid 1000); Wed, 20 Jul 2016 12:42:17 -0000 Date: Wed, 20 Jul 2016 14:42:17 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20160720124217.GF26784@hephaistos.amsuess.com> References: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qoTlaiD+Y2fIM3Ll" Content-Disposition: inline In-Reply-To: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@ericsson.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML values and extensions in SenML Records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 12:42:26 -0000 --qoTlaiD+Y2fIM3Ll Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 12:14:27PM +0000, Ari Ker=E4nen wrote: > Currently the draft says that there must be exactly one of the defined va= lue labels {v, vb, vd, vs} in each SenML record unless there's a sum value.= However, if in future we define a new value label, currently it would mean= you could not have that alone in a Record. >=20 > Therefore, we are suggesting to relax that rule to say that exactly one v= alue label (defined in the SenML document or in some future document) must = be in each record. The proposed text change can be seen in pull request #22: > https://github.com/core-wg/senml-spec/pull/22/files >=20 > Is anyone against doing this change? Other comments welcome too. I'm in favor of this change for your reasons but also due to a suggestion I'm currently writing up -- but to make it short: To accomodate streaming parsing, the current draft is much better than what we had last year, but parsers still need to seek around a little because a bn/bt can be after a n/t. If we made them mutually exclusive (either bn or n, either bt or t), the 30-byte-state-parser (which includes relative URI resolution) becomes doable again. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --qoTlaiD+Y2fIM3Ll Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj3GmAAoJEDmNERLTpL3hYPYP/RDE572mnJhidZ7Sd8FR5G+J iUpiTkiUx/bDraIJFW0FMWAZ5aQyl59U1oTSlrd4naETGpQR9P3b9BFymF31WoTc ULTWtPAZ74vHE2SyzXSCTEPG5iQvCwzodjwRP5DhB4IlfiPpwZdMSL/OgMWiLXFX HlWG6lS6X/kFp/QfbqSCzHZOcx9IIVm+hNlGMQE19LE4vamc0a44dX31P6Imn0kT UBKQB4HQdNdIf3HanB/0wgplgioapBUGToUOHI3NcT+y33Tu+/YXH5P4ofNPGUie gNViixIOC4WFmFNdSfV5a7W7l4A4wNDCcLcddLEiCdnw1nN6JRegslfsSynLA48N 2fZ8tIocSlN46tA7Z7z/d8FohRyY8ltFMWOdl+5G3FLkMGIuP+1jcwGuWm5OA+UP XDvGdn589kT2lBQ06Nv7YZVHyOWMb6naOUMmrLuhSSVkrryguM4S9gPH+yL9zdau poC09ypfEarSvQuCf0DiJyoGhZip3En421+iyz0XvPOvHxNvyX+PVS19ixws5/c5 roH8YUmVaR/OnLP3xhmJi/J48KQKP/ISPFJXuxWI9WQp2Z5kUCHRVlO8YwPjQViF H2O/D64XuKeDUhI74HmCNdOSx7MaMgPk4So8/pxy/bbM8DqYLxIoGwoNEdfUaGe2 sO3NYJvylEc20mbyI3Pj =DIzm -----END PGP SIGNATURE----- --qoTlaiD+Y2fIM3Ll-- From nobody Wed Jul 20 05:57:22 2016 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 1AB0812DBE5 for ; Wed, 20 Jul 2016 05:57: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] 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 SxskbZCFstfT for ; Wed, 20 Jul 2016 05:57:19 -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 5BC1712DBB9 for ; Wed, 20 Jul 2016 05:57:19 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CB5F442F15 for ; Wed, 20 Jul 2016 14:57:17 +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 5E40F4A for ; Wed, 20 Jul 2016 14:57:16 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2184144 for ; Wed, 20 Jul 2016 14:57:16 +0200 (CEST) Received: (nullmailer pid 31744 invoked by uid 1000); Wed, 20 Jul 2016 12:57:14 -0000 Date: Wed, 20 Jul 2016 14:57:14 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core Message-ID: <20160720125714.GG26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="smOfPzt+Qjm5bNGJ" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: [core] SenML nit: data value in CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 12:57:21 -0000 --smOfPzt+Qjm5bNGJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello list, I think that the current SenML draft is missing a note on JSON/CBOR differences in Data Value: While it is explicitly stated that vd is a base64 string in JSON and a binary-value in CBOR, the supposedly exhaustive list of differences in 6. fails to mention that no base64 encoding is done in CBOR. Suggested addition: o For Data Values, no base64url-encoding is done, as the data can be directly expressed as binary-value. Furthermore, I suggest that "Characters in the Data Value are base64 encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", to make the distinction to the character-based strings and binary data clearer. (The only context in which I'd name bytes of binary data "Character" are when speaking of a "char" in C). Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --smOfPzt+Qjm5bNGJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj3UmAAoJEDmNERLTpL3hyR0P/R1aP2pLPc013bupSgd5ZOWg 3dy8aGnhUrTRrGd8AIUmX//aXwdKPt1sAyfrHk+5MSf9yzMMSGzX5c7MlVlfRdoS GIj3Y0ZosQrXCvel7/9PRpzvdhvYv0d3tHIdMjFEZEWpnCAuvPPumW/WcCQqCNlt GUx5FLcxhBsqlff19hRXVk9D/zHtD+GeZMIEFb3nq+nvo//CLa23pvUzggDV1Owy wknh3/RELDYQ/1815tOJHDLrZzZE4zyFCj6ttOIinCDRl23x+gEMwxzE1f9FlsQN s3zgVKSgAMUIiYfFlzdL09+xqVMa9wGulNhn2xiyaJ6qaTxGYE0+KpIT9nDFDHa6 kK5kxMT5nPL9YVajXgJ9kL4Mbbqah5fgJja+glBu+ys+3DLX62bMmSGLpBn5uVeT feV1YVDZZfIeoOJZpUUTWto6QPiMzpm3kgURqyaKsvin7XuHsKvJeH0OlZn3ooow 41wvxPzMCKI3EMpteK5UHRFXctrJvkvVRVnRWyIxFkGmoyxgC+GHTkv2xHtVSO/f vBolYLc14Vr37lgbKqSfCCD2WGJklnwTQCFYORfJ3/plJvjxqI7w4XQo/v+/8eQs OtrF3Xm3P7K1SDJwCFRMc/AoSYpiQOjoqrkeLKscNJc4WWBsdvYrnKHAslE6+1oe IpkQGTugBsZK4W2AlHgy =f1nW -----END PGP SIGNATURE----- --smOfPzt+Qjm5bNGJ-- From nobody Wed Jul 20 06:19:44 2016 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 1E40E12D63F for ; Wed, 20 Jul 2016 06:19: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 8TPyNUkfVomV for ; Wed, 20 Jul 2016 06:19:41 -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 19BAD12D5D3 for ; Wed, 20 Jul 2016 06:19:41 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3AA8B42F11 for ; Wed, 20 Jul 2016 15:19:39 +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 F18E54A for ; Wed, 20 Jul 2016 15:19:36 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A9E1144 for ; Wed, 20 Jul 2016 15:19:36 +0200 (CEST) Received: (nullmailer pid 4052 invoked by uid 1000); Wed, 20 Jul 2016 13:19:35 -0000 Date: Wed, 20 Jul 2016 15:19:35 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" Message-ID: <20160720131935.GK7974@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dzI2QqkSBOAresgT" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: [core] SenML suggestions 1/3: Object Values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 13:19:43 -0000 --dzI2QqkSBOAresgT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone interested in SenML, I'd like to bring up again three suggestions for SenML which all already been on the list, but were not followed up on. In the interest of thread followability, I'll send them in separate mails. As a preamble, I'd like to state that some of this reflects the notion that SenML can be used to convey not only sensor data, but as a generic way of transporting representations of multiple resources in a single request. First, object values. SenML extensions like the "l" attribute for links show the need for having structured data in extensions. The data transported with this SenML extension can be viewed as a representation of a resource (in particular the link-format representation of the batch IIRC), and could thus just as well go into a SenML record's value. In order to avoid nesting JSON, it would be practical to allow a new value-like property, "vo", to be an object value, which would be deeper JSON. (For "sv"/"bv"/"v", the point has been made that some JSON parsing mechanisms expect every recognized key to have a pre-specified type; if that's at all an issue here, it might need splitting into "va" (array value) and "vo" (object value in the sense of a JSON "object" (dictionary)). Inside a REST client or server, such a representation would appear pre-parsed -- it in an API, an object would be passed instead of a string. If this sounds odd to you, beware that this is already happening: JSON strings are unicode character strings, so any REST engine that allows a resource to be handled both as text/plain;charset=3Dutf-8 and as part of a SenML batch already needs to handle byte strings and character strings (though that may be invisible as JSON libraries are commonly dealing with UTF-8 encoded byte strings for practical reasons). The same scheme would work for CBOR in a straightforward way. While something like that would probably be feasible in XML with namespaces and such, I don't think it's worth the hassle, especially given that the whole XML/EXI serialization might be dropped in favor of a generic XML serialization of JSON. Converters that have no dedicated knowledge of what to do with the "vo" data should just pack the JSON into a string and put that as a string value. (Which would *not* roundtrip, but roundtrippability in conversion is something I'm not sure we have anyway given CBOR's extended capabilities). I do not currently have use cases for this myself, but I think that it allows the hypermedia things to mix their results into SenML in a much more straightforward way. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --dzI2QqkSBOAresgT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj3pkAAoJEDmNERLTpL3hZL0P/00AwFeoSzRAnvrc/3GLvfPt QVkkERD0GaQOGS+lG3uJ0jYA+bLjpFZ7C88TsX7s/H6BlAl30nbXPLJ4c5oxCZkg NMg7kp11cYig1p/aeNSpqmSvJ87WjB6DowRnfK+dvXmQHVC6Ib686IwQ22dcXE4K wRvPtn192LkJdNE2+gPThDQuqZ7Vn4zv9dVgNdSKn0+E+1+mGHd4NrIwpPLqnQlI eP6LbRDIqCUamjTc0dqgkGMsxv08BZp6fTZ5W3O0XvWeZQRhwAsqeC+mKw7MX5pb fuQzht4rYWncvWtqz7DYbUvgILM7BFCiJzVUul1k4XMjncLHCmUzuRHirEEpwYlf QZ1xfRM5z3yyPrysSaMa1awG/sm2TFi6+phHH1L+oQ65Q7Xd2vFiWIUrYRMMm34P 5IwE/5PExqFf4sAMV5J+xeAaZ0Jh+ZMpofqRbdeG1lw2hkGkW45INIePWcmtJYTw C6flndcZnLeguVXmGIbjdDNrSqCsJaLxnZgNXo6eZ7wL8nqBhxviLIM2iTPK69kh qzb38v+2LJVpiOaVzwuB1sJ2VgXJI1YljKhiQDBTLU5AlbXziE9EPVgnLhO3JNQu lOxd4evCMMOQhY5ehHkvjrhLXUg7VYssUrJD3ORKW2OSBLjxFCHbultSL6IVw0hB SJNU6vYyRRmTQz/iowAq =agrh -----END PGP SIGNATURE----- --dzI2QqkSBOAresgT-- From nobody Wed Jul 20 06:22:49 2016 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 5101412D130 for ; Wed, 20 Jul 2016 06:22:47 -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 OrKKnmYm9Cwe for ; Wed, 20 Jul 2016 06:22: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 3DEBB12D66C for ; Wed, 20 Jul 2016 06:22:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 93F4342F1D for ; Wed, 20 Jul 2016 15:22: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 CF34A4A for ; Wed, 20 Jul 2016 15:22:37 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9096944 for ; Wed, 20 Jul 2016 15:22:37 +0200 (CEST) Received: (nullmailer pid 4518 invoked by uid 1000); Wed, 20 Jul 2016 13:22:36 -0000 Date: Wed, 20 Jul 2016 15:22:36 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" Message-ID: <20160720132236.GL7974@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vxa5joy26gVGOrvU" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: [core] SenML suggestions 2/3: Content Format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 13:22:47 -0000 --Vxa5joy26gVGOrvU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone interested in SenML, (for introduction, see the 1/3 mail) Second, content types. When multiple resources' representations are sent in a batch, the client loses the information otherwise present in the Content-Format header GET /light/1 -> 2.05, Content-Format=3D0 (text/plain), "1" GET /light/2 -> 2.05, Content-Format=3D0 (text/plain), "0" in the aggregation GET /light/ -> 2.05, Content-Format=3Dapplication/senml+json, [{"n":"1","v":1},{"n":2","v":0}] =2E This leaves the client to guess what to actually do with the "sv" strings. ("bv" and "v" booleans / numerics are a little odd here as this is a rare situation where a resource has such a representation; I don't see any harm there tough.) I suggest that a pair of "cf"/"bcf" (content format, base content format) be added with the usual "base" mechanism. Their values are an integer number (like in the Content-Format option or the ct=3D link-format parameter) or null, which is the default when neither bcf nor cf are present, and has the semantics of an absent Content-Format option. This is relevant in all situations when the transported content is not text/plain, and would allow removing ambiguity in SenML interpretation in a way that is widespread practice in unaggregated responses. (I've considered that strings for mime types might be an option here, and could be compressed between JSON and CBOR into the content formats of the CoRE world, but this would be the first time an embedded device would need to produce those, and should be avoided IMO.) Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --Vxa5joy26gVGOrvU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj3scAAoJEDmNERLTpL3hfhYP/1PVoJN7cqXApFCHt4W7AT7i Iz9d1YWOJZlPBF4JBJ1Efn6A/Lr91yyvvGOhHGJ2T0LGXt5467aXp2eLjI9tLFOW 48slceqwLQ3mJTI0hXQz9T/wcJQbK5vPYbTOS7n9O+Od5yxswJdQj+pXczfIxY44 FjRbK+QQNrAaCLUUZ3vIzA6w25kTY74ZHKxT82O2XWT/Yg71JhlCXuAw0k3sI+Ri 3TjTOdincOiiuhD+WMeE3831IfD9SWMNQWL7jroz4vN36MPcJsj105VMZ+uqRw+7 jkj5q7CJxQeRyDdbAAJYFYU7yRg6U7pf5IDKNZeRVLO26QKebaX6l7hsBmJKlGyS 2tpKgKu+wZ6l/qOo2d4/bMYzTnekgkvCJwL95C42LGGpDCNouOWvdBvrF6pV/nF8 eAgT5km71jXFJUo9yRpkCN47eSSE0+9za7PUw7yI8KZYZ6HnVIN9GDLXIMTlgrV6 Omxn8juC0fPIMqmxEbn1txiYpmj0k9lvbaUq129HmeFqEbqxODL0VU4UkKLgpqX9 hJrP/05Oszb7nvMD8VQDeqUEwkrm1yy2agDG30YqjJde3EC5f5xJ/KDXB/L9Z9ko gOrNph11IFXs2q7epWhHQ/+hPnZ8yE6iCQi9yrH4Ib9wFNfeF9+MfvCOl7nO9Qhp dWQS0kzx65JzK5Q79qAj =/IjO -----END PGP SIGNATURE----- --Vxa5joy26gVGOrvU-- From nobody Wed Jul 20 06:24:25 2016 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 A40E212D65E for ; Wed, 20 Jul 2016 06:24:23 -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 SVS4Atvuod6Y for ; Wed, 20 Jul 2016 06:24:22 -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 9D2F612D130 for ; Wed, 20 Jul 2016 06:24:21 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D70DD42F12 for ; Wed, 20 Jul 2016 15:24:19 +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 2D13D4A for ; Wed, 20 Jul 2016 15:24:19 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b310.meeting.ietf.org [31.133.179.16]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E195344 for ; Wed, 20 Jul 2016 15:24:18 +0200 (CEST) Received: (nullmailer pid 4788 invoked by uid 1000); Wed, 20 Jul 2016 13:24:17 -0000 Date: Wed, 20 Jul 2016 15:24:17 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" Message-ID: <20160720132417.GM7974@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9DptZICXTlJ7FQ09" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: [core] SenML suggestions 3/3: Streamability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 13:24:24 -0000 --9DptZICXTlJ7FQ09 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone interested in SenML, (for introduction, see the 1/3 mail). Third, streamability. As said in Ari's extended-values thread, streamability is now good but not yet perfect. (By streamability here I mean that consumers can process SenML in arbitrarily small or aligned chunks without the need for seeking back or buffering received data, and still grasp the document and set their state accordingly). With the -02 draft, a client would need to buffer roughly the first item (so it can parse the potentially-first "n" attribute in the context of the potentially-last "bn" attribute). Do you think it would be viable to require that a base attribute and its corresponding individual attribute be mutually exclusive in a record? That would allow streamability. I'd have them exclusive in a pairwise fashion; alternatively, an "either there's base or non-base attributes" would work for that use case just as well. Sorry for the data rate peak I'm sending here -- I wanted to make sure 1/3 and 2/3 are consistent with each other. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --9DptZICXTlJ7FQ09 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj3uBAAoJEDmNERLTpL3hz0sQAK/UJmrNGxyU7wLIFcAQtxGy VBBcqrjPCBrgWBmI8J8GRWe70rB8Jlf4fD6XZy2ufkn3KPogmY919rKRZOACRWAV XFw3WW9JhjffNEunvoSDn9TFp25U+HBRqvej8sAIeQzxM6I69KrhTpX1TyA9Tb30 QnEL2DuQGY40QwhJV7HbrDD8k15A9zGCkgdOuxkrjckZshNnOIE6jLEy/Vmque0q hwa+gRtzB3Kd+WkaMR729YfDZOjvGsX/EWC/aqm+vI3C7Bl5HDPNwjr/HmnXDKtE qwWLVU9/8L+jEZqCGd9ONEU+ivV0HNIwUbnmelkfe4rbFxbGy7aZe+GtWlAmeDBa 5SMkvs6OmuwAk6GRgGZdgUxJIIwwFfQF+mZbvygvyYH6iMHoqsfKgHaUNeXoAxw6 6XfcmbYxPMRCARNAp89OJQS2H2eUIN40sVik1oEF0JeVrX+MNcxLOF5+5SlCeuia 0BdzKTQVM3hDwVr9tlQd5dxnxqXJ2QZY1Zhm++vD9+x2H1YA/ZVsWvPqXZuo2on4 5so+eInueSFee+qzLdLlZxCSR8p1Oi08I6xIIhyel/IHm/mJuGz29PCoBdzsr16v Bf0wkLJqHNck4llQPS+ilnNDvhcrwKojphDlUFFP41YfIBFVdnMSICu0qPvOlhj0 diRvUBRNCm0FDPV0fI6L =thMq -----END PGP SIGNATURE----- --9DptZICXTlJ7FQ09-- From nobody Wed Jul 20 07:15:58 2016 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 7FE4E12D7C3; Wed, 20 Jul 2016 07:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQICmub0hQ9e; Wed, 20 Jul 2016 07:15:50 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1205C12D7B0; Wed, 20 Jul 2016 07:15:46 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-37-578f878f6e65 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.2C.27088.F878F875; Wed, 20 Jul 2016 16:15:45 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.150]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 16:15:43 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: SenML metadata label Thread-Index: AQHR4pEzX/PuJUNphkq8J4fvZtnYmQ== Date: Wed, 20 Jul 2016 14:15:42 +0000 Message-ID: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <94E93601E0196E4FADEE314DAA29C980@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9Sndie3+4QcsPTot9b9czW/x8t4TZ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZPSd+MxfcZ6loPXSfsYHxDnMXIyeHhICJxOSOmVC2 mMSFe+vZuhi5OIQEjjBKPN3zghnCWcIocXlZByNIFZuAvcTkNR/BbBEBCYnOr/vZQWxmAVeJ 32tvgsWFBWQlbm3/wgxRoyTx/M5LqHo9iXMtr1hAbBYBVYlVV9rZQGxeoJlPb0DUMwJd8f3U GiaImeISt57MZ4K4TkBiyZ7zUJeKSrx8/I8VwlaSWLH9EiNEvZ7EjalT2CBsa4kplw5D2doS yxa+ZobYJShxcuYTlgmMorOQrJiFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyEgvtSgzubg4 P08vL7VkEyMwbg5u+W2wg/Hlc8dDjAIcjEo8vAq3+8KFWBPLiitzDzFKcDArifCmtPaHC/Gm JFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamDM1OudJ2MRMqfM 5+wPqzXKJRVxmt/XrNzMvPWmfe3/rgU9v1fYGxpOXuS6IdS9J0F1dvv94jv7tV9qfZc/cuf5 +3qN0hDJp1NeSO3iWKqRuvlPf4OXBd/NjG0pJ+p+Bvzc0v/b9R/f3u6WKf9teT9NU3/7fN+T OQvmxBY9ub3SL+r8RRfBr39clViKMxINtZiLihMB9iFQQJcCAAA= Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: [core] SenML metadata label X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 14:15:56 -0000 Hi, Another proposed extension for SenML not yet in the draft is a "metadata" f= ield for SenML Records. This could be free-form UTF-8 text, like string val= ue (sv). Unlike sv, you can have this *and* a value. Use cases include "international names" that you can't use as part of "n" l= abel due to the URI compatible restriction, adding "tags" that describe you= r data, etc. This seems like a simple thing with reasonable trade-off between value and = extra complexity. We welcome proposals for the name and label of this thing. I'd suggest "met= adata" and "m". Cheers, Ari From nobody Wed Jul 20 07:27:18 2016 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 4667F12D818; Wed, 20 Jul 2016 07:27:17 -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 RNlvvnKfnb7V; Wed, 20 Jul 2016 07:27:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B2912D7BE; Wed, 20 Jul 2016 07:27:13 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-8f-578f8a3f371a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C1.FA.18043.F3A8F875; Wed, 20 Jul 2016 16:27:11 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.150]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 16:27:11 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: SenML base stride: time offset between records Thread-Index: AQHR4pLNlYGkq346k0y47fib3Y469Q== Date: Wed, 20 Jul 2016 14:27:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdSde+qz/c4MppDYsv7xtZLPa9Xc9s 8fPdEmYHZo8lS34yeaw4P5MlgCmKyyYlNSezLLVI3y6BK+PehMtsBQ85K/oaXrM0MM5k72Lk 4JAQMJHYeUGxi5ETyBSTuHBvPVsXIxeHkMARRonNV28yQjhLGCWmPdvEDlLFJmAvMXnNR0YQ W0RAQqLz636wOLNApcSzdS+ZQWxhAXOJk80nWCFqbCR+H5vGDGHrSWy+1wTWyyKgKvH94nIm EJsXaObdUy/B5jACXfH91BomiJniEreezGeCuE5AYsme88wQtqjEy8f/WCFsJYkV2y8xQtTr SdyYOoUNwraWWDBxDtQcbYllC18zQ+wSlDg58wnLBEbRWUhWzELSPgtJ+ywk7bOQtC9gZF3F KFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhJB7f8ttrBePC54yFGAQ5GJR5ehdt94UKsiWXF lbmHGCU4mJVEeLs7+sOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2C yTJxcEo1MFqG83Uf7Jx11YLB+2rPyb2HljqelF1gw2SUZOpQfF9WcVamofn8dXum6FRu+8a8 aN6FyrPrLOMU96rM5X5vqZsXkP62cWpnA9t/5763W1m9f376KFdwX/tWzfPdter8/LqXH9x9 ERvyrtdR/PHtO4bBs1NttTLedpuGKS7++OHWxTB5l8xeWyWW4oxEQy3mouJEAH+zIwGgAgAA Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: [core] SenML base stride: time offset between records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 14:27:17 -0000 Hi, Third suggestion we discussed recently with Christian (Cc'd) is to add a "b= ase time offset" or "base stride" parameter that allows eliding the time va= lue for measurements that have been done at equal intervals. So (slightly m= odifying Christian's original example), using currently defined format you = would have "bt": 1320067464, "bu": "%RH", "v": 21.2, "t": 0 }, { "v": 21.3, "t": 10 }, { "v": 21.4, "t": 20 }, { "v": 21.4, "t": 30 }, ... With "base stride" of 10 seconds, that would be "bt": 1320067464, "bs": 10, "bu": "%RH", "v": 21.2}, { "v": 21.3}, { "v": 21.4}, { "v": 21.4}, ... And of course the benefits become more apparent the more records you have. This does bring some complexity since you have to do some simple arithmetic= s based on the "index" of the record to find out the time for each SenML Re= cord. Also it's questionable how often the measurements are done in exact (= enough) time intervals. On the other hand, it reduces size of a Pack consid= erably in relatively common use case. I would suggest we include this feature in the next version of the SenML dr= aft. Opinions? Cheers, Ari From nobody Wed Jul 20 07:44:05 2016 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 2830112D7CC for ; Wed, 20 Jul 2016 07:44:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4eVl3Mjv4P5s for ; Wed, 20 Jul 2016 07:43:59 -0700 (PDT) Received: from smtp125.ord1c.emailsrvr.com (smtp125.ord1c.emailsrvr.com [108.166.43.125]) (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 0495712D80C for ; Wed, 20 Jul 2016 07:43:58 -0700 (PDT) Received: from smtp16.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2DD27C02AC; Wed, 20 Jul 2016 10:43:58 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 86401C0278; Wed, 20 Jul 2016 10:43:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-61-100-229.cisco.com ([UNAVAILABLE]. [173.38.220.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Wed, 20 Jul 2016 10:43:58 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 20 Jul 2016 16:43:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86E499A8-F09B-4D7A-8EF8-0267C4D39074@iii.ca> References: To: =?utf-8?Q?Ari_Ker=C3=A4nen?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML base stride: time offset between records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 14:44:04 -0000 I don=E2=80=99t feel supper strongly either way. It seems like a nice = feature but on the other hand I don=E2=80=99t want to just add a bunch = of incremental complexity. I guess I am weakly in favour of this.=20 > On Jul 20, 2016, at 4:27 PM, Ari Ker=C3=A4nen = wrote: >=20 > Hi, >=20 > Third suggestion we discussed recently with Christian (Cc'd) is to add = a "base time offset" or "base stride" parameter that allows eliding the = time value for measurements that have been done at equal intervals. So = (slightly modifying Christian's original example), using currently = defined format you would have >=20 > "bt": 1320067464, > "bu": "%RH", > "v": 21.2, "t": 0 }, > { "v": 21.3, "t": 10 }, > { "v": 21.4, "t": 20 }, > { "v": 21.4, "t": 30 }, > ... >=20 > With "base stride" of 10 seconds, that would be >=20 > "bt": 1320067464, > "bs": 10, > "bu": "%RH", > "v": 21.2}, > { "v": 21.3}, > { "v": 21.4}, > { "v": 21.4}, > ... >=20 > And of course the benefits become more apparent the more records you = have. >=20 > This does bring some complexity since you have to do some simple = arithmetics based on the "index" of the record to find out the time for = each SenML Record. Also it's questionable how often the measurements are = done in exact (enough) time intervals. On the other hand, it reduces = size of a Pack considerably in relatively common use case. >=20 > I would suggest we include this feature in the next version of the = SenML draft. >=20 > Opinions? >=20 >=20 > Cheers, > Ari >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jul 20 07:45:15 2016 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 90A6B12D7D4 for ; Wed, 20 Jul 2016 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 GvVqd5WyS9cJ for ; Wed, 20 Jul 2016 07:45:13 -0700 (PDT) Received: from smtp77.ord1c.emailsrvr.com (smtp77.ord1c.emailsrvr.com [108.166.43.77]) (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 3A4A812D7CC for ; Wed, 20 Jul 2016 07:45:13 -0700 (PDT) Received: from smtp18.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 878FEE030F; Wed, 20 Jul 2016 10:45:12 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp18.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F3D50E0302; Wed, 20 Jul 2016 10:45:11 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-61-100-229.cisco.com ([UNAVAILABLE]. [173.38.220.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Wed, 20 Jul 2016 10:45:12 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> Date: Wed, 20 Jul 2016 16:45:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> To: =?utf-8?Q?Ari_Ker=C3=A4nen?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML metadata label X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 14:45:14 -0000 > On Jul 20, 2016, at 4:15 PM, Ari Ker=C3=A4nen = wrote: >=20 > Hi, >=20 > Another proposed extension for SenML not yet in the draft is a = "metadata" field for SenML Records. This could be free-form UTF-8 text, = like string value (sv). Unlike sv, you can have this *and* a value. >=20 > Use cases include "international names" that you can't use as part of = "n" label due to the URI compatible restriction, adding "tags" that = describe your data, etc. >=20 > This seems like a simple thing with reasonable trade-off between value = and extra complexity. >=20 > We welcome proposals for the name and label of this thing. I'd suggest = "metadata" and "m". >=20 >=20 > Cheers, > Ari >=20 Seems like a good addition.=20= From nobody Wed Jul 20 07:47:19 2016 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 4C40212D878 for ; Wed, 20 Jul 2016 07:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 LBlOPnfT1aHM for ; Wed, 20 Jul 2016 07:47:13 -0700 (PDT) Received: from smtp85.ord1c.emailsrvr.com (smtp85.ord1c.emailsrvr.com [108.166.43.85]) (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 2BBED12D7CC for ; Wed, 20 Jul 2016 07:47:06 -0700 (PDT) Received: from smtp19.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A06B3A02F9; Wed, 20 Jul 2016 10:47:05 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 36437A01E0; Wed, 20 Jul 2016 10:47:05 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-61-100-229.cisco.com ([UNAVAILABLE]. [173.38.220.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Wed, 20 Jul 2016 10:47:05 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20160720125714.GG26784@hephaistos.amsuess.com> Date: Wed, 20 Jul 2016 16:47:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6FEF9EFD-47E4-472E-B2E4-40E265BB0368@iii.ca> References: <20160720125714.GG26784@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: core Subject: Re: [core] SenML nit: data value in CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 14:47:18 -0000 > On Jul 20, 2016, at 2:57 PM, Christian Ams=C3=BCss = wrote: >=20 > Hello list, >=20 > I think that the current SenML draft is missing a note on JSON/CBOR > differences in Data Value: While it is explicitly stated that vd is a > base64 string in JSON and a binary-value in CBOR, the supposedly > exhaustive list of differences in 6. fails to mention that no base64 > encoding is done in CBOR. Suggested addition: >=20 > o For Data Values, no base64url-encoding is done, as the data can be > directly expressed as binary-value. >=20 > Furthermore, I suggest that "Characters in the Data Value are base64 > encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", = to > make the distinction to the character-based strings and binary data > clearer. (The only context in which I'd name bytes of binary data > "Character" are when speaking of a "char" in C). >=20 > Best regards > Christian >=20 > =E2=80=94=20 Seems like a good addition - thanks for catching this=20 From nobody Wed Jul 20 08:01:39 2016 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 2437712D92F; Wed, 20 Jul 2016 08:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 6VF2h56sI2U2; Wed, 20 Jul 2016 08:01:33 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834B612D90D; Wed, 20 Jul 2016 08:01:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,394,1464645600"; d="scan'208,217";a="185362659" Received: from mail-lf0-f44.google.com ([209.85.215.44]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Jul 2016 17:01:29 +0200 Received: by mail-lf0-f44.google.com with SMTP id f93so40344697lfi.2; Wed, 20 Jul 2016 08:01:29 -0700 (PDT) X-Gm-Message-State: ALyK8tKLWyojbkuuysV0NbVg/YCIS21VEy40WjMGeK6CzBqSzxLxbTA1gFcFSYptbxXHKZeCZ7u6mYsfFOXH6w== X-Received: by 10.25.37.208 with SMTP id l199mr7827548lfl.41.1469026888797; Wed, 20 Jul 2016 08:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Wed, 20 Jul 2016 08:01:09 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Wed, 20 Jul 2016 17:01:09 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, core , IETF ROLL , cose@ietf.org, lp-wan@ietf.org, "iot-dir@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "t2trg@irtf.org" Content-Type: multipart/alternative; boundary=001a11410ed4df55e40538127963 Archived-At: Subject: Re: [core] F-Interop info session @IETF96 - Monday 8.30-9-30pm - Charlottenburg I X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 15:01:37 -0000 --001a11410ed4df55e40538127963 Content-Type: text/plain; charset=UTF-8 All, Thanks for attending the F-Interop info session on Monday evening. As promised, you will find the slides at http://www.finterop.eu/images/presentations/F-Interop_IETF96.pdf. Thomas On Sun, Jul 17, 2016 at 5:22 PM, Thomas Watteyne wrote: > All, > > Please note that the info session is in the EVENING, i.e. 20.30. Some > people got confused. > > Also, the Meetecho team is arranging for remote participation [1] to be > possible, thanks to them! > > Thomas > > [1] http://ietf96.conf.meetecho.com/index.php/Remote_Participation > > On Thu, Jul 14, 2016 at 3:43 PM, Thomas Watteyne > wrote: > >> All, >> >> We are organizing an information meeting about F-Interop, an online >> platform for remote interoperability testing, IETF96 Monday 8.30-9.30pm, in >> Charlottenburg I. >> >> F-Interop (www.f-interop.eu) is a platform for online and remote >> conformance and interoperability testing, targeted at IoT-related standards >> (6TiSCH, 6LoWPAN, CoAP, RPL, ...) >> >> The purpose of this info session is to give you a technical overview of >> the platform, describe how the IETF community can use and contribute to it, >> and get feedback. >> >> The platform is built as part of the 2016-2018 F-Interop H2020 European >> project. As part of that project, we will have an open call for entities to >> contribute additional tools and test descriptions to the platform. Selected >> projects will be funded; we will explain the process during the info >> session as well. >> >> Looking forward to seeing you there, >> >> Thomas >> > > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > _______________________________________ > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11410ed4df55e40538127963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Thanks for attending the F-Interop= info session on Monday evening. As promised, you will find the slides at= =C2=A0http://www.finterop.eu/images/presentations/F-Interop_IETF96.pdf.

On Sun, Jul 17, 2016 at 5:22 PM, Thomas Wattey= ne <thomas.watteyne@inria.fr> wrote:
All,

Please note that= the info session is in the EVENING, i.e. 20.30. Some people got confused.<= /div>

Also, the Meetecho team is arranging for remote pa= rticipation [1] to be possible, thanks to them!

Th= omas


On Thu, J= ul 14, 2016 at 3:43 PM, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
All,

We are organizing an information meeting ab= out F-Interop, an online platform for remote interoperability testing, IETF= 96 Monday 8.30-9.30pm, in Charlottenburg I.

F-Inte= rop (www.f-interop.eu= ) is a platform for online and remote conformance and interoperability = testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN, CoAP, RPL, ...= )

The purpose of this info session is to give you = a technical overview of the platform, describe how the IETF community can u= se and contribute to it, and get feedback.

The pla= tform is built as part of the 2016-2018 F-Interop H2020 European project. A= s part of that project, we will have an open call for entities to contribut= e additional tools and test descriptions to the platform. Selected projects= will be funded; we will explain the process during the info session as wel= l.

Looking forward to seeing you there,
=
Thomas



--
<= div>
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________


--
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________
--001a11410ed4df55e40538127963-- From nobody Wed Jul 20 08:05:23 2016 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 4B6F312D919; Wed, 20 Jul 2016 08:05: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] 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 NuYtaOdkELfS; Wed, 20 Jul 2016 08:05:16 -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 6C6D412D873; Wed, 20 Jul 2016 08:05:14 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1036A42F93; Wed, 20 Jul 2016 17:05:12 +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 812804A; Wed, 20 Jul 2016 17:05:11 +0200 (CEST) Received: from hephaistos.amsuess.com (prometheus.amsuess.com [5.9.147.112]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2DE1544; Wed, 20 Jul 2016 17:05:11 +0200 (CEST) Received: (nullmailer pid 16229 invoked by uid 1000); Wed, 20 Jul 2016 14:45:47 -0000 Date: Wed, 20 Jul 2016 16:45:47 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20160720144547.GI26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x0KprKst+ZOYEj2z" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: [core] SenML-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 15:05:21 -0000 --x0KprKst+ZOYEj2z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Given the number of SenML topics currently in the room, shall we have kind of a SenML pow-wow with the interested parties? (Ari, you mentioned a Christian Cc'd where there was no personal Cc, I suppose it's Christian Groves?) Like, before/during/after the plenary this evening? Cheers Christian --=20 We are dreamers, shapers, singers, and makers. -- Elric --x0KprKst+ZOYEj2z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj46bAAoJEDmNERLTpL3hNf8QAKzcexAWJctDTA1m2a0OiH2E TkzCCJx+suvo3td73JMPoIYXDTIas/C5tJXPXN4qE0kJNAu9KAfM77xVhL/IcGmr 8nAjLIDDkfaygs/qe2HsaScAAJIC4lcJJQbjrpvF0I5366YgWDc0Fv7wqmKVm72r Yra5ygBtF4wXHsDTrZqt2Ld7M/AXOq8kuKrFJTIXbv34ot5SU/kaEB0jRPEKK5yR F8eGapd2DPJMkBly0iBG0vhe1wkfoLqAEBHpONJuk7WUcit68BkOqt7NCBlNQDMZ no6uJCYbLFj24ncBMAC4vmG/p2GOAb5wVKJV5VJuSAlJ9+JXAF9XKI07mJO+RsFB kdNmtznYISLVBwCd/zsVbdKqIvjDH5mGbKaf6cw/c4MnjYSPbVtzpxzpgKeuOQSD M2kulMJro+a2Va6uRW06apKelc5wBp7Se86xJr0+4E29ysy7ttwbNSMTUr0PScE8 WX3c5t2NeUmL9rcD7Le/OcVhYw4nIc2KTSX+18l4VQ0QjfNSMOQpAt7frEx8XK/h Rja/OBv+liGuEJrcR1gbC819llBDcjXsfYzK8SVzJI8aBHtwG0w9GVcR58QQ7bcQ YR19P/oztpWp6TbAc8uQw2u8wgAmOufOOMY0YblPI0OU5J1emVAQyrz16nsCYdXC WvNEPwXtJiMF6tMy8rl4 =K1Rb -----END PGP SIGNATURE----- --x0KprKst+ZOYEj2z-- From nobody Wed Jul 20 08:05:32 2016 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 C0AF312D873; Wed, 20 Jul 2016 08:05:22 -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 7YsFf1XUdbY7; Wed, 20 Jul 2016 08:05:18 -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 DD48A12D7D4; Wed, 20 Jul 2016 08:05:14 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7E75142F99; Wed, 20 Jul 2016 17:05:13 +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 88C174A; Wed, 20 Jul 2016 17:05:12 +0200 (CEST) Received: from hephaistos.amsuess.com (prometheus.amsuess.com [5.9.147.112]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1D78B44; Wed, 20 Jul 2016 17:05:12 +0200 (CEST) Received: (nullmailer pid 17518 invoked by uid 1000); Wed, 20 Jul 2016 14:52:59 -0000 Date: Wed, 20 Jul 2016 16:52:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20160720145259.GJ26784@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="huBJOJF9BsF479P6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML base stride: time offset between records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 15:05:23 -0000 --huBJOJF9BsF479P6 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 02:27:10PM +0000, Ari Ker=E4nen wrote: > Third suggestion we discussed recently with Christian (Cc'd) is to add > a "base time offset" or "base stride" parameter that allows eliding > the time value for measurements that have been done at equal > intervals. On the balance between complexity and achievable compression, I'm moderately in favor of this. However, we should think through the numerics of this for non-integer times. Maybe it might be a good idea to limit base time (even independently of the strides) and the stride size to integers. (That's also the easiest way to avoid clients having to add an integer, a multiple of a decimal and a floating point coming from CBOR in this situation.) As the topic of precisely hitting the stride time, I think that a stride time should accumulate on the base time, and a time delta could still be applied. The delta can then be, in case of floating point time, the remaining t can then easily fit in a half float. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --huBJOJF9BsF479P6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj5BLAAoJEDmNERLTpL3hsRMQAKfZbLAOPRZ4EYTPL+ASOUJx 2bx+sSo1Jdmk2ofxJhoK4/RGZx+jxZOMTx7fasFB3GpM70Hsnwoo8cWcl8CwI1B1 OdldDtsK6hAb3wG7gfIh+qMHxZJeNaTvXdTesDin+Gyp7KxpeDnD+RLBWqDT0RLS WVsbDCj9djQXM33+H5+Ft9GyC6Q6i8PaCL9xN07KGBf18sjAbDZFuUFVv/g9mu9w /PkRIIMy6M3u4NHD/k6gTefn5ex9KhvFqAKs1CAlIV4iYgKScR9VQoXQxRawUKZY GS9PYkbGjjG9swgiuCFChke6lgpfdEa1Geaw2ZRY80U99AWsw3lqMVT/9bLH59nO GjsIfaX0TqxEbw4S5+XclGyVqz3BdlWrfR5/FG9EIZuYYW9mF2qDi7E2k1zynZ9y V330584Uq9qJ0OjHNbZBmU5d4+Jr3xhLjd0F2dWtiZN1gPVuAVOVVP81mVf1tgGw bHJAS8KYrnluFpXZpD+u3X3Kue/hHXpJp5PGOpDNNZr+PWEeUy7lsHEAolnPCyl6 QzRLsbswIxTb0QeoeWRhgF0X94MoE+59DOmnitzaIu+LY2rdWn/CaNuZ8MeozheL YfsrDL2stQtiEt0AcTE0LMqAVV4shaXrami7knFyBYnfGqyRer26W6FfIIYEBcjL q87RZqriGHBSeS9kNgHL =E+pS -----END PGP SIGNATURE----- --huBJOJF9BsF479P6-- From nobody Wed Jul 20 08:05:34 2016 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 19EA112D988; Wed, 20 Jul 2016 08:05:26 -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 ujw41VGvKcm8; Wed, 20 Jul 2016 08:05:21 -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 8B0E712D958; Wed, 20 Jul 2016 08:05:15 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 08E5B42F4C; Wed, 20 Jul 2016 17:05:14 +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 6860B1ED; Wed, 20 Jul 2016 17:05:13 +0200 (CEST) Received: from hephaistos.amsuess.com (prometheus.amsuess.com [5.9.147.112]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 221193BE; Wed, 20 Jul 2016 17:05:13 +0200 (CEST) Received: (nullmailer pid 19027 invoked by uid 1000); Wed, 20 Jul 2016 15:01:55 -0000 Date: Wed, 20 Jul 2016 17:01:55 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20160720150155.GK26784@hephaistos.amsuess.com> References: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tv2SIFopg1r47n4a" Content-Disposition: inline In-Reply-To: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML metadata label X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 15:05:26 -0000 --tv2SIFopg1r47n4a Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 02:15:42PM +0000, Ari Ker=E4nen wrote: > Another proposed extension for SenML not yet in the draft is a "metadata"= field for SenML Records. This could be free-form UTF-8 text, like string v= alue (sv). Unlike sv, you can have this *and* a value. >=20 > Use cases include "international names" that you can't use as part of "n"= label due to the URI compatible restriction, adding "tags" that describe y= our data, etc. >=20 > This seems like a simple thing with reasonable trade-off between value an= d extra complexity. What kind of data could go there that would *not* belong into link-format title instead? If title does not fit, why should that metadata not be in another link-format property? I consider the "associating meta-data" section applicable here, which tries to limit static meta-data about resources in SenML. Is this dynamic data you are proposing to be added there, and what would be their semantics? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --tv2SIFopg1r47n4a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj5JjAAoJEDmNERLTpL3hmk8QALf9Y3OWzWJwxSA0dHESYpI6 TxKPIhFgFcv66r5x8vuqDH0nlfbtG1q9CLdsf843/4TyKdrFIKvj6KTE6IMZ1tN6 bek6zLINJYHIViqAgVxpm7G01LOJOjvumHW3yX3ARAoz8ulCL3ZMm84suR7IZNse ELq0pu1NIE85cgUMu2J+bgVcg7lGL2mThhR1Q6lNpspdKzUGyvANlvldtO2JaQl3 H+R3QXfjT9INeA18k/X4krnnm8OOZJVcRbqM87ZXR1xgjKcXEYIuhXDIU2EgMlC3 ASw4ENh5dV74O9EdvsszUPvAEVMjZnS9zPqfGYWwAiKgCWruJLkw+uhyIMJDwZyZ b2obt4QJCNGJnjSAObJiaYS7KdBELqMZag6YOXDgPgW9rGwiDgm29YoZf2F2ORpC bNYCSUrVMMeNCab7wIoKNIGTlmB3TDhDvIRU1zu5F+oZ3ojf0SrGKvZjFm5b9UFx YTwpNgKYhwzHX+TUFbHoMsX/OV6HXLzdh+QklMljsvHeV5HiEXifv+TztjaFS+TZ wUpjWVe72+pzsqfn/hQg7QyshiCzb1h7YX5HSdygbiRRqpVDgAfPRoWXUSYio+UD H3Imszd/VY7I47O27s9UwM9vwURuLadi/MTt79M/vweAo7rV84OvCGXDNGxyRr1w JYFO1f6J4OzVjsqnVwJm =fE8r -----END PGP SIGNATURE----- --tv2SIFopg1r47n4a-- From nobody Wed Jul 20 09:02:10 2016 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 9542B12D85E for ; Wed, 20 Jul 2016 09:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 6a5NhftssbHY for ; Wed, 20 Jul 2016 09:02:07 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 041AC12D824 for ; Wed, 20 Jul 2016 09:02:07 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for core@ietf.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bPtwj-000jMJ-Kv>; Wed, 20 Jul 2016 18:02:05 +0200 Received: from zcde1.pia.fu-berlin.de ([87.77.205.225] helo=bender.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) for core@ietf.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1bPtwj-0022UN-EU>; Wed, 20 Jul 2016 18:02:05 +0200 To: core@ietf.org References: <20160720132236.GL7974@hephaistos.amsuess.com> From: =?UTF-8?Q?Lennart_D=c3=bchrsen?= Message-ID: <12277597-4a08-fa65-d87a-4d0a81486f82@fu-berlin.de> Date: Wed, 20 Jul 2016 18:02:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <20160720132236.GL7974@hephaistos.amsuess.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Originating-IP: 87.77.205.225 Archived-At: Subject: Re: [core] SenML suggestions 2/3: Content Format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 16:02:08 -0000 Hi Christian, not sure if I understand you correctly, but: > When multiple resources' representations are sent in a batch, the client > loses the information otherwise present in the Content-Format header > > GET /light/1 -> 2.05, Content-Format=0 (text/plain), "1" > GET /light/2 -> 2.05, Content-Format=0 (text/plain), "0" This is a very bad idea imho. Such resources and their aggregations should always be represented in SenML. As I understood it, SenML is developed precisely to avoid these arbitrary representations of sensor values. > in the aggregation > > GET /light/ -> 2.05, Content-Format=application/senml+json, > [{"n":"1","v":1},{"n":2","v":0}] > > . This leaves the client to guess what to actually do with the "sv" > strings. ("bv" and "v" booleans / numerics are a little odd here as this > is a rare situation where a resource has such a representation; I don't > see any harm there tough.) Which "sv" strings..? Can you give a more verbose example of what you mean? > I suggest that a pair of "cf"/"bcf" (content format, base content > format) be added with the usual "base" mechanism. Their values are an > integer number (like in the Content-Format option or the ct= link-format > parameter) or null, which is the default when neither bcf nor cf are > present, and has the semantics of an absent Content-Format option. Content format options are not available in all application layer protocols, and SenML should be independent of the underlying stack, right? I am strongly against including information from specific underlying protocols in SenML. Cheers, Lennart From nobody Wed Jul 20 09:27:28 2016 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 E3BC612D195 for ; Wed, 20 Jul 2016 09:27:26 -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 Xp5J9l7DdE3g for ; Wed, 20 Jul 2016 09:27:24 -0700 (PDT) Received: from smtp149.dfw.emailsrvr.com (smtp149.dfw.emailsrvr.com [67.192.241.149]) (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 B981312D821 for ; Wed, 20 Jul 2016 09:27:24 -0700 (PDT) Received: from smtp31.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp31.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 2DFF840295; Wed, 20 Jul 2016 12:27:24 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp31.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A150E40282; Wed, 20 Jul 2016 12:27:23 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-61-100-229.cisco.com ([UNAVAILABLE]. [173.38.220.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Wed, 20 Jul 2016 12:27:24 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20160720131935.GK7974@hephaistos.amsuess.com> Date: Wed, 20 Jul 2016 18:27:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F609BBA-6694-49C4-8153-0E51A2A2F975@iii.ca> References: <20160720131935.GK7974@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] SenML suggestions 1/3: Object Values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 16:27:27 -0000 > On Jul 20, 2016, at 3:19 PM, Christian Ams=C3=BCss = wrote: >=20 > Hello everyone interested in SenML, >=20 > I'd like to bring up again three suggestions for SenML which all = already > been on the list, but were not followed up on. In the interest of = thread > followability, I'll send them in separate mails. >=20 > As a preamble, I'd like to state that some of this reflects the notion > that SenML can be used to convey not only sensor data, but as a = generic > way of transporting representations of multiple resources in a single > request. >=20 > First, object values. >=20 > SenML extensions like the "l" attribute for links show the need for > having structured data in extensions. The data transported with this > SenML extension can be viewed as a representation of a resource > (in particular the link-format representation of the batch IIRC), and > could thus just as well go into a SenML record's value. >=20 > In order to avoid nesting JSON, it would be practical to allow a new > value-like property, "vo", to be an object value, which would be = deeper > JSON. (For "sv"/"bv"/"v", the point has been made that some JSON = parsing > mechanisms expect every recognized key to have a pre-specified type; = if > that's at all an issue here, it might need splitting into "va" (array > value) and "vo" (object value in the sense of a JSON "object" > (dictionary)). I=E2=80=99m strong against adding this. It make high speed parsing = really hard. I think l allows you to put this type of extensibility in a = separate document and use l to reference it.=20 >=20 > Inside a REST client or server, such a representation would appear > pre-parsed -- it in an API, an object would be passed instead of a > string. If this sounds odd to you, beware that this is already > happening: JSON strings are unicode character strings, so any REST > engine that allows a resource to be handled both as > text/plain;charset=3Dutf-8 and as part of a SenML batch already needs = to > handle byte strings and character strings (though that may be = invisible > as JSON libraries are commonly dealing with UTF-8 encoded byte strings > for practical reasons). They can also just keep the bytes intact and not process the string in = any way.=20 >=20 > The same scheme would work for CBOR in a straightforward way. While > something like that would probably be feasible in XML with namespaces > and such, I don't think it's worth the hassle, especially given that = the > whole XML/EXI serialization might be dropped in favor of a generic XML > serialization of JSON. Converters that have no dedicated knowledge of > what to do with the "vo" data should just pack the JSON into a string > and put that as a string value. (Which would *not* roundtrip, but > roundtrippability in conversion is something I'm not sure we have = anyway > given CBOR's extended capabilities). >=20 > I do not currently have use cases for this myself, but I think that it > allows the hypermedia things to mix their results into SenML in a much > more straightforward way. I=E2=80=99d like SENML to have the sort of performance of ProtoBuf and I = think that is very difficult with support for this type flexibility. =20 >=20 > Best regards > Christian >=20 > --=20 > Christian Ams=C3=BCss | Energy Harvesting = Solutions GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > | ATU68476614 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jul 20 09:30:35 2016 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 36B9412D8B3; Wed, 20 Jul 2016 09:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 1-1LY25iL1RJ; Wed, 20 Jul 2016 09:30:31 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 BD6DD12D8AB; Wed, 20 Jul 2016 09:30:31 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bPuOE-000vRk-Cf>; Wed, 20 Jul 2016 18:30:30 +0200 Received: from zcde1.pia.fu-berlin.de ([87.77.205.225] helo=bender.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1bPuOE-0024nt-6s>; Wed, 20 Jul 2016 18:30:30 +0200 To: core References: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> From: =?UTF-8?Q?Lennart_D=c3=bchrsen?= Message-ID: <0006768d-48b5-1db5-13ee-9c3fad9e5a12@fu-berlin.de> Date: Wed, 20 Jul 2016 18:30:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Originating-IP: 87.77.205.225 Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML metadata label X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 16:30:33 -0000 Hi, > Another proposed extension for SenML not yet in the draft is a > "metadata" field for SenML Records. This could be free-form UTF-8 text, > like string value (sv). Unlike sv, you can have this *and* a value. > > Use cases include "international names" that you can't use as part of > "n" label due to the URI compatible restriction, adding "tags" that > describe your data, etc. I understand the need for additional information. For example, it would be nice to know what exactly a sensor is measuring (e.g. the temperature of what object). However, I think SenML should focus on sensor values, because meta data as I imagine it should be standardized to some extent as well, and nodes should be able to request meta data independently from the values. Shorter things (titles etc) should go into the link format, as Christian suggested. For example, a node would request a list of sensors (via resource discovery), then request meta data for a few sensors/resources, and based on that meta data decide which values it is interested in. tl;dr meta data should be handled independently from values, should go somewhere else to keep SenML compact Best, Lennart From nobody Wed Jul 20 09:31:43 2016 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 8456412D8C7 for ; Wed, 20 Jul 2016 09:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zurH50R8FTZE for ; Wed, 20 Jul 2016 09:31:37 -0700 (PDT) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (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 C1F9312D8AC for ; Wed, 20 Jul 2016 09:31:37 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0877E20499; Wed, 20 Jul 2016 12:31:35 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id EF3E92035B; Wed, 20 Jul 2016 12:31:33 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-61-100-229.cisco.com ([UNAVAILABLE]. [173.38.220.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Wed, 20 Jul 2016 12:31:35 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20160720145259.GJ26784@hephaistos.amsuess.com> Date: Wed, 20 Jul 2016 18:31:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160720145259.GJ26784@hephaistos.amsuess.com> To: =?iso-8859-1?Q?Christian_Ams=FCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: core , "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML base stride: time offset between records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 16:31:42 -0000 > On Jul 20, 2016, at 4:52 PM, Christian Ams=FCss = wrote: >=20 > On Wed, Jul 20, 2016 at 02:27:10PM +0000, Ari Ker=E4nen wrote: >> Third suggestion we discussed recently with Christian (Cc'd) is to = add >> a "base time offset" or "base stride" parameter that allows eliding >> the time value for measurements that have been done at equal >> intervals. >=20 > On the balance between complexity and achievable compression, I'm > moderately in favor of this. >=20 > However, we should think through the numerics of this for non-integer > times. Maybe it might be a good idea to limit base time (even > independently of the strides) and the stride size to integers. (That's > also the easiest way to avoid clients having to add an integer, a > multiple of a decimal and a floating point coming from CBOR in this > situation.) >=20 > As the topic of precisely hitting the stride time, I think that a = stride > time should accumulate on the base time, and a time delta could still = be > applied. The delta can then be, in case of floating point time, the > remaining t can then easily fit in a half float. you have just convinced me that values in CBOR should be float not a = mixture of different integer, rational, and floating point types=20 From nobody Wed Jul 20 09:41:21 2016 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 4620212D786; Wed, 20 Jul 2016 09:41:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160720164119.1314.97880.idtracker@ietfa.amsl.com> Date: Wed, 20 Jul 2016 09:41:19 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:41:19 -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 : Guidelines for HTTP-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-13.txt Pages : 36 Date : 2016-07-20 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-13 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 20 10:02:46 2016 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 E1CA112D6B2 for ; Wed, 20 Jul 2016 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_QUOTING=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 zzPijdwgFFaw for ; Wed, 20 Jul 2016 10:02: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 74BB112D541 for ; Wed, 20 Jul 2016 10:02:42 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B03FC42F50; Wed, 20 Jul 2016 19:02:40 +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 F16574A; Wed, 20 Jul 2016 19:02:39 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A3C8144; Wed, 20 Jul 2016 19:02:39 +0200 (CEST) Received: (nullmailer pid 6533 invoked by uid 1000); Wed, 20 Jul 2016 17:02:38 -0000 Date: Wed, 20 Jul 2016 19:02:38 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Cullen Jennings Message-ID: <20160720170238.GL26784@hephaistos.amsuess.com> References: <20160720131935.GK7974@hephaistos.amsuess.com> <9F609BBA-6694-49C4-8153-0E51A2A2F975@iii.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8c07nsHwQobhlezh" Content-Disposition: inline In-Reply-To: <9F609BBA-6694-49C4-8153-0E51A2A2F975@iii.ca> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] SenML suggestions 1/3: Object Values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 17:02:45 -0000 --8c07nsHwQobhlezh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 06:27:21PM +0200, Cullen Jennings wrote: > I=E2=80=99m strong against adding this. It make high speed parsing really > hard. I think l allows you to put this type of extensibility in a > separate document and use l to reference it.=20 If this impedes high-speed parsing (which in my impression it does not, but that's just a weakly founded (see below) gut feeling), that's a very valid reason, but then we should make it explicit that any nested/object SenML extensions must only exist in formats that kind of inherit from SenML, and that they can't just show up in regular SenML. > > JSON strings are unicode character strings, so any REST > > engine that allows a resource to be handled both as > > text/plain;charset=3Dutf-8 and as part of a SenML batch already needs to > > handle byte strings and character strings [...]] >=20 > They can also just keep the bytes intact and not process the string in an= y way.=20 This was more to argue why it's not novel on the semantic side. > I=E2=80=99d like SENML to have the sort of performance of ProtoBuf and I = think > that is very difficult with support for this type flexibility. =20 Could you elaborate a little on how the potential presence of a "vo" key slows down a parser? Granted, the state inside the stream can, when depth is [{"":""}] at maximum, be represented in one enum and not an enum and two moderately sized ints. Is this what is sufficient to slow things down, or are there other considerations I missed? Best regards Christian --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --8c07nsHwQobhlezh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj66qAAoJEDmNERLTpL3h0i4P/0f11fRs7cQPVHwVdOPWjcpa G6bIBEkrlDIYLyRBVEyC6F0VoQvet4pp+Bvxdg4oy3zeLCipkx6tt+R7lVwYQQpR iecxAy0JnXjBCEz3iHAk3D82Ikj/8Rrl+v2IHLnAxhZb7+6smR38hcuPpBv+K8pT ek6BiKOSUw8u3YrEUKkAvspTAwg3ydoZAhG4EeCazZTN+yf1gKLiEKHzH2Zj6iRc Rjeot++0w8AxgsNIV4rxHyhUwarj/0gHebnsr1SPxc1JkLoYuWaf8IWICy3cM7yi 8R6V58rXHhfcQRBy0GRJaRB2tcY8ApXSf4aCkUGSbFqrty31gBWcJPyCWaS8p13Q NXPhMpD01w+g2S2/yJK5AQgs95tVbSH1v4E3EvSxSOnhtyOonTZMfiKRgT4iw6vZ 0Q4Mps3OuRJw//wAS8kzJ4MCGHZuFMS7kvBSez95CHgMzI2JJ/QiKq7BzcEdkJv2 ikrl8DOUDIQpOlYJZhesxczxOn8qtdjybNXbUCanxMmmJ2qjh3wuXFqGmcrAvLeW +AuTR02+bTvlHl4vJeoqpIIoSvJlQgK5V3C9vKzzLmAOq0zEOXQcRvBG6Amld0+Y KtrUs0tEjV2rDyEOsZ5VmrHbBP16vqnZma+oa1is/GbxgBEwNTiyLmILpw1OB3Y1 /n8NPMG+uNkvhg1GCfLm =OfAv -----END PGP SIGNATURE----- --8c07nsHwQobhlezh-- From nobody Wed Jul 20 12:41:31 2016 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 C599C12DB4A; Wed, 20 Jul 2016 12:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 pPD-TtpG2ADB; Wed, 20 Jul 2016 12:41:27 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 A9D6112DAEA; Wed, 20 Jul 2016 12:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=geYzNyjlfXjY/Wy/eYHMiKnkpK67hWXE+icV6tbwi00=; b=iXO7gb/qZjRuC6alCgcWv4pGnv NsnrjC2peY63Xg+hdWg5SHRMIIHltZt0jdugZ3JJsV6o9B702rcohhjlHH9whmh0U8ToH6WZSRr7Y E8yHQWp7QpZldsLQ0td2MbJFynqpQm9cEIRZXIG7ZyQ+lgrkZJDoLqqP6vyYZC79mh4QQht8bxSr8 pEDt6H9w8WwFUnmd1EqxFSHmghxvg41a37RPOe0+6mc+R9BpJJnYHro4fU5qt4g1vLgT41udxixsS ZM3jNNzNfT3XXxDsj4/IoiAjD47ra6jGVaERuqvbvRJiXhoNv7CfjFSldhkYrNVNBrFfYz3c+c1Wl Lfw0tWLg==; Received: from [46.189.28.83] (port=56252 helo=[10.24.255.117]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bPxMz-000TyO-9o; Thu, 21 Jul 2016 05:41:25 +1000 To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , core References: From: Christian Groves Message-ID: Date: Thu, 21 Jul 2016 05:41:17 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML base stride: time offset between records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 19:41:30 -0000 Hello Ari, all, No surprise that I'm in favour of this. I wasn't sure about "stride" but when I checked the dictionary it said "move over with long measured steps" so it seems pretty appropriate. There was some discussion about whether this would apply to a negative offset (e.g. "t": -10} case or just a time series increasing stride from the base time? Time series increasing only might minimise the implementation complexity but then the ability to map between negative time offset and stride would be lost. Any thoughts on that? Regards, Christian On 21/07/2016 12:27 AM, Ari Kernen wrote: > Hi, > > Third suggestion we discussed recently with Christian (Cc'd) is to add a "base time offset" or "base stride" parameter that allows eliding the time value for measurements that have been done at equal intervals. So (slightly modifying Christian's original example), using currently defined format you would have > > "bt": 1320067464, > "bu": "%RH", > "v": 21.2, "t": 0 }, > { "v": 21.3, "t": 10 }, > { "v": 21.4, "t": 20 }, > { "v": 21.4, "t": 30 }, > ... > > With "base stride" of 10 seconds, that would be > > "bt": 1320067464, > "bs": 10, > "bu": "%RH", > "v": 21.2}, > { "v": 21.3}, > { "v": 21.4}, > { "v": 21.4}, > ... > > And of course the benefits become more apparent the more records you have. > > This does bring some complexity since you have to do some simple arithmetics based on the "index" of the record to find out the time for each SenML Record. Also it's questionable how often the measurements are done in exact (enough) time intervals. On the other hand, it reduces size of a Pack considerably in relatively common use case. > > I would suggest we include this feature in the next version of the SenML draft. > > Opinions? > > > Cheers, > Ari > From nobody Wed Jul 20 12:54:01 2016 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 C920D12D0BA; Wed, 20 Jul 2016 12:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 hyCy1qmDmbXO; Wed, 20 Jul 2016 12:53:56 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 0282B1288B8; Wed, 20 Jul 2016 12:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nsCGO93/0xdZ1BQoJ0zP6O9W7+8uizOtbTZPEiwIOZ8=; b=f1cmCDd21ub/hekDP6GnSJK/Go 5MBse/MOY9vzlImCRaxbiZXez4dcpCA+SVSu5yhG8P/UQ7a0OMqusjZOnpohRai+S3DPJmlj451hz 2ireNpOGiqtVbkcPBkblLchqAmOI51C1tCGcwa3tF+Pu42YvhhtDzPsnLMOkhurH7Z3I3OmOO/3u5 2R344h5zmtZAQZRfNAahlrs+a4W9TPJ55HViUQpmwsiDRhhomHOcNiQJX2/LvS2kUw25bIVtxLZ8F CnVcwhrkbP0P1qU9Qc4u4SComLwR+L42xxwjfGRiQfdkhfzNdUPdUVdklUx23ki1sHK6cTQSVXHa+ Tg5ruMHw==; Received: from [46.189.28.83] (port=53581 helo=[10.24.255.117]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bPxZ3-000Uen-RH; Thu, 21 Jul 2016 05:53:54 +1000 To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , core References: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@ericsson.com> From: Christian Groves Message-ID: Date: Thu, 21 Jul 2016 05:53:45 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML values and extensions in SenML Records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 19:54:00 -0000 Hello Ari, I support the change. Regards, Christian On 20/07/2016 10:14 PM, Ari Kernen wrote: > Hi, > > We are considering small changes to SenML draft to clarify use of values in SenML Records and to facilitate value extensions. > > Currently the draft says that there must be exactly one of the defined value labels {v, vb, vd, vs} in each SenML record unless there's a sum value. However, if in future we define a new value label, currently it would mean you could not have that alone in a Record. > > Therefore, we are suggesting to relax that rule to say that exactly one value label (defined in the SenML document or in some future document) must be in each record. The proposed text change can be seen in pull request #22: > https://github.com/core-wg/senml-spec/pull/22/files > > Is anyone against doing this change? Other comments welcome too. > > > Cheers, > Ari > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Jul 20 13:02:18 2016 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 BC29512D19F; Wed, 20 Jul 2016 13:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 Qamjlo95Bnau; Wed, 20 Jul 2016 13:02:16 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 6825A12B034; Wed, 20 Jul 2016 13:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=n9vcqcr5x8ZKqXMmekmkQ0QVn+hxFR55pb7ty80uXeY=; b=bIv+eq0Oh106aNSO5yUDYD2k4R KK/0n0fRPZKClbPUGHsgbW3FUN8jnAAWAst7o/5Ek1vnvSK3LFKJsQrOGa+0/s4XnHi9Sf3SCNnfk 9rr5P0AUW2VoK4rND3q/tDueB55PVq1RMr3/UJMJITsmrvIY6TCfSe3UBsXQhrDd5BH8RcE+lk3pB yMS4ZrtlVU4nVp4dMX5cdEsi1aXg4IKtBXbvKaOeJk2KlJy+xJcWov3PtOrGa3jnHkrGy9wA9htdh WdfQWAVawkei0IpYSsBdT6ZDCq1FHd3kSLvQfMfICQG8FUEshSnA3ZVTMR+FdEQr5i62gXc34spYl hDQGO0WQ==; Received: from [46.189.28.83] (port=52231 helo=[10.24.255.117]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bPxh8-000VBr-4u; Thu, 21 Jul 2016 06:02:14 +1000 To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , core References: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> From: Christian Groves Message-ID: <08ebaaca-3139-6db9-a498-ab315cbb8736@nteczone.com> Date: Thu, 21 Jul 2016 06:02:05 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML metadata label X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 20:02:18 -0000 Hello Ari, Would this be roughly equivalent to the "name": construct from the proposed W3C thing descriptions? Regards, Christian On 21/07/2016 12:15 AM, Ari Kernen wrote: > Hi, > > Another proposed extension for SenML not yet in the draft is a "metadata" field for SenML Records. This could be free-form UTF-8 text, like string value (sv). Unlike sv, you can have this *and* a value. > > Use cases include "international names" that you can't use as part of "n" label due to the URI compatible restriction, adding "tags" that describe your data, etc. > > This seems like a simple thing with reasonable trade-off between value and extra complexity. > > We welcome proposals for the name and label of this thing. I'd suggest "metadata" and "m". > > > Cheers, > Ari > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Jul 20 13:13:13 2016 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 C7DB512D5D1 for ; Wed, 20 Jul 2016 13:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 xTy8cU3NBC-B for ; Wed, 20 Jul 2016 13:13:10 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 CE64212B04E for ; Wed, 20 Jul 2016 13:13:09 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for core@ietf.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bPxrg-001wnt-9g>; Wed, 20 Jul 2016 22:13:08 +0200 Received: from zcde1.pia.fu-berlin.de ([87.77.205.225] helo=bender.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) for core@ietf.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1bPxrg-002Kvh-3f>; Wed, 20 Jul 2016 22:13:08 +0200 To: core@ietf.org References: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@ericsson.com> From: =?UTF-8?Q?Lennart_D=c3=bchrsen?= Message-ID: <0c269318-c5bb-789c-097e-4468c19a248c@fu-berlin.de> Date: Wed, 20 Jul 2016 22:13:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Originating-IP: 87.77.205.225 X-ZEDAT-Hint: T Archived-At: Subject: Re: [core] SenML values and extensions in SenML Records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 20:13:12 -0000 Hi, > I support the change. so do I. Cheers, Lennart From nobody Wed Jul 20 13:46:15 2016 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 98E2612D60C; Wed, 20 Jul 2016 13:46:14 -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 wG3w5zloPZ2W; Wed, 20 Jul 2016 13:46:12 -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 960F012D6AD; Wed, 20 Jul 2016 13:46:12 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D8D9A42FA2; Wed, 20 Jul 2016 22:46:09 +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 D86211E9; Wed, 20 Jul 2016 22:46:08 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1C78E44; Wed, 20 Jul 2016 22:46:08 +0200 (CEST) Received: (nullmailer pid 18827 invoked by uid 1000); Wed, 20 Jul 2016 20:46:05 -0000 Date: Wed, 20 Jul 2016 22:46:05 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Christian Groves Message-ID: <20160720204605.GM26784@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U6leaJ20qZQc29iB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML base stride: time offset between records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 20:46:14 -0000 --U6leaJ20qZQc29iB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2016 at 05:41:17AM +1000, Christian Groves wrote: > There was some discussion about whether this would apply to a negative > offset (e.g. "t": -10} case or just a time series increasing stride from = the > base time? Time series increasing only might minimise the implementation > complexity but then the ability to map between negative time offset and > stride would be lost. Any thoughts on that? If we allow negative strides, we need to limit base time and stride time to integers (something -- again -- I favor anyway). Otherwise, we're in numeric elimination land and people will have expectations that just fail. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --U6leaJ20qZQc29iB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj+MKAAoJEDmNERLTpL3hAxwQALyo1dOWnXBzl9FzhmfER9ry f6Ly0QKtz/7HOp4wGonQyLe2r/CcvS4LuGylrYxDasXGj/Jc2uO7Vk1GhLA1pwiH /rG8vxaZYuQYFt1bkzoRtb84ZfZCAHjaa7iktYHMrfTD/JX4BcwhXZT/pDXZy32x adk3AwkmK28+7+bAHTf9m8CcL9PfSeR3dAyOgt5G80+tZXA7+kH10qITRw4Sjrwc LvRAlsQLMfFLGvYndnQ7h1/7aZvZp0CaSiYJ7LReoZg4dKIUIdcfxM+mpFOrpKKO 7gfWxaw6aAZqGQkA8KxjyatAL1Mu5g7xTPW5i7cEVwb1PCSVlr6pbdaPlRB0aQ1H nKTLV+7zrbztBgMyKgnuerut28NglTMY9xTBRssFo3i55VC+nHIxvoCzxliKvpPM 9vlK/N/EZtNtccJiUsi/i4kBMKLe83QA4fvHTwkd5FvbOgFQzef3vQ3X+bW40VRS +IT8209pVg7iC8gxbh3VXoTnqQv0XQDA7vHvrAdk9hkraTBnOGYYR4kU6n8RIkTF YPdNFMdsUUW0n+TEkz2tkPU03xMyrB1tnjS75vHvqSSjH2LG/8DPT8VH2i+9uZ0W 82fuQHt/mbxjHSu/Lt0BrgruGXvVaKNX5kK93NzgOEk3j4pmMOqDvC0uCJ0qI1gI iEhbmpp+fRVYOBHxlXbr =rCBb -----END PGP SIGNATURE----- --U6leaJ20qZQc29iB-- From nobody Wed Jul 20 13:54:49 2016 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 3F30212D7CC; Wed, 20 Jul 2016 13:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX0Fh74VLNru; Wed, 20 Jul 2016 13:54:45 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 C9F5912D66F; Wed, 20 Jul 2016 13:54:44 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id q128so70638073wma.1; Wed, 20 Jul 2016 13:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=duzvUNXJcku7+HD0+sBpN8/OfPWov9Y+fKcehaZPLIw=; b=aDXWG++hFhxgCEpEsgyyWVbP3sV53BE7DUVttJto1xPA0GFC81+7LihpcbZcHWqQJN ZXxi2RPeNT87B7Zhf66toWgUDDlRcSyCAFZQPubKMD8ATOli6jRT8+kLok42H3FQ6BMQ VesBS9WQFcvlC9+bthOFwBfkgYG9LPvpnBjOmfX8Byqjn1hzqrQDOPtofnL4pilJNYE7 G/boSfGqVKCj7lldVXa/C3y7l9zMnn1HXyf4TmSs3/PyqZz2wANGqEVOR2whC20JN6M6 hF+KvJ+udVYOCgdVBe8n2qTkmtgHQQkyBFeollcnxbVguJFwsnUw7K0GW7T+7Y542dSD 2U4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=duzvUNXJcku7+HD0+sBpN8/OfPWov9Y+fKcehaZPLIw=; b=FFwJcaXkKOdPTfFBlKu8kX/77/zF7kLntWdyL2kFK1Yl0QHVbWRHDJxYsUOYnofQy6 ozVqh+MwgEUUBWdd413EH7erXCHjx0N8C77/B0YrtMJvqEHyNFC9F2zBBtSpHmHkWUNy oDwrZ2EtxPGut6l3LK2nbkM4pKlsYdwoZgoM0Dvf9o77+o5W888W/OxxRMARI3nV16oh fmRflgSGCXqj2ZpxpbpqjrkDF5TEn81vs3304/m4FFS76RJML55nUeuoTdBPlkjSgnls beNXZevlvRxuuRjbI7u8TmheaATvoUyZ6eVXDblz64t4Sf8TT/CeWlKclrWBVxKdirYy aK5A== X-Gm-Message-State: ALyK8tLpKfkm9Xv9TPg6dGaAav+TqC6cZuU3VKt0iy2tNm0c8Bn2W//SmhEDbHg/JX13bA== X-Received: by 10.28.225.4 with SMTP id y4mr13732475wmg.98.1469048083316; Wed, 20 Jul 2016 13:54:43 -0700 (PDT) Received: from [192.168.48.206] ([212.91.224.152]) by smtp.gmail.com with ESMTPSA id e7sm2965054wjj.45.2016.07.20.13.54.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 13:54:42 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <20160720124217.GF26784@hephaistos.amsuess.com> Date: Wed, 20 Jul 2016 22:54:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9BE2C484-4A37-4DB4-A134-340624D4D4A1@ericsson.com> <20160720124217.GF26784@hephaistos.amsuess.com> To: =?iso-8859-1?Q?Christian_Ams=FCss?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core , "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML values and extensions in SenML Records X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 20:54:47 -0000 So to be clear, does this mean that a base value or a regular value is = still required in every record? Meaning I can't have a simple collection representation like this? [ { "bn": "/collection/" }, { "n": "resource1", "vs": "foo", }, { "n": "resource2", "vs" "bar", }, { "n": "resource3", "vs": "baz" } ] Best regards, Michael > On Jul 20, 2016, at 2:42 PM, Christian Ams=FCss = wrote: >=20 > On Wed, Jul 20, 2016 at 12:14:27PM +0000, Ari Ker=E4nen wrote: >> Currently the draft says that there must be exactly one of the = defined value labels {v, vb, vd, vs} in each SenML record unless there's = a sum value. However, if in future we define a new value label, = currently it would mean you could not have that alone in a Record. >>=20 >> Therefore, we are suggesting to relax that rule to say that exactly = one value label (defined in the SenML document or in some future = document) must be in each record. The proposed text change can be seen = in pull request #22: >> https://github.com/core-wg/senml-spec/pull/22/files >>=20 >> Is anyone against doing this change? Other comments welcome too. >=20 > I'm in favor of this change for your reasons but also due to a > suggestion I'm currently writing up -- but to make it short: To > accomodate streaming parsing, the current draft is much better than = what > we had last year, but parsers still need to seek around a little = because > a bn/bt can be after a n/t. If we made them mutually exclusive (either > bn or n, either bt or t), the 30-byte-state-parser (which includes > relative URI resolution) becomes doable again. >=20 > Best regards > Christian >=20 > --=20 > Christian Ams=FCss | Energy Harvesting Solutions = GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > | ATU68476614 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jul 20 14:04:47 2016 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 2056D12D805; Wed, 20 Jul 2016 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 VMJLVeI4zqGy; Wed, 20 Jul 2016 14:04:44 -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 342DC12D0C5; Wed, 20 Jul 2016 14:04:44 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id AC55442FA2; Wed, 20 Jul 2016 23:04:42 +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 C17341E9; Wed, 20 Jul 2016 23:04:41 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 71D2044; Wed, 20 Jul 2016 23:04:41 +0200 (CEST) Received: (nullmailer pid 22807 invoked by uid 1000); Wed, 20 Jul 2016 21:04:40 -0000 Date: Wed, 20 Jul 2016 23:04:40 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" , Michael Koster Message-ID: <20160720210440.GN26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ctUzwJm0i+kwMBIK" Content-Disposition: inline In-Reply-To: <20160720132417.GM7974@hephaistos.amsuess.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML suggestions 3/3: Streamability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 21:04:46 -0000 --ctUzwJm0i+kwMBIK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (moving this into the right thread to not hijack Ari's allow-absance-of-value proposal) On Wed, Jul 20, 2016 at 10:54:40PM +0200, Michael Koster wrote: > So to be clear, does this mean that a base value or a regular value is > still required in every record? No, only that they must not occur in the same record. > Meaning I can't have a simple collection representation like this? >=20 > [ > { > "bn": "/collection/" > }, > { > "n": "resource1", > "vs": "foo", > }, > { > "n": "resource2", > "vs" "bar", > }, > { > "n": "resource3", > "vs": "baz" > } > ] You can have this. You could even simplify it to this per (what I think by now are) established semantics: [ { "bn": "/collection/resource1", "vs": "foo", }, { "n": "resource2", "vs" "bar" }, { "n": "resource3", "vs": "baz" } ] What you can not do is [ { "n": "resource1", "vs": "foo", "bn": "/collection/" }, { "n": "resource2", "vs" "bar" }, { "n": "resource3", "vs": "baz" } ] because an application would be delaying interpretation of "resource1" until the bn occurred, and there may be arbitrary lengths of "foo" inbetween. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --ctUzwJm0i+kwMBIK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj+dlAAoJEDmNERLTpL3hLWYP/2P2CKvg+EuQ4wsr5/98W/yv TyPbW62W+TUYwvFTpLtZYSFDFzL7wPqKDHNhMitzvhAIQvEvvDTXEr0rHIDTXeVn dlJhVRyE0+sbrVlmpeLZmGbfTCxtHmZ/pOd012Q3WcK6rppHAexa/FvY5REL9OWB M2sYWeqlW38h1ZmsznZgYt3p32oLIVy0o/VO2YMt4nHpduyMyZ8+H0UpJxwIUuua D96vgF6PKpLrC/rX5o726dKamku0BbY3yXRK1m3fNlONmnIgyA193ktgSGgpptzY v1yHYgP9AVpT8h721+ehRiNbWE2RSf/W+8wT9T2YKjDOVBC4CAk50ZmP1C+EiWbl VgXdRdzPmid8cTadD6wrgoQ/MMsGT1OaXhGnszgRqNJFhEzxyWa/RTvtof9AiYNd 0Seq7gXQ0jEUJzZfpNW7HBDdPfZTqmWUqIDR978ECQ01tQB/vnriUXY8rDXiPQ6U 0iDa8owPKjgEzThfa+/tAj6UQJm2/SbACcMeIm9PxZzAlBKQUABI5OZ9cAMFUU3C JcyumiKw8+ad9VQg50PYGQFaG8lzByTswMRLBun3U1GF1di1clw5pBK2NCCGgb7n T2syYIIVsxzPv8TfPEt3YAG4/1dZU7HtQkq+nX9eQNadOPZtwvF0CZz+WexTAxyt PrLEv984s6IPSaSGEDFX =sIGP -----END PGP SIGNATURE----- --ctUzwJm0i+kwMBIK-- From nobody Wed Jul 20 14:09:46 2016 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 7FE1712D0C5; Wed, 20 Jul 2016 14:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfIRWOQ1zy-f; Wed, 20 Jul 2016 14:09:44 -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 B18B112D0AF; Wed, 20 Jul 2016 14:09:43 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id q128so71019365wma.1; Wed, 20 Jul 2016 14:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=uQtTQ9Hfw4JdNJo2ZIg56ew3yVphfngNbU/4daTyGco=; b=V3ZcmglaNfWLLaoV1F5mkIBRpkJ/Z5ExR5LyGCkWbAK3wjyP+9uJR/0qATWn0H/iIw s3aP8uYIzitH/qpt0yeeNk+ETUnOMlqeL/FmhOU4pDT/N+RokJ1THVsSZRwy1AUhktmL gefGdXCBTY0F5vQXfykJ6rtUzDDXsBM2HQLBB+bRK+5eEZBe1JNAnuiXysydKmHlU3sY i78VP6aEm8rkZ9gVSxOQv9WIpaC+avUQmdKotSGAVD+Ao4z/r418A2WxZ/1akyeSGdxG esHbKGgJZCEr+Xc/p8znjsTqJRvx1Fi51d9AHRpeKUCPKDk6dT1fdFRj4gCraVvvAvKC 9Pyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uQtTQ9Hfw4JdNJo2ZIg56ew3yVphfngNbU/4daTyGco=; b=cvV7ELEw1VEcv4Sn+HugrolR9t3n/kBC9gIwlkFmERdxiSzKuXcPU9JjYh2gaF8qnr m4Mx5LKshT7xEaKmFX4kLmPU0o8UbUpVWAVPukV6m5W4ZjozjIq872qUVZCz0ZY/0Zvp 1cTrk7Od4zkHrzXorpWMcd0+iKWC+DJdfkEa4Rw+PLl8gG+tZZHAiCRZwkmTLkMZXLec sRpDxGy75O3C5T2Uj5f1cHiM7l/DVWzJVSUE2RXRMxIAmJer4ubpwV1qoRq4/SAqd8mA 7yOkf1QWShcNTELsKEh+/w2tM1mzK7Dv7lnjMNtu8GS4OqimAFUOtAlGGOa+0TdM1S9e T0RA== X-Gm-Message-State: ALyK8tIr3FKXNLK50LpbFqL91sl2uukHjVswma8uUlmqao7xzEzPcfgETfD04tSgGueCyw== X-Received: by 10.194.175.39 with SMTP id bx7mr3866524wjc.150.1469048982114; Wed, 20 Jul 2016 14:09:42 -0700 (PDT) Received: from [192.168.48.206] ([212.91.224.152]) by smtp.gmail.com with ESMTPSA id 207sm33201896wmb.7.2016.07.20.14.09.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 14:09:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD139F83-0324-4233-A5A8-CD0D01B18C9F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <20160720210440.GN26784@hephaistos.amsuess.com> Date: Wed, 20 Jul 2016 23:09:39 +0200 Message-Id: <2692023D-A0D8-41D7-8DC5-763F638712B5@gmail.com> References: <20160720210440.GN26784@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , "core@ietf.org" Subject: Re: [core] SenML suggestions 3/3: Streamability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 21:09:45 -0000 --Apple-Mail=_DD139F83-0324-4233-A5A8-CD0D01B18C9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I would not prefer this, and it's not clear it's a simplification. It = means my code has to identify a value to pack in with the base and then = split it out at the other end.=20 More work for a tiny gain in efficiency on the wire. Plus it's not = obvious to many how the URI resolution works. Best regards, Michael > On Jul 20, 2016, at 11:04 PM, Christian Ams=FCss = wrote: >=20 > You can have this. You could even simplify it to this per (what I = think > by now are) established semantics: >=20 > [ > { > "bn": "/collection/resource1", > "vs": "foo", > }, > { > "n": "resource2", > "vs" "bar" > }, > { > "n": "resource3", > "vs": "baz" > } > ] --Apple-Mail=_DD139F83-0324-4233-A5A8-CD0D01B18C9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I would not prefer this, and it's not clear = it's a simplification. It means my code has to identify a value to pack = in with the base and then split it out at the other end. 

More work for a tiny = gain in efficiency on the wire. Plus it's not obvious to many how the = URI resolution works.

Best regards,

Michael

On = Jul 20, 2016, at 11:04 PM, Christian Ams=FCss <c.amsuess@energyharvesting.at> wrote:

You can have this. You could even simplify it to = this per (what I think
by now are) established = semantics:

   [
     {
       "bn": = "/collection/resource1",
       "vs": = "foo",
     },
     {
       "n": = "resource2",
       "vs" = "bar"
     },
     {
       "n": = "resource3",
       "vs": = "baz"
     }
   ]

= --Apple-Mail=_DD139F83-0324-4233-A5A8-CD0D01B18C9F-- From nobody Wed Jul 20 14:16:37 2016 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 7D37612D7E1; Wed, 20 Jul 2016 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uExFeVPQdCXv; Wed, 20 Jul 2016 14:16:33 -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 1ABD012D5A3; Wed, 20 Jul 2016 14:16:33 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id p129so267658wmp.0; Wed, 20 Jul 2016 14:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Psf8JENxWGrWvs1Q0yzcZt+VYz1rtYkujuX8wSM24Is=; b=Qnqqodd6wMj2X37QpD2c9g752vdOgYXoodztn+Nav9mIgSvxhYEE1e4mXYwrnbbJSd Z8PAs27Zkdl2/NfGDfVCPT3l0deHhmykuQvc1+yr/LmyzrKVjG3zRz9qyEE8X4fn8Tbl Kc9mbaiWLFXvJPXBl0tiiheiHZRbQWOMBEi4vs7qqWm1bCiVX/1JHRJGdY7bhTj55KgJ nWY12r3d+LxOY2VQs+BbFYv1fEDvykd31azbq2aJaLavwcUkcshrGOpyiIFVb7LBznBb 4Jr9PFy4JcAPcz0WF4/IYVDAUFpFoQ6sBHpJAyh4ak2c8ZSrCx6vvB3mDBJOAZIIqWzB vbUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Psf8JENxWGrWvs1Q0yzcZt+VYz1rtYkujuX8wSM24Is=; b=lF5vWvuHUdiKw3lFamBVbUATevtjavxKJIyRCRQZNCnG3qkUFiA/YWLSOnHFDf3eMy 5uu4uQ3dS7ubP9YH+DWWHPWvNrgMUAcyLEh+nbypJwcXjNbX9cDHMzCn7XYljKn4fQMm J1J1qTwfmn+iZfhkwdKGF3p9KRpqeQbtyd3zrPFS8OpMxxzjlvUK2GHR3uJdhmPG4zOh 2uOLDBuLSfwA/AAOldQjVY2YaCVJRtUPKukyS2LrcY0dkpMgUPNhY3H14KPqSIFvZwol E6vzol2aipqZ6huWl4EaHxOD4Y2A7xE81vPSCHYARqDryZGoFPwpcw7vkJIggESJfrW9 VGnQ== X-Gm-Message-State: ALyK8tLHkKl/PwX2dgLXPGjz+3XZLxymk8X6BP5zgPEgsxQmWcEfCiFiYu1u1WtV/5Of7w== X-Received: by 10.194.17.105 with SMTP id n9mr3357407wjd.161.1469049391633; Wed, 20 Jul 2016 14:16:31 -0700 (PDT) Received: from [192.168.48.206] ([212.91.224.152]) by smtp.gmail.com with ESMTPSA id r67sm6886044wmb.14.2016.07.20.14.16.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 14:16:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FB6F3D12-30CE-4C0B-96D4-4A7B4497677E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <20160720210440.GN26784@hephaistos.amsuess.com> Date: Wed, 20 Jul 2016 23:16:29 +0200 Message-Id: References: <20160720210440.GN26784@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , "core@ietf.org" Subject: Re: [core] SenML suggestions 3/3: Streamability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 21:16:36 -0000 --Apple-Mail=_FB6F3D12-30CE-4C0B-96D4-4A7B4497677E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The new proposal doesn't seem to allow an absence of value.=20 On careful reading, it still requires a value (or a sum), but the value = may be one other than that defined in the current draft. I don't think "bn" qualifies as such a value. It seems overly restrictive to force this. Best regards, Michael Values are represented using basic data types. This specification + defines floating point numbers ("v" field for "Value"), booleans = ("vb" for=20 + "Boolean Value"), strings ("vs" for "String Value") and binary data = ("vd" for + "Data Value"). Exactly one value field MUST appear unless there is = Sum field=20 + in which case it is allowed to have no Value field.=20 =20 > On Jul 20, 2016, at 11:04 PM, Christian Ams=FCss = wrote: >=20 > (moving this into the right thread to not hijack Ari's > allow-absance-of-value proposal) >=20 --Apple-Mail=_FB6F3D12-30CE-4C0B-96D4-4A7B4497677E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The new proposal doesn't seem to allow an absence of = value. 

On = careful reading, it still requires a value (or a sum), but the value may = be one other than that defined in the current draft.

I don't think "bn" qualifies as such a = value.

It = seems overly restrictive to force this.

Best regards,

Michael


Values are represented using basic data types. This = specification
+ defines floating point numbers ("v" = field for "Value"), booleans ("vb" for =
+ "Boolean Value"), strings = ("vs" for "String Value") and binary data ("vd" = for
+ "Data Value"). Exactly = one value field MUST appear unless there is Sum field =
+ in which case it is allowed to have no Value field. =

On Jul 20, 2016, at 11:04 PM, Christian Ams=FCss <c.amsuess@energyharvesting.at> wrote:

(moving this into the right thread to not hijack = Ari's
allow-absance-of-value = proposal)


= --Apple-Mail=_FB6F3D12-30CE-4C0B-96D4-4A7B4497677E-- From nobody Wed Jul 20 14:17:01 2016 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 01FFF12D803; Wed, 20 Jul 2016 14:17:01 -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 jkdBMHUBqUFW; Wed, 20 Jul 2016 14:16:58 -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 86E0512D0AF; Wed, 20 Jul 2016 14:16:58 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CA7BC42F4B; Wed, 20 Jul 2016 23:16:54 +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 C45864A; Wed, 20 Jul 2016 23:16:53 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3D16244; Wed, 20 Jul 2016 23:16:52 +0200 (CEST) Received: (nullmailer pid 24888 invoked by uid 1000); Wed, 20 Jul 2016 21:16:49 -0000 Date: Wed, 20 Jul 2016 23:16:49 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20160720211649.GO26784@hephaistos.amsuess.com> References: <20160720210440.GN26784@hephaistos.amsuess.com> <2692023D-A0D8-41D7-8DC5-763F638712B5@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b5sSX5qSQrSInIHt" Content-Disposition: inline In-Reply-To: <2692023D-A0D8-41D7-8DC5-763F638712B5@gmail.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" , "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML suggestions 3/3: Streamability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 21:17:01 -0000 --b5sSX5qSQrSInIHt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 11:09:39PM +0200, Michael Koster wrote: > > [{"bn":"/foo/bar",...}, {"n": "baz"}] > > I would not prefer this, and it's not clear it's a simplification. It > means my code has to identify a value to pack in with the base and > then split it out at the other end.=20 >=20 > More work for a tiny gain in efficiency on the wire. Plus it's not > obvious to many how the URI resolution works. How far this is a simplifcation could be argued, but I'd prefer not to do this right now. As for it not being obvious to many, I agree, but this is something we'll need to work on. I'd like to point out, however, that this is not the point of this thread. The point is that [{"n":"bar", ...(much)..., "bn":"/foo/"}...] should be avoided. The example you were worried about not being allowed any more would still be allowed. Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --b5sSX5qSQrSInIHt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj+o+AAoJEDmNERLTpL3hySsP/RLtE6ySp6P8JokjNq8N/T1I yqGumVF79lXUTFp4gXf7Ai64bMQIi9CGSq/7wq5IWOihXKHxIZZRm08MRNYUyqOY xe03uV2yQjB2A+wStPK3PEMNobfJwAyjluO4dABK4zw8p49Y1oZhokZUVqZI/qSy JEZSgklCpdHQQ118wy/191GNetQoKJRKBqXR5a1iqb0JD6oczBq7IWCMo3aKtsib Ygo7g5JBejqWey63RSbcMnn4r1YP2nNSeUnvsONnkXvyu0O90QKRvAvBiTGqCyPF 8ldQNPPZYvosF7XPqXqhHiGjZoW7WH10I8JUpFo4+uxp27I3KCPVK02iPcxxqT5q nrrYKHdxRxejUgOSyfgrwDc2GpfE/x65Dh7ASp0vZiNHxzOStRO79y54yvEKFCab lswnrpb7NU9EzWqfsDIucXrNI6iXuRyIvk0fxEv1QnDHU4a1P1kE5zUumHOQlO2D FJNy0DnKe5sk+Z0gkODkTOBnwnHPSDcpLYeNGsipraDNpQYtQACz89Nr0SYvNIrI Tfa8HwcKEL+ZvYwXe/WNxH8XGNb6X1AZXuqT3lKJ53WnMcN7XlBEkGHVN1g0zhlm vnNGkXYTXKwobWn/ec6cGDBeXZrGew26fExDiTH26YSaoUR7A7ZsnfadiR8/Chac bb63TB+nmDvw8yAnr8iJ =KhYQ -----END PGP SIGNATURE----- --b5sSX5qSQrSInIHt-- From nobody Wed Jul 20 14:23:16 2016 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 D9F7812D0A1; Wed, 20 Jul 2016 14:23:14 -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 3Pmy62G8L0uw; Wed, 20 Jul 2016 14:23:13 -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 656C912B024; Wed, 20 Jul 2016 14:23:13 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id EC45E42F4B; Wed, 20 Jul 2016 23:23:11 +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 1B2BB4A; Wed, 20 Jul 2016 23:23:11 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BAEFE44; Wed, 20 Jul 2016 23:23:10 +0200 (CEST) Received: (nullmailer pid 25733 invoked by uid 1000); Wed, 20 Jul 2016 21:23:09 -0000 Date: Wed, 20 Jul 2016 23:23:09 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20160720212309.GP26784@hephaistos.amsuess.com> References: <20160720210440.GN26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2D20dG0OqTzqkNh7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" , "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML suggestions 3/3: Streamability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 21:23:15 -0000 --2D20dG0OqTzqkNh7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 11:16:29PM +0200, Michael Koster wrote: > On careful reading, it still requires a value (or a sum), but the > value may be one other than that defined in the current draft. The change Ari suggested in "SenML values and extensions in SenML Records" already suggests dropping that restriction, and has received positive feedback so far. > It seems overly restrictive to force this. The context of this statment is ambiguous to me. What do you consider overly restrictive, the above "there must be a "v*" parameter", or my "there must not be base and non-base of a kind"? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --2D20dG0OqTzqkNh7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj+u9AAoJEDmNERLTpL3hTZYP/3dC9dvxpIvrb8g5QY7zyMeG rCTQnpjYmK6g15o26KdBllJrQmEpzg7VIMPhGZu08tXMTVrULudAjISiOKkypER9 LmQ0ZV724pKioo7NsiDUlCTlGr4qAkkaHBKxHlR/1/CRoIBTY1T/a0svxp51laiL c85Il7TAaDtv8NHsT2aNGAiwREmzC+ESP9Al98E6rj7mLiE5SwscHyUW7MTjpd2d fPZ8y9P058Jt/0Yw4vn6nAbCU8Ur019R14EYhY1eoummBWx+SM5O97gSpIV8HbRC 6zJVIqgki+ekg6n02f6ZLcf5LpRUjlasPi9os2CwEDlGCl05uPHDAZKEggBf9rid c7FxiUIMbT83+gRf57Yo1tgY0VKEydJbWfQa6oB6rsv6rN2xwcKUDNa6H5cURHYp BJwnTxa0f7OAPNSX4j3GxvoF3cVLmydhHLI7K1Hl57wzwj5xCXLp+EoTHiNAXAi8 /pm4r9daWCMbBHCdkiiFrpo9SAao4EgNmdSBx4yOZV12xefnLqKOOiga/V0FUiMx paqBqyiVzd6UslnCl6tqFfDHg/bvYs8kiTappN5PhLtQdoScRsvsA5FbNoQtNwUO rTS4xiA/3O7A6zTHK2S228PrJB+7gTTpjgQ5YYNDbRggGqckvV6BgcJ4Enq8t3JA GI+pfigi102z7FhGB7ea =La3V -----END PGP SIGNATURE----- --2D20dG0OqTzqkNh7-- From nobody Wed Jul 20 14:54:13 2016 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 61E3112D0C4 for ; Wed, 20 Jul 2016 14:54:12 -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 JtA5FOBsm6zA for ; Wed, 20 Jul 2016 14:54:10 -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 BEBD812B015 for ; Wed, 20 Jul 2016 14:54:10 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0330442F07; Wed, 20 Jul 2016 23:54:08 +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 5A5F94A; Wed, 20 Jul 2016 23:53:55 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-9a98.meeting.ietf.org [31.133.154.152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 398CA44; Wed, 20 Jul 2016 23:53:49 +0200 (CEST) Received: (nullmailer pid 29729 invoked by uid 1000); Wed, 20 Jul 2016 21:53:45 -0000 Date: Wed, 20 Jul 2016 23:53:45 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20160720215345.GQ26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0Qexx6XJGNEACt6j" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "core@ietf.org" Subject: [core] pubsub-05: why UNSUBSCRIBE? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 21:54:12 -0000 --0Qexx6XJGNEACt6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael, late as always I'm just reading the pubsub draft. Apart from me not being convinced that this the proposed way is the right way to implement the pubsub pattern on CoAP (maybe it is, I'd love to chat about the rationale in another thread/conversation), I'm wondering about UNSUBSCRIBE: Why is this a dedicated operation? I do not find anything in there that is not obvious behavior from there being an active observation that can (just as laid out in RFC 7641) can be cancelled. I do see that coming =66rom a pubsub mindset this is an operation, but on the CoAP side I would not see it as an operation (with all its attached Method and URI and what not details), and would rather informally state that an "UNSUBSCRIBE" mechanism is expressed by cancellation of the observation obtained in the SUBSCRIBE mechanism. See you tomorrow Christian --=20 Yesterday is history, tomorrow is a mystery, and today is a gift. That is why it is called the present. -- ancient saying --0Qexx6XJGNEACt6j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXj/LmAAoJEDmNERLTpL3heCMQANDvW6ligI3DxKCkjtLwQS8J YnWmSFvrFKzA8Bn1riWjZ+wwcDb3vTtZvgtV+wEriyAoJduHeFqGDHtdBj6rGocp egZOkfcArOmDHjaBgOxBR9lgL6qI1rPUbDfLfWWgneRHK18aUs0lrPmsLxyyG6jE LmFNaBCo58T0SZpQjC7QXxYmggZTaSm8niQDfjq9RV03MtBud5omGASztEhffv8E jh3tGDjZwMtnzkD5wAcIoYlX/Og8kwLvheTn6o6ooIc4fJ1OKlcy2rB1m6tN/QGu kCkstzL8JnXVWQcwb2HpZlSPJk7kgvVZpwQJx1XVOWjaL6+AQqTDFOQyHYXvarxO 1bzNqNq08vxLf5wZgJMuRUZYQC+tYcxD/PZi4n5kAiA0nxCWr8eLsQp5VxYB7Pfk /9L2VFZrAzE81T/hCrUDMvQztyBRZ+u5WvKPwU3AzaF/xrlaIbLHxydprN8+v38h eQZZARxGMhOab3PQ/BggjPZt826mOWEgViLeezeIcCyoyLsrBOckL5nFYMRx9L0e 2L+1lLJwI4fBSRbx1JQuj+kfdERnJ90glKy26SrH4jmlrIr5/NAHSFk5EkCdbKod SWULrlENZ7hM+ny6EbmJFQwGDtCzHla3N/wQEbVAsNGI2ZDPQlciLnK/m9E122mf RL+Evcr5GGqNoK23XnAl =xemu -----END PGP SIGNATURE----- --0Qexx6XJGNEACt6j-- From nobody Wed Jul 20 16:25:57 2016 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 2CE7812D7A1; Wed, 20 Jul 2016 16:25: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 zYEtQ4rKn3tm; Wed, 20 Jul 2016 16:25:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3995212D5C7; Wed, 20 Jul 2016 16:25:54 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-1a-579008808cba Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.01.12516.08800975; Thu, 21 Jul 2016 01:25:52 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.150]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 01:25:51 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: SenML-* Thread-Index: AQHR4pgd91N9CQxkukuKzcAlAVQjuqAh1WIA Date: Wed, 20 Jul 2016 23:25:50 +0000 Message-ID: <07D70AF3-AB05-4350-AE5F-CBAAF7675C61@ericsson.com> References: <20160720144547.GI26784@hephaistos.amsuess.com> In-Reply-To: <20160720144547.GI26784@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.148] Content-Type: text/plain; charset="utf-8" Content-ID: <4F629853A73E684F9FEF0676B4FE2DC2@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUyM2K7qG4Dx4RwgyuThSyWX3jOYvHlfSOL xb6365ktfr5bwmzxYf0PRotpB+eyWUxrP8/uwO6xdf9dJo+989vYPXbOusvusWTJTyaPy+c/ MnqsOD+TJYAtissmJTUnsyy1SN8ugSvj2PoZTAULOCteXulnbmBs4Oxi5OSQEDCRaG3pZIaw xSQu3FvP1sXIxSEkcIRRYsPFV1DOEkaJ9VsWM4JUsQnYSjxp3ccKYosIeEhMXPqFHaSIWWAV k8TxzrdgCWEBEYnfn98AdXMAFYlKfF0YCVFvJHH6xi0WEJtFQFVi4ambrCAlvAL2Eld2W4GE hQSsJU7+m8IGYnMK2Eicv9/PBGIzAh33/dQaMJtZQFzi1pP5TBBHC0gs2XMe6gFRiZeP/7FC 2EoSjUuegI1nFtCUWL9LH6LVWqKzZxYbhK0oMaX7ITuIzSsgKHFy5hOWCYzis5BsmIXQPQtJ 9ywk3bOQdC9gZF3FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERjFB7f81t3BuPq14yFGAQ5G JR5ehT394UKsiWXFlbmHGCU4mJVEeJ/+AQrxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4k kJ5YkpqdmlqQWgSTZeLglGpgdPHRVQrcMS/3e9vKbZdZN0k1BUoYfRcUfj9lvcU8I4tQac0X j/3VxI5/1rn6PWvqvLNud048zFLOV7m94H6b7CxzDe2jR83d2LMDZI/M2L2D7657SHjFu4Cd 3OK35NaFcB9P3LvrwInUF+VtbubvOfeUJSs3Ox3SuL7wSVKBiLtcZcmJaw9nKrEUZyQaajEX FScCAGqdFPHeAgAA Archived-At: Cc: core , "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 23:25:56 -0000 SGksDQoNClVuZm9ydHVuYXRlbHkgbGFzdCBldmVuaW5nIHdhcyBhbHJlYWR5IGZ1bGx5IGJvb2tl ZCwgYnV0IGF0IGxlYXN0IHBhcnQgb2YgdGhlIDE0OjAwLTE2OjAwIHNsb3QgKGJlZm9yZSBDb1JF KSBvbiBUaHVyc2RheSBJIGNvdWxkIHVzZSBmb3IgYSBzaWRlIG1lZXRpbmcgdG8gZGlzY3VzcyB0 aGVzZSBpc3N1ZXMuDQoNCkknbSBDYydpbmcgaGVyZSBzZXQgb2YgcGVvcGxlIHdobyBoYXZlIHBh cnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lvbiwgYnV0IG90aGVycyBhcmUgd2VsY29tZSB0byBq b2luIHRvby4NCg0KV2UgY291bGQgbWVldCAxNDowMCBhdCB0aGUgdGFibGVzIGluIGZyb250IG9m IExBIGNhZmUuDQoNCg0KQ2hlZXJzLA0KQXJpDQoNCj4gT24gMjAgSnVsIDIwMTYsIGF0IDE2OjQ1 LCBDaHJpc3RpYW4gQW1zw7xzcyA8Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQ+IHdyb3Rl Og0KPiANCj4gR2l2ZW4gdGhlIG51bWJlciBvZiBTZW5NTCB0b3BpY3MgY3VycmVudGx5IGluIHRo ZSByb29tLCBzaGFsbCB3ZSBoYXZlDQo+IGtpbmQgb2YgYSBTZW5NTCBwb3ctd293IHdpdGggdGhl IGludGVyZXN0ZWQgcGFydGllcz8gKEFyaSwgeW91IG1lbnRpb25lZA0KPiBhIENocmlzdGlhbiBD YydkIHdoZXJlIHRoZXJlIHdhcyBubyBwZXJzb25hbCBDYywgSSBzdXBwb3NlIGl0J3MNCj4gQ2hy aXN0aWFuIEdyb3Zlcz8pDQo+IA0KPiBMaWtlLCBiZWZvcmUvZHVyaW5nL2FmdGVyIHRoZSBwbGVu YXJ5IHRoaXMgZXZlbmluZz8NCj4gDQo+IENoZWVycw0KPiBDaHJpc3RpYW4NCj4gDQo+IC0tIA0K PiBXZSBhcmUgZHJlYW1lcnMsIHNoYXBlcnMsIHNpbmdlcnMsIGFuZCBtYWtlcnMuDQo+ICAtLSBF bHJpYw0KDQo= From nobody Wed Jul 20 16:30:11 2016 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 4443F12D7E6; Wed, 20 Jul 2016 16:30:09 -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 dU1rEM9VjDVd; Wed, 20 Jul 2016 16:30:04 -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 95EEB12D7A1; Wed, 20 Jul 2016 16:30:04 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BD5D442F50; Thu, 21 Jul 2016 01:30:02 +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 DAC491E9; Thu, 21 Jul 2016 01:30:01 +0200 (CEST) Received: from hephaistos.amsuess.com (p4FD4C980.dip0.t-ipconnect.de [79.212.201.128]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 73AC160; Thu, 21 Jul 2016 01:30:01 +0200 (CEST) Received: (nullmailer pid 1929 invoked by uid 1000); Wed, 20 Jul 2016 23:29:59 -0000 Date: Thu, 21 Jul 2016 01:29:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20160720232959.GR26784@hephaistos.amsuess.com> References: <20160720144547.GI26784@hephaistos.amsuess.com> <07D70AF3-AB05-4350-AE5F-CBAAF7675C61@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8DtChEGCcMdSgkU2" Content-Disposition: inline In-Reply-To: <07D70AF3-AB05-4350-AE5F-CBAAF7675C61@ericsson.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 23:30:09 -0000 --8DtChEGCcMdSgkU2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 11:25:50PM +0000, Ari Ker=E4nen wrote: > We could meet 14:00 at the tables in front of LA cafe. Works for me. (As would earlier times.) See you then Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --8DtChEGCcMdSgkU2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXkAlzAAoJEDmNERLTpL3hfUIP/3rgvRc3v+4P6avF7eiKzlJy iKNscW0GwY4UvWXeAHefPxhQ2LuJATnL9f0jtTjl2lO2wMWYgzfQiKiosMUL572v PE/5NJMXKuuHJJRm15RtnxJJaJwT4cnSDCR7iqcEbDjHAU64GjWoQz+Zi/a2x3zR CFoO2aDrC6dAK8OKP8zkPApuQn3u0BOsAfLtgf3nK2qrrAdYLTMSIbJ0n3ezgs0h MKC+ibAq0Qz6gztawOVk9WTBOVVC91Y4LSDymVMj3Qfnz6S+A5JwRnimt9VTDcU7 ZH5Xq1KvWQxAbXbYYYVhWg/VeANaQNGYvp95cI7lhDg+o158TSAaD4o0d8v3vXEW DQdkkOJUyx7xNZDlIkiNNe/BYg/WTrI+a/fDjIKiomcCVPPMgFYOycBq/u9w6gyH L6EOW1q4kDCrGa8/CROAwH8q8c68h/+KrHfcLGdpQ7ipJEayeUrlY/COFvf1WT6e DgrliWK4eie9oTuPh1e/dF4kc3BbIdYaWWGe0XNe/6pmvciAI79PJZvDYl+UJbB+ cBUEz7SLNdNlpZlh3ChjiOrCZrjRW8nAq1953t+gdROPUiPIumVSx3EGe4jELAMh nVapnEzMi5lgnXc/E4RQBwLsmo1kZvtI/TuigHAULVfApg+XIYpl3shKQJs+PjAS Ww92ONqtxzHVv7PtxqKJ =E52W -----END PGP SIGNATURE----- --8DtChEGCcMdSgkU2-- From nobody Wed Jul 20 16:48:46 2016 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 769E712D16D for ; Wed, 20 Jul 2016 16:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 249pxHbf3Dct for ; Wed, 20 Jul 2016 16:48:44 -0700 (PDT) Received: from smtp-in1.interdigital.com (unknown [68.168.94.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8A212D0A6 for ; Wed, 20 Jul 2016 16:48:43 -0700 (PDT) X-ASG-Debug-ID: 1469058521-06daaa108f359f50001-aa7cYp Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id ozYI7tXRMTcSeJRs (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2016 19:48:41 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0301.000; Wed, 20 Jul 2016 19:48:39 -0400 From: "Rahman, Akbar" To: =?iso-8859-1?Q?Jaime_Jim=E9nez?= Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-13.txt X-ASG-Orig-Subj: RE: [core] I-D Action: draft-ietf-core-http-mapping-13.txt Thread-Index: AQHR4qWPUEvB31P6WkmvTeIqIAN2oaAh8nUg Date: Wed, 20 Jul 2016 23:48:39 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5C041942@NABESITE.InterDigital.com> References: <20160720164119.1314.97880.idtracker@ietfa.amsl.com> In-Reply-To: <20160720164119.1314.97880.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.183] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253] X-Barracuda-Start-Time: 1469058521 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 2726 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.31412 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 23:48:45 -0000 Hi Jaime, Thomas has updated the draft: 1) As per the comments on the email list from Christian Amsuss' to add the = missing (end) slashes in the URI mapping template examples. 2) Also the suggestion from the IANA pre-review (by Sean Leonard) has been = incorporated to add a reference to RFC 7252 for the new CoAP content format= ("cf") parameter (as part of the new Internet Media Type "application/coap= -payload"). So hopefully that will be enough to finally close the WGLC and submit the d= ocument to IESG. Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Wednesday, July 20, 2016 12:41 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments of the IE= TF. Title : Guidelines for HTTP-to-CoAP Mapping Implementation= s Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-13.txt Pages : 36 Date : 2016-07-20 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-13 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 21 00:09:28 2016 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 C5AB912DA7B for ; Thu, 21 Jul 2016 00:09:27 -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 S4vU--8nOkoS for ; Thu, 21 Jul 2016 00:09:26 -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 E99F712D8A1 for ; Thu, 21 Jul 2016 00:09:25 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:d927:c758:3112:9a12]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 888C91720C8; Thu, 21 Jul 2016 09:09:24 +0200 (CEST) Message-ID: <57907525.80305@tzi.org> Date: Thu, 21 Jul 2016 09:09:25 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Core@IETF96 slides updated X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 07:09:28 -0000 I have updated the slide set at https://www.ietf.org/proceedings/96/slides/slides-96-core-0.pdf with new material submitted so far. Slot leaders: please check... (I apologize for a few artifacts from the widescreen conversion; there are some interesting presentation software bugs lurking here. This little artifacts should not hold us back.) Grüße, Carsten From nobody Thu Jul 21 04:14:52 2016 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 DCCFF12DE05; Thu, 21 Jul 2016 04:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 L2jgEbWoUNC4; Thu, 21 Jul 2016 04:14:49 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 5630512DE0B; Thu, 21 Jul 2016 04:11:48 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bQBtI-001Lxr-Ec>; Thu, 21 Jul 2016 13:11:44 +0200 Received: from zcde1.pia.fu-berlin.de ([87.77.205.225] helo=bender.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1bQBtI-003OrE-8G>; Thu, 21 Jul 2016 13:11:44 +0200 To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , =?UTF-8?Q?Christian_Ams=c3=bcss?= References: <20160720144547.GI26784@hephaistos.amsuess.com> <07D70AF3-AB05-4350-AE5F-CBAAF7675C61@ericsson.com> From: =?UTF-8?Q?Lennart_D=c3=bchrsen?= Message-ID: Date: Thu, 21 Jul 2016 13:11:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <07D70AF3-AB05-4350-AE5F-CBAAF7675C61@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Originating-IP: 87.77.205.225 Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , core Subject: Re: [core] SenML-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 11:14:51 -0000 Hi, unfortunately I won't be able to come to IETF before 6pm today, there are too many overlaps with my work and exams. I'll try to join remotely as soon as possible, and maybe we'll see each other at the Bits 'n Bites. Cheers, Lennart On 07/21/2016 01:25 AM, Ari Keränen wrote: > Hi, > > Unfortunately last evening was already fully booked, but at least part of the 14:00-16:00 slot (before CoRE) on Thursday I could use for a side meeting to discuss these issues. > > I'm Cc'ing here set of people who have participated in the discussion, but others are welcome to join too. > > We could meet 14:00 at the tables in front of LA cafe. > > > Cheers, > Ari > >> On 20 Jul 2016, at 16:45, Christian Amsüss wrote: >> >> Given the number of SenML topics currently in the room, shall we have >> kind of a SenML pow-wow with the interested parties? (Ari, you mentioned >> a Christian Cc'd where there was no personal Cc, I suppose it's >> Christian Groves?) >> >> Like, before/during/after the plenary this evening? >> >> Cheers >> Christian From nobody Thu Jul 21 08:38:16 2016 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 2903912D5F7; Thu, 21 Jul 2016 08:38:13 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 Np19zpTcJdH9; Thu, 21 Jul 2016 08:38:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 88E9212D520; Thu, 21 Jul 2016 08:38:11 -0700 (PDT) Received: from [192.168.122.112] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 86297509B6; Thu, 21 Jul 2016 11:38:10 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2016 08:38:09 -0700 Message-Id: To: cbor@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: core@ietf.org Subject: [core] CBOR Tag for IP address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 15:38:13 -0000 Hello: Shall there be a CBOR tag for IP addresses? I would propose that one tag be allocated, <>; right now I=E2=80=99m = thinking in the range of 40-255. If the byte string is 4 bytes, then = it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6; if = it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. And if people need arrays or maps of IP addresses, we can talk about = that too. Not sure if people need subnet masks. I recall that some hallway discussions in the past 2-3 IETFs suggested = that it should be done. However, it has not been added to = draft-bormann-cbor-tags-oid, or to any other draft, yet. I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while = the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80=99s= quite inefficient for ipv4-address and ipv6-address. Rather than having = huge regular expression patterns, you can just transmit the octets, you = know, the way that IP itself transmits them. Regards, Sean= From nobody Thu Jul 21 08:48:50 2016 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 40DD312D627; Thu, 21 Jul 2016 08:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmmsVzbOat0K; Thu, 21 Jul 2016 08:48:44 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 3918312B031; Thu, 21 Jul 2016 08:48:44 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id f93so65663404lfi.2; Thu, 21 Jul 2016 08:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zNRPDOitRFiTRTiAfzAvLTSiEpor1G1SvSwTtVeMtEY=; b=FCfiNJf1SQa/dNj19VYDb6BY5q05fabN/EZAOKVRRJhq0+bFFscUkZZnqoZe0SHt2b A/JytPUh2Xo2BvOBvmPv0juaVDJbAAUVnfIn6T4Vyc0r1mj0cAMO1EXiDBqsr9pMFUW8 em5IPXCbwYG2KBo7HIx8sPpX6gtpQcR77NB6r/xRFN2Vv50eYoMRdG2V0kVINqgn2Fui 8jerTorgHqzOYJN92jDIyjdGtUW36aX0yvrVmFgZ47D3f5zoJIytk8/cie2CJwDNgKck ixB8kDG5059xbTOBhHm7MoeVlK5fGFydiJeD5O+grs0y3eoPK5eGwT3ARbGlRaxQe+kO AERg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zNRPDOitRFiTRTiAfzAvLTSiEpor1G1SvSwTtVeMtEY=; b=KZfFLwieu4JuW9Ltu3/7886lTgFkVB2BoHhtmIo0wyz7MJMiLtWCnA+SbV0lS/OHVB xfNxgwI8rnIr51t3isq/vO977FkRldBsUJ89ifQCPemTnvgqijYltpWOWK+AJ6AOPcLA B3nUd04glYmEbg+yABYDS1aV+TopBaMX2mBqeqxMjMmPfkaeU1wAmlccvOghjiTeooNy ji7bcdtH+MKwA8CdqtT+o6r/swBUzL3UeBg8hQ/IViFKqg7INl7/IQ0wtLgyr0Ch/RaM jiS2FzTCZS93jsKeCNQsS3DVhA/MnfZ3E4+vUjQ6mydiT7MB92+c4ZdJDDCthHXCRvw+ 5vXg== X-Gm-Message-State: ALyK8tJrz7KJSe304ZssFCxUFTIJwD/lUB/0q5NYnXzAUUJNfrLd+OlWB2PsQHU5wOBC9g== X-Received: by 10.25.82.202 with SMTP id g193mr11290910lfb.141.1469116122066; Thu, 21 Jul 2016 08:48:42 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:28cc:dc4c:9703:6781? ([2001:67c:370:160:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g72sm1991456lji.43.2016.07.21.08.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:48:40 -0700 (PDT) To: Sean Leonard , cbor@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> Date: Fri, 22 Jul 2016 03:48:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core@ietf.org Subject: Re: [core] [Cbor] CBOR Tag for IP address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 15:48:46 -0000 I'm not convinced. I have running code based on (in CDDL) ipv4-address =3D bytes .size 4 ipv6-address =3D bytes .size 16 with no particular problems. Brian On 22/07/2016 03:38, Sean Leonard wrote: > Hello: >=20 > Shall there be a CBOR tag for IP addresses? >=20 > I would propose that one tag be allocated, <>; right now I=E2=80=99m= thinking in the range of 40-255. If the byte string is 4 bytes, then it=E2= =80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6; if it=E2=80=99= s > 16, then it=E2=80=99s some IPvFuture. >=20 > And if people need arrays or maps of IP addresses, we can talk about th= at too. Not sure if people need subnet masks. >=20 > I recall that some hallway discussions in the past 2-3 IETFs suggested = that it should be done. However, it has not been added to draft-bormann-c= bor-tags-oid, or to any other draft, yet. >=20 > I have been reviewing draft-ietf-core-yang-cbor-02, and noted that whil= e the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80=99= s quite inefficient for ipv4-address and ipv6-address. Rather than having= huge regular expression patterns, you can just transmit the octets, you = know, the way that IP itself transmits them. >=20 > Regards, >=20 > Sean > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Thu Jul 21 08:52:18 2016 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 52B1212D665; Thu, 21 Jul 2016 08:52:15 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 rs7s6bTRxVFL; Thu, 21 Jul 2016 08:52:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 C257512D69A; Thu, 21 Jul 2016 08:52:13 -0700 (PDT) Received: from [192.168.122.112] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C7D150A87; Thu, 21 Jul 2016 11:52:12 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> Date: Thu, 21 Jul 2016 08:52:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cbor@ietf.org, core@ietf.org Subject: Re: [core] [Cbor] CBOR Tag for IP address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 15:52:15 -0000 Semantic tagging is (almost) always optional. Whether you =E2=80=9Cneed=E2= =80=9D it or not depends on the higher-level protocol. RFC 7049: 2.4. Optional Tagging of Items In CBOR, a data item can optionally be preceded by a tag to give it additional semantics while retaining its structure. =20 ... Their primary purpose in this specification is to define common data types such as dates. A secondary purpose is to allow optional tagging when the decoder is a generic CBOR decoder that might be able to benefit from hints about the content of items. So actually, I think your example proves the point...of how easy it is = to specify IP addresses in a 4 or 16 byte string. Sean > On Jul 21, 2016, at 8:48 AM, Brian E Carpenter = wrote: >=20 > I'm not convinced. I have running code based on (in CDDL) >=20 > ipv4-address =3D bytes .size 4 > ipv6-address =3D bytes .size 16 >=20 > with no particular problems. >=20 > Brian >=20 >=20 > On 22/07/2016 03:38, Sean Leonard wrote: >> Hello: >>=20 >> Shall there be a CBOR tag for IP addresses? >>=20 >> I would propose that one tag be allocated, <>; right now I=E2=80=99m= thinking in the range of 40-255. If the byte string is 4 bytes, then = it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6; if = it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. >>=20 >> And if people need arrays or maps of IP addresses, we can talk about = that too. Not sure if people need subnet masks. >>=20 >> I recall that some hallway discussions in the past 2-3 IETFs = suggested that it should be done. However, it has not been added to = draft-bormann-cbor-tags-oid, or to any other draft, yet. >>=20 >> I have been reviewing draft-ietf-core-yang-cbor-02, and noted that = while the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, = it=E2=80=99s quite inefficient for ipv4-address and ipv6-address. Rather = than having huge regular expression patterns, you can just transmit the = octets, you know, the way that IP itself transmits them. >>=20 >> Regards, >>=20 >> Sean >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 From nobody Thu Jul 21 09:31:25 2016 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 23A8712D7A0; Thu, 21 Jul 2016 09:31:19 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 75kFX_WvPgfY; Thu, 21 Jul 2016 09:31:17 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 BF62112D79C; Thu, 21 Jul 2016 09:31:17 -0700 (PDT) Received: from [192.168.122.112] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 51CB650A84; Thu, 21 Jul 2016 12:31:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> Date: Thu, 21 Jul 2016 09:31:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> To: cbor@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian E Carpenter Subject: Re: [core] [Cbor] CBOR Tag for IP address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 16:31:19 -0000 Actually I should have rearranged my original e-mail. It was not meant = to advocate for a particular outcome, but rather to generate discussion = of a perceived problem and a possible solution: Shall there be a CBOR tag for IP addresses? I recall that some hallway discussions in the past 2-3 IETFs suggested = that it should be done. However, it has not been added to = draft-bormann-cbor-tags-oid, or to any other draft, yet. I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while = the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80=99s= quite inefficient for ipv4-address and ipv6-address. Rather than having = huge regular expression patterns, you can just transmit the octets, you = know, the way that IP itself transmits them. One proposal could go as follows: one tag be allocated, <>; right now = I=E2=80=99m thinking in the range of 40-255. If the byte string is 4 = bytes, then it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s = IPv6; if it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. And if people need arrays or maps of IP addresses, we can talk about = that too. Not sure if people need subnet masks. (=46rom the CoRE/YANG perspective, typedef-ing IP addresses differently = could also work.) Regards, Sean= From nobody Thu Jul 21 10:44:24 2016 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 5EBF712B071; Thu, 21 Jul 2016 10:44:20 -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 OZNjVALB82ke; Thu, 21 Jul 2016 10:44:18 -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 0B0C512B006; Thu, 21 Jul 2016 10:44:18 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:494c:7923:68d9:f968]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 80D4A1720AF; Thu, 21 Jul 2016 19:44:14 +0200 (CEST) Message-ID: <579109EC.1030209@tzi.org> Date: Thu, 21 Jul 2016 19:44:12 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Sean Leonard References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cbor@ietf.org, Brian E Carpenter , core@ietf.org Subject: Re: [core] [Cbor] CBOR Tag for IP address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 17:44:20 -0000 We might take a page out of draft-ietf-anima-grasp-06.txt ipv4-address = bytes .size 4 ipv6-address = bytes .size 16 Grüße, Carsten Sean Leonard wrote: > Actually I should have rearranged my original e-mail. It was not meant to advocate for a particular outcome, but rather to generate discussion of a perceived problem and a possible solution: > > > Shall there be a CBOR tag for IP addresses? > > I recall that some hallway discussions in the past 2-3 IETFs suggested that it should be done. However, it has not been added to draft-bormann-cbor-tags-oid, or to any other draft, yet. > > I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while the example in Section 5.12 is “interesting”, it’s quite inefficient for ipv4-address and ipv6-address. Rather than having huge regular expression patterns, you can just transmit the octets, you know, the way that IP itself transmits them. > > > One proposal could go as follows: one tag be allocated, <>; right now I’m thinking in the range of 40-255. If the byte string is 4 bytes, then it’s IPv4; if it’s 16 bytes, it’s IPv6; if it’s > 16, then it’s some IPvFuture. > > And if people need arrays or maps of IP addresses, we can talk about that too. Not sure if people need subnet masks. > > (From the CoRE/YANG perspective, typedef-ing IP addresses differently could also work.) > > Regards, > > Sean > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Thu Jul 21 12:30:05 2016 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 1786912D77D; Thu, 21 Jul 2016 12:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlZVafdC1hKz; Thu, 21 Jul 2016 12:29:59 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 2159D12D694; Thu, 21 Jul 2016 12:29:59 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id x25so49918426qtx.2; Thu, 21 Jul 2016 12:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cE2EwR+ScgMDKxf1ZSCtr/8YJ+WJM+9RVFnDPpHQjlI=; b=08qU50DNQ2odZiHrI7IKXjQ5eaLoJ8Y3+vTkkZh/AxK81yUTi2TvWvC2LCIP845taf OWtLbGf3bFStevoFCTT/Mu6Nco0RBtmI1bWTnFTeppLj9WPNgN4JmIGbP6Dcoe2h5r7G UuM03zwUCENpRDMCClUAhdx0YsvTooeZdsN+aYWp5UUC15jYSmefoBTf8/BWpOY5UTMt YnFRnLzVqm8ks0Dw6dol0bQk7g/Be7lulTMMnvoQwqX6fxLnWkFysKU0JCfwpOdmjoks jmhZrboLU2xTC/OdQxMyXwSTJqbmybjaXHsr3/ZmjMK6D8CwbQG9NyBgUQwBgjG81xyP 5Nfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cE2EwR+ScgMDKxf1ZSCtr/8YJ+WJM+9RVFnDPpHQjlI=; b=EcIYMOjxMV0nYdGfpiSkiWRas/pa2wD09R0rAhhbrzrfegVmOKknUQK/gvLhHKqbSx XjumlcGp1YA9mVpo8uK6pAnsNho575P55b3pM51OoSKZjPplPL79ctR8Mi2zKscqRn4z Xi9m3h8Fh9rwGMjZ5blMcGtn0APNqGzNqS4ZJkow5ZNdJed0i8X/yF8zJAXWRHzIfL5n wCN6dAXOYT0TqolfWsbHH8AAPTtYGViuXKah1MnCa8WuT7Jy49ZWu3ykOiOp9/jJYjNd yaxaKzts+uAJZcMct7k0XE5xX098mVaXIrhL9pxvG5X/mT9TtDD5eYC+FEBa2NMxOsy/ RjvA== X-Gm-Message-State: ALyK8tISiv1Hz8YXGo9npfGx9rIQO9oX4b8QO5o9Mf85QUE3ub9DRQ+5LlmuKjpUI6EAvg== X-Received: by 10.200.37.252 with SMTP id f57mr86323977qtf.68.1469129398042; Thu, 21 Jul 2016 12:29:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j7sm5193701qkf.11.2016.07.21.12.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 12:29:57 -0700 (PDT) To: Carsten Bormann , Sean Leonard References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> <579109EC.1030209@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2afa99ae-303c-280d-1d2f-53b2c3ecb531@gmail.com> Date: Fri, 22 Jul 2016 07:30:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <579109EC.1030209@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cbor@ietf.org, core@ietf.org Subject: Re: [core] [Cbor] CBOR Tag for IP address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 19:30:01 -0000 On 22/07/2016 05:44, Carsten Bormann wrote: > We might take a page out of draft-ietf-anima-grasp-06.txt > ipv4-address =3D bytes .size 4 > ipv6-address =3D bytes .size 16 And to expand a bit on that, once one of those has emerged from cbor.loads() as for example b, you do something like this (in Python): if len(b) =3D=3D 16: a =3D ipaddress.IPv6Address(b) elif len(b) =3D=3D 4: a =3D ipaddress.IPv4Address(b) else: # error handling and what you'd feed into cbor.dumps() would be a.packed The advantage of having a defined tag and appropriate support in dumps() and loads() would be to avoid that if statement and simply use an object of class ipaddress. Brian >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Sean Leonard wrote: >> Actually I should have rearranged my original e-mail. It was not meant= to advocate for a particular outcome, but rather to generate discussion = of a perceived problem and a possible solution: >> >> >> Shall there be a CBOR tag for IP addresses? >> >> I recall that some hallway discussions in the past 2-3 IETFs suggested= that it should be done. However, it has not been added to draft-bormann-= cbor-tags-oid, or to any other draft, yet. >> >> I have been reviewing draft-ietf-core-yang-cbor-02, and noted that whi= le the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80= =99s quite inefficient for ipv4-address and ipv6-address. Rather than hav= ing huge regular expression patterns, you can just transmit the octets, y= ou know, the way that IP itself transmits them. >> >> >> One proposal could go as follows: one tag be allocated, <>; right n= ow I=E2=80=99m thinking in the range of 40-255. If the byte string is 4 b= ytes, then it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6= ; if it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. >> >> And if people need arrays or maps of IP addresses, we can talk about t= hat too. Not sure if people need subnet masks. >> >> (From the CoRE/YANG perspective, typedef-ing IP addresses differently = could also work.) >> >> Regards, >> >> Sean >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >=20 From nobody Thu Jul 21 16:32:34 2016 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 E1AE412DA9C; Thu, 21 Jul 2016 16:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 91dz7TskCfAt; Thu, 21 Jul 2016 16:32:21 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D06212DA9E; Thu, 21 Jul 2016 16:32:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,401,1464645600"; d="xml'217?scan'217,208,217";a="185562424" Received: from mail-lf0-f46.google.com ([209.85.215.46]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jul 2016 01:32:16 +0200 Received: by mail-lf0-f46.google.com with SMTP id l69so73239175lfg.1; Thu, 21 Jul 2016 16:32:16 -0700 (PDT) X-Gm-Message-State: AEkoousbHOxyxYu9BgCO2VTBTmsFhA8RnPIkw6pfGuwS9Seh+uQOSCPH/gsNNShFZ9qsetzOdwlTX9MTpMKqeQ== X-Received: by 10.25.37.208 with SMTP id l199mr576711lfl.41.1469143935971; Thu, 21 Jul 2016 16:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.84 with HTTP; Thu, 21 Jul 2016 16:31:56 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Fri, 22 Jul 2016 01:31:56 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Suresh Krishnan Content-Type: multipart/mixed; boundary=001a11410ed46d946b05382dba70 Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 23:32:25 -0000 --001a11410ed46d946b05382dba70 Content-Type: multipart/alternative; boundary=001a11410ed46d946505382dba6e --001a11410ed46d946505382dba6e Content-Type: text/plain; charset=UTF-8 Suresh, I strongly support the publication of this document. Since it defines a mechanism which can be used by several working groups, AD sponsoring seems perfect. I'm attaching the XML of the the -02 version of that draft in which I have corrected some typos. I'll let Tero and Pat decide what he wants to merge, if anything. These changes are for the authors' information only, they do NOT affect my support to publish this document. Thomas On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > I am considering AD sponsoring the following draft > > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 > > to request the allocation of an 802.15.4 information element from the IEEE > for use in the IETF protocols that may need it. If you have any concerns > either with the content of the draft or about requesting the IE at all > please > let me know before 2016/07/29. > > Thanks > Suresh > > NOTE: I have CCed: all the groups that I thought could be potentially > interested in this work. If you think I have missed out some WG(s) please > let > me know. > > _______________________________________________ > IoT-DIR mailing list > IoT-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/iot-dir > --001a11410ed46d946505382dba6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suresh,

I strongly support the publicat= ion of this document. Since it defines a mechanism which can be used by sev= eral working groups, AD sponsoring seems perfect.

= I'm attaching the XML of the the -02 version of that draft in which I h= ave corrected some typos. I'll let Tero and Pat decide what he wants to= merge, if anything. These changes are for the authors' information onl= y, they do NOT affect my support to publish this document.

Thomas

On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan <= suresh.kr= ishnan@ericsson.com> wrote:
Hi all,
=C2=A0 =C2=A0I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-kivinen-802-= 15-ie-02

to request the allocation of an 802.15.4 information element from the IEEE<= br> for use in the IETF protocols that may need it. If you have any concerns either with the content of the draft or about requesting the IE at all plea= se
let me know before 2016/07/29.

Thanks
Suresh

NOTE: I have CCed: all the groups that I thought could be potentially
interested in this work. If you think I have missed out some WG(s) please l= et
me know.

_______________________________________________
IoT-DIR mailing list
IoT-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/iot-dir

--001a11410ed46d946505382dba6e-- --001a11410ed46d946b05382dba70 Content-Type: text/xml; charset=US-ASCII; name="draft-kivinen-802-15-ie-02_tw.xml" Content-Disposition: attachment; filename="draft-kivinen-802-15-ie-02_tw.xml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqwy8jug0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHJmYyBTWVNU RU0gInJmYzI2MjkuZHRkIiBbCiAgICA8IUVOVElUWSByZmMyMTE5IFBVQkxJQyAnJyAKICAgICAg J2h0dHA6Ly94bWwycmZjLmlldGYub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMu MjExOS54bWwnPgpdPgoKPHJmYyBjYXRlZ29yeT0nc3RkJyBpcHI9J3RydXN0MjAwOTAyJwogICAg IGRvY05hbWU9J2RyYWZ0LWtpdmluZW4tODAyLTE1LWllLTAyLnR4dCc+Cgo8P3htbC1zdHlsZXNo ZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5LnhzbHQnID8+Cgo8P3JmYyB0b2M9J3ll cycgPz4KPD9yZmMgc3ltcmVmcz0neWVzJyA/Pgo8P3JmYyBzb3J0cmVmcz0neWVzJz8+Cjw/cmZj IGlwcm5vdGlmaWVkPSdubycgPz4KPD9yZmMgY29tcGFjdD0neWVzJyA/Pgo8P3JmYyBzdHJpY3Q9 J3llcycgPz4KCjxmcm9udD4KICA8dGl0bGU+SUVFRSA4MDIuMTUuNCBJbmZvcm1hdGlvbiBFbGVt ZW50IGZvciBJRVRGPC90aXRsZT4KICAgICAgICAKICA8YXV0aG9yIGluaXRpYWxzPSdULicgc3Vy bmFtZT0nS2l2aW5lbicgZnVsbG5hbWU9J1Rlcm8gS2l2aW5lbic+CiAgICA8b3JnYW5pemF0aW9u PklOU0lERSBTZWN1cmU8L29yZ2FuaXphdGlvbj4KICAgIDxhZGRyZXNzPgogICAgICA8cG9zdGFs PgogICAgICAgIDxzdHJlZXQ+RWVyaWtpbmthdHUgMjg8L3N0cmVldD4KICAgICAgICA8Y29kZT5G SS0wMDE4MDwvY29kZT4KICAgICAgICA8Y2l0eT5IRUxTSU5LSTwvY2l0eT4KICAgICAgICA8Y291 bnRyeT5GSTwvY291bnRyeT4KICAgICAgPC9wb3N0YWw+CiAgICAgIDxlbWFpbD5raXZpbmVuQGlr aS5maTwvZW1haWw+CiAgICA8L2FkZHJlc3M+CiAgPC9hdXRob3I+CiAgPGF1dGhvciBmdWxsbmFt ZT0iUGF0IEtpbm5leSIgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJLaW5uZXkiPgogICAgPG9yZ2Fu aXphdGlvbj5LaW5uZXkgQ29uc3VsdGluZyBMTEM8L29yZ2FuaXphdGlvbj4KICAgIDxhZGRyZXNz PgogICAgICA8cG9zdGFsPgoJPHN0cmVldC8+Cgk8Y2l0eS8+Cgk8cmVnaW9uLz4KCTxjb2RlLz4K CTxjb3VudHJ5Lz4KICAgICAgPC9wb3N0YWw+CiAgICAgIDxlbWFpbD5wYXQua2lubmV5QGtpbm5l eWNvbnN1bHRpbmdsbGMuY29tPC9lbWFpbD4KICAgIDwvYWRkcmVzcz4KICA8L2F1dGhvcj4KICA8 ZGF0ZSB5ZWFyPScyMDE2JyAvPgogIDxhcmVhPkludGVybmV0PC9hcmVhPgogIDxhYnN0cmFjdD4K ICAgIDx0PklFRUUgU3RkIDgwMi4xNS40IGhhcyBJbmZvcm1hdGlvbiBFbGVtZW50cyAoSUUpIHRo YXQgY2FuIGJlCiAgICB1c2VkIHRvIGV4dGVuZCA4MDIuMTUuNCBpbiBhbiBpbnRlcm9wZXJhYmxl IG1hbm5lci4gVGhlIElFRUUgODAyLjE1CiAgICBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSAo QU5BKSBtYW5hZ2VzIHRoZSByZWdpc3RyeSBvZiB0aGUKICAgIEluZm9ybWF0aW9uIEVsZW1lbnRz LCBhbmQgdGhpcyBkb2N1bWVudCByZXF1ZXN0cyBBTkEgdG8gYWxsb2NhdGUgYQogICAgbnVtYmVy IGZvciB0aGUgSUVURiwgYW5kIHByb3ZpZGVzIGluZm9ybWF0aW9uIG9uIGhvdyB0aGUgSUUgaXMK ICAgIGZvcm1hdHRlZCB0byBwcm92aWRlIHN1YiB0eXBlcy48L3Q+CiAgPC9hYnN0cmFjdD4KPC9m cm9udD4KCjxtaWRkbGU+CiAgPHNlY3Rpb24gdGl0bGU9J0ludHJvZHVjdGlvbic+CiAgICA8dD5J RUVFIFN0ZC4gODAyLjE1LjQgPHhyZWYgdGFyZ2V0PSJJRUVFLTgwMi0xNS00IiAvPiBoYXMKICAg IEluZm9ybWF0aW9uIEVsZW1lbnRzIChJRSkgdGhhdCBjYW4gYmUgdXNlZCB0byBleHRlbmQgODAy LjE1LjQgaW4gYW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuCiAgICBUaGVyZSBhcmUgdHdvIGRpZmZl cmVudCBJRQogICAgdHlwZXMsIEhlYWRlciBJRSBhbmQgUGF5bG9hZCBJRS4gVGhlIEhlYWRlciBJ RXMgYXJlIHBhcnQgb2YgdGhlCiAgICBNZWRpdW0gQWNjZXNzIENvbnRyb2wgKE1BQykgaGVhZGVy LCBhbmQgYXJlIG5ldmVyIGVuY3J5cHRlZCwKICAgIGJ1dCB0aGV5IG1heSBiZSBhdXRoZW50aWNh dGVkLiBNb3N0IG9mIHRoZSBIZWFkZXIgSUUgcHJvY2Vzc2luZyBpcwogICAgZG9uZSBieSB0aGUg TUFDLCBhbmQgSUVURiBwcm90b2NvbHMgc2hvdWxkIG5vdCBuZWVkIHRvIGV4dGVuZAogICAgdGhl bS4gVGhlIFBheWxvYWQgSUVzIGFyZSBwYXJ0IG9mIHRoZSBNQUMgcGF5bG9hZCBhbmQgdGhleQog ICAgbWF5IGJlIGVuY3J5cHRlZCBhbmQgYXV0aGVudGljYXRlZC48L3Q+CgogICAgPHQ+SUVURiBw cm90b2NvbHMgd2lsbCBuZWVkIHRvIGluY2x1ZGUgaW5mb3JtYXRpb24gaW4gdGhlIDgwMi4xNS40 CiAgICBmcmFtZXM7IHRoZSBzdGFuZGFyZCA4MDIuMTUuNCB3YXkgb2YgZG9pbmcgdGhpcyBpcyB0 byBpbmNsdWRlCiAgICBvbmUgb2YgbW9yZSBwYXlsb2FkIElFcyBpbiB0aGUgZnJhbWUgdGhhdCB3 aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9uLiBCZWNhdXNlCiAgICBvZiB0aGlzLCB0aGUgSUVU RiBuZWVkcyB0byBvYnRhaW4gYSBkZWRpY2F0ZWQgUGF5bG9hZCBJRSBmcm9tIHRoZSBJRUVFCiAg ICA4MDIuMTUgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKEFOQSkgPHhyZWYKICAgIHRhcmdl dD0nSUVFRS04MDItMTUtQU5BJyAvPi4gVGhlIHVwLXRvLWRhdGUgODAyLjE1IEFOQSBkYXRhYmFz ZQogICAgY2FuIGJlIGZvdW5kIGF0IDx4cmVmIHRhcmdldD0nSUVFRS04MDItMTUtQU5BLURCJyAv Pi48L3Q+CgogICAgPHQ+VGhlIDgwMi4xNS40IG9wZXJhdGlvbnMgbWFudWFsIDx4cmVmIHRhcmdl dD0nSUVFRS04MDItMTUtT1BTJwogICAgLz4gcHJvdmlkZXMgaW5mb3JtYXRpb24gb24gaG93IGEg c3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlvbiBtYXkKICAgIHJlcXVlc3QgYW4gYWxsb2NhdGlv biBvZiBhbiBJRS4gVG8gbWFrZSB0aGlzIHJlcXVlc3QsCiAgICB0aGUgc3RhbmRhcmRpemF0aW9u IG9yZ2FuaXphdGlvbiBuZWVkcyB0bzogcHJvdmlkZSB0aGUgcmVhc29uIGZvcgogICAgdGhlIHJl cXVlc3Q7IGEgZGVzY3JpcHRpb24gb2YgdGhlIHByb3RvY29sIGZvcm1hdCB0aGF0IHNob3dzIHRo ZXJlCiAgICBpcyBzdWZmaWNpZW50IHN1YnR5cGUgY2FwYWJpbGl0eTsgYSBzdGF0ZW1lbnQgdGhh dCB0aGUgZXh0ZXJuYWwKICAgIG9yZ2FuaXphdGlvbiB1bmRlcnN0YW5kcyB0aGF0IG9ubHkgb25l IElEIG51bWJlciB3aWxsIGJlCiAgICBpc3N1ZWQuPC90PgoKICAgIDx0PlRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlCiAgICByZXF1ZXN0LjwvdD4K CiAgIDwvc2VjdGlvbj4KCiAgIDxzZWN0aW9uIGFuY2hvcj0idGVybWlub2xvZ3kiIHRpdGxlPSJU ZXJtaW5vbG9neSI+CgogICAgPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTAogICAgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiCiAgICBpbiB0aGlzIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYKICAgIHRhcmdl dD0nUkZDMjExOScvPi48L3Q+CiAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbiB0aXRsZT0iVXNlcnMg b2YgdGhlIElFVEYgSUUiIGFuY2hvcj0idXNlcnMiPgogICAgPHQ+VGhlcmUgYXJlIHNldmVyYWwg SUVURiB3b3JraW5nIGdyb3VwcyBzdWNoIGFzIDZUaVNDSCwgNmxvLCBDb1JFCiAgICBldGMsIHdo aWNoIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgSUVURiBJRS4gVGhlIDZUaVNDSCB3b3JraW5nCiAg ICBncm91cCBoYXMgYWxyZWFkeSBleHByZXNzZWQgdGhlIG5lZWQgZm9yIHRoZSBJRSwgYW5kIHRo aXMKICAgIGFsbG9jYXRpb24gc2hvdWxkIHByb3ZpZGUgdGhlbSBhIHdheSBmb3J3YXJkLjwvdD4K ICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRpdGxlPSdJRVRGIElFIFN1YnR5cGUgRm9ybWF0JyBh bmNob3I9J2lldGYtaWUnPgoKICAgIDx0PlRoZSBtYXhpbXVtIGxlbmd0aCBvZiB0aGUgUGF5bG9h ZCBJRSBjb250ZW50IGlzIDIwNDcgb2N0ZXRzLAogICAgYW5kIDgwMi4xNS40IGZyYW1lIGNvbnRh aW5zIGEgbGlzdCBvZiBwYXlsb2FkIElFcywgaS5lLiBhIHNpbmdsZQogICAgZnJhbWUgY2FuIGhh dmUgbXVsdGlwbGUgcGF5bG9hZCBJRXMsIHRlcm1pbmF0ZWQgd2l0aCB0aGUgcGF5bG9hZAogICAg SUUgdGVybWluYXRvciwgYW5kIG1heSBiZSBmb2xsb3dlZCBieSB0aGUgcGF5bG9hZC48L3Q+Cgog ICAgPHQ+QmVjYXVzZSB0aGUgZnJhbWUgY29udGFpbnMgYSBsaXN0IG9mIHBheWxvYWRzLCB0aGVy ZSBpcyBubwogICAgbmVlZCB0byBwcm92aWRlIGludGVybmFsIHN0cnVjdHVyZSBpbnNpZGUgdGhl IElFVEYgSUUuIFRoZSBQYXlsb2FkCiAgICBJRSBmb3JtYXQgb2YgdGhlIDgwMi4xNS40IGNvbnRh aW5zIHRoZSBMZW5ndGggZmllbGQsIHNvIHRoZQogICAgbGVuZ3RoIG9mIHRoZSBTdWItVHlwZSBD b250ZW50IGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gdGhlIExlbmd0aAogICAgZmllbGQgb2YgdGhl IElFVEYgSUUuPC90PgoKICAgIDx0PlRoZSBmb3JtYXQgb2YgdGhlIElFVEYgSUUgaXMgYXMgZm9s bG93czo8L3Q+CiAgICAKICAgIDxmaWd1cmUgYW5jaG9yPSJpZXRmLWllLWZpZ3VyZSIgdGl0bGU9 IklFVEYgSUUgU3VidHlwZSBGb3JtYXQiID48YXJ0d29yaz48IVtDREFUQVsKICAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwp8IFN1Yi1UeXBlIElEICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAorLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp+ICAgICAgICAgICAgICAgICAgICAgICBTdWIt VHlwZSBDb250ZW50ICAgICAgICAgICAgICAgICAgICAgICAgfgp8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwpd XT48L2FydHdvcms+PC9maWd1cmU+CgogICAgPHQ+PGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAg ICA8dD5TdWItVHlwZSBJRCBpcyB0aGUgSUFOQSBhbGxvY2F0ZWQgbnVtYmVyIHNwZWNpZnlpbmcg dGhlCiAgICAgIHN1Yi10eXBlIG9mIHRoZSBJRVRGIElFLiBWYWx1ZSAwIGlzIHJlc2VydmVkIGZv ciBmdXR1cmUKICAgICAgZXh0ZW5zaWJpbGl0eSwgaS5lLiwgaW4gY2FzZSBhIGxvbmdlciBTdWIt VHlwZSBJRCBmaWVsZCBpcwogICAgICBuZWVkZWQuPC90PgoKICAgICAgPHQ+U3ViLVR5cGUgQ29u dGVudCBpcyB0aGUgYWN0dWFsIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uCiAgICAgIGVsZW1l bnQsIGFuZCBpdHMgbGVuZ3RoIGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gdGhlIExlbmd0aCBmaWVs ZAogICAgICBvZiB0aGUgSUVURiBJRS4gPC90PgogICAgPC9saXN0PjwvdD4KCiAgICA8dD5PbmUg SUVFRSA4MDIuMTUuNCBmcmFtZSBjYW4gY29udGFpbiBtdWx0aXBsZSBJRVRGIElFcyB3aXRoIHRo ZSBzYW1lCiAgICBvciBkaWZmZXJlbnQgc3ViIHR5cGVzLjwvdD4KICAgIAogIDwvc2VjdGlvbj4K CiAgPHNlY3Rpb24gdGl0bGU9IlZlbmRvciBTcGVjaWZpYyBJRSI+CgogICAgPHQ+SUVFRSA4MDIu MTUuNCBoYXMgYWxyZWFkeSBzZXZlcmFsIG51bWJlcnMgZm9yIGRpZmZlcmVudCBWZW5kb3IKICAg IFNwZWNpZmljIElFIHR5cGVzLiBUaGVyZSBpcyBvbmUgZm9yIHRoZSBWZW5kb3IgU3BlY2lmaWMg SGVhZGVyIElFCiAgICBmb3IgSGVhZGVyIElFcy4gVGhlcmUgaXMgb25lIGluY29ycmVjdGx5IG5h bWVkIFZlbmRvciBTcGVjaWZpYwogICAgTmVzdGVkIElFIGZvciBQYXlsb2FkIElFcywgYW5kIHRo ZXJlIGlzIGFub3RoZXIgb25lIHdpdGgKICAgIGV4YWN0bHkgdGhlIHNhbWUgbmFtZSwgYnV0IHVu ZGVyIHRoZSBNTE1FIE5lc3RlZCBJRSBsb25nIGZvcm1hdC4gQWxsCiAgICBvZiB0aGUgVmVuZG9y IFNwZWNpZmljIElFcyBzdGFydCB3aXRoIGEgMy1vY3RldCB2ZW5kb3IgT1VJIHRvCiAgICBpZGVu dGlmeSB0aGUgb3JnYW5pemF0aW9uLjwvdD4KCiAgICA8dD5CZWNhdXNlIG9mIHRoaXMsIHRoZXJl IGlzIG5vIG5lZWQgdG8gcmVzZXJ2ZSB0aGUgc3BlY2lmaWMKICAgIFN1Yi1UeXBlIElEcyBmb3Ig dGhlIHZlbmRvci1zcGVjaWZpYyB1c2VzLCBhcyB0aG9zZSBvdGhlciBJRSB0eXBlcwogICAgY2Fu IGJlIHVzZWQgZm9yIHRoYXQuPC90PgoKICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRpdGxlPSJS ZXF1ZXN0IHRvIGFsbG9jYXRlIElFVEYgSUUiPgogICAgPHQ+SUVURiB3b3VsZCByZXF1ZXN0IHRo ZSA4MDIuMTUuNCBXb3JraW5nIEdyb3VwIHRvIGFsbG9jYXRlIGEKICAgIFBheWxvYWQgSUUgZm9y IElFVEYgdXNlLiBGdXJ0aGVybW9yZSBJRVRGIHVuZGVyc3RhbmRzIHRoYXQgb25seQogICAgb25l IElEIHdpbGwgYmUgaXNzdWVkIHRvIGl0LjwvdD4KICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRp dGxlPSdTZWN1cml0eSBDb25zaWRlcmF0aW9ucyc+CgogICAgPHQ+VGhpcyBkb2N1bWVudCBjcmVh dGVzIGFuIElBTkEgcmVnaXN0cnkgZm9yIElFVEYgSUUgU3ViLXR5cGUKICAgIElEcywgYW5kIHRo ZSBzZWN1cml0eSBvZiB0aGUgcHJvdG9jb2xzIHVzaW5nIHRoZSBJRXMgbmVlZHMgdG8gYmUKICAg IGRlc2NyaWJlZCBpbiB0aGUgYWN0dWFsIGRvY3VtZW50cyBhbGxvY2F0aW5nIHZhbHVlcyBmcm9t IHRoaXMKICAgIHJlZ2lzdHJ5LjwvdD4KCiAgICA8dD5UaGUgSUVFRSBTdGQgODAyLjE1LjQtMjAx NSA8eHJlZiB0YXJnZXQ9IklFRUUtODAyLTE1LTQiIC8+CiAgICBjb250YWlucyBtZXRob2RzIHdo ZXJlIHNlY3VyaXR5IG9mIHRoZSBJRSBjYW4gYmUgZW5mb3JjZWQgd2hlbiBhCiAgICBmcmFtZSBp cyByZWNlaXZlZCwgYnV0IHRoaXMgaXMgb25seSBwZXIgSUUgdHlwZSwgdGh1cyBhbGwgSUVURiBJ RXMKICAgIHdpbGwgaGF2ZSBzYW1lIHNlY3VyaXR5IGxldmVsIHJlcXVpcmVtZW50cyByZWdhcmRs ZXNzIG9mIHRoZQogICAgU3ViLVR5cGUgSUQgdXNlZC4gVGhpcyBjYW4gY2F1c2UgaXNzdWVzIGlm IGRpZmZlcmVudCBzZWN1cml0eQogICAgcHJvY2Vzc2luZyB3b3VsZCBiZSBuZWVkZWQgYW5kIGFu eSBvZiB0aG9zZSBJRXMgd291bGQgbmVlZCB0byBiZQogICAgcHJvY2Vzc2VkIGluIHRoZSBNQUMg bGV2ZWwuIEZvcnR1bmF0ZWx5LCBldmVyeXRoaW5nIElFVEYgZG9lcwogICAgc2hvdWxkIGJlIGlu IGEgaGlnaGVyIGxldmVsIHRoYW4gdGhlIE1BQyBsZXZlbCwgdGh1cyB0aGUgaGlnaGVyCiAgICBs YXllciBwcm9jZXNzaW5nIGZvciB0aGVzZSBJRXMgbmVlZHMgdG8gcGVyZm9ybSBzZXBhcmF0ZSBz ZWN1cml0eQogICAgcG9saWN5IGNoZWNraW5nIGJhc2VkIG9uIHRoZSBJRVRGIElFIFN1Yi1UeXBl IElEIGluIGFkZGl0aW9uIHRvCiAgICB0aGUgY2hlY2tzIGRvbmUgYnkgdGhlIE1BQy48L3Q+Cgog IDwvc2VjdGlvbj4KICAKICA8c2VjdGlvbiB0aXRsZT0nSUFOQSBDb25zaWRlcmF0aW9ucycgYW5j aG9yPSdpYW5hJz4KCiAgICA8dD5UaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnkg Zm9yIElFVEYgSUUgU3ViLXR5cGUgSURzCiAgICByZWdpc3RyeTo8L3Q+CgogICAgPGZpZ3VyZT48 YXJ0d29yaz48IVtDREFUQVsKVmFsdWUgICAgIFN1Yi10eXBlIElECjAgICAgICAgICBSZXNlcnZl ZAoxLTIwMCAgICAgVW5hc3NpZ25lZAoyMDEtMjU1ICAgRXhwZXJpbWVudGFsIFVzZQpdXT48L2Fy dHdvcms+PC9maWd1cmU+CgogICAgPHQ+Q2hhbmdlcyBhbmQgYWRkaXRpb25zIHRvIHRoaXMgcmVn aXN0cnkgaXMgYnkgZXhwZXJ0IHJldmlldy48L3Q+CiAgICAgICAKICA8L3NlY3Rpb24+Cgo8L21p ZGRsZT4KPGJhY2s+CgogIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+ CiAgICAmcmZjMjExOTsKICA8L3JlZmVyZW5jZXM+CgogIDxyZWZlcmVuY2VzIHRpdGxlPSdJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzJz4KICAgIDxyZWZlcmVuY2UgYW5jaG9yPSdJRUVFLTgwMi0xNS00 Jz4KICAgICAgPGZyb250PgogICAgICAgIDx0aXRsZT5JRUVFIFN0YW5kYXJkIGZvciBMb3ctUmF0 ZSBXaXJlbGVzcyBQZXJzb25hbCBBcmVhCiAgICAgICAgTmV0d29ya3MgKFdQQU5zKTwvdGl0bGU+ Cgk8YXV0aG9yPjwvYXV0aG9yPgogICAgICAgIDxkYXRlIHllYXI9JzIwMTUnLz4KICAgICAgPC9m cm9udD4KICAgICAgPHNlcmllc0luZm8gbmFtZT0iSUVFRSIgdmFsdWU9IlN0YW5kYXJkIDgwMi4x NS40IiAvPgogICAgPC9yZWZlcmVuY2U+CgogICAgPHJlZmVyZW5jZSBhbmNob3I9J0lFRUUtODAy LTE1LUFOQScKCSAgICAgICB0YXJnZXQ9Imh0dHA6Ly93d3cuaWVlZTgwMi5vcmcvMTUvQU5BLmh0 bWwiPgogICAgICA8ZnJvbnQ+CiAgICAgICAgPHRpdGxlPklFRUUgODAyLjE1IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5PC90aXRsZT4KCTxhdXRob3I+PC9hdXRob3I+CiAgICAgICAgPGRhdGUg Lz4KICAgICAgPC9mcm9udD4KICAgIDwvcmVmZXJlbmNlPgoKICAgIDxyZWZlcmVuY2UgYW5jaG9y PSdJRUVFLTgwMi0xNS1BTkEtREInCgkgICAgICAgdGFyZ2V0PSdodHRwczovL21lbnRvci5pZWVl Lm9yZy84MDIuMTUvZG9jdW1lbnRzP2lzX2Rjbj0yNTcmYW1wO2lzX2dyb3VwPTAwMDAnPgogICAg ICA8ZnJvbnQ+CiAgICAgICAgPHRpdGxlPklFRUUgODAyLjE1IEFOQSBkYXRhYmFzZTwvdGl0bGU+ Cgk8YXV0aG9yPjwvYXV0aG9yPgogICAgICAgIDxkYXRlIC8+CiAgICAgIDwvZnJvbnQ+CiAgICA8 L3JlZmVyZW5jZT4KCiAgICA8cmVmZXJlbmNlIGFuY2hvcj0nSUVFRS04MDItMTUtT1BTJwoJICAg ICAgIHRhcmdldD0naHR0cHM6Ly9tZW50b3IuaWVlZS5vcmcvODAyLjE1L2RvY3VtZW50cz9pc19k Y249MjM1JmFtcDtpc19ncm91cD0wMDAwJz4KICAgICAgPGZyb250PgogICAgICAgIDx0aXRsZT5J RUVFIDgwMi4xNSBPcGVyYXRpb25zIE1hbnVhbDwvdGl0bGU+Cgk8YXV0aG9yPjwvYXV0aG9yPgog ICAgICAgIDxkYXRlIC8+CiAgICAgIDwvZnJvbnQ+CiAgICA8L3JlZmVyZW5jZT4KCiAgPC9yZWZl cmVuY2VzPgo8L2JhY2s+Cgo8L3JmYz4K --001a11410ed46d946b05382dba70-- From nobody Thu Jul 21 16:45:29 2016 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 A283412D1E4; Thu, 21 Jul 2016 16:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9leZ6JS4IN0; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 30F3B12D74E; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p74so88258870qka.0; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Ehcii1hf2lKhGdgwu2igm6uToYpA6zsvT1M7SjEK2Wg=; b=oUZ9E3Wt2h9rs6qRtvwb5SNAoeNQCIWNEk/KfY2VJXvFciivrbUhBfdo2B2l84/l53 ysRJi4Ypae/wMtx2ky/tL3yJW8UXYf6y9z7LKZsmOYhWxon9hMILccrTWbxt2F4AyVuv dOJ5AMexwSLq2AigY2lKQXD7iTbKH5vqHseEFENKPZAyN0X091k8lUzgUu6C3F5BHzU3 l+43Eale5yjQUIMSuwXLe31Jpou6m5HY1WCv+JerfuS/EMncf6Dbv/8/dB9WhRQtE/Uy knEBdQGkaG5YgPDDvOEOgDDIPB+DkWH2PHF9LbY779I9scFfQEzmOhnWHufw9lSH2KIs /BuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Ehcii1hf2lKhGdgwu2igm6uToYpA6zsvT1M7SjEK2Wg=; b=d2B31SvMMGuGZjFP5DmrnZLb4p/nWIRpZwKLfCL2+OeKuDg3ygdJbaK9KBhY/tPAKn OYlreVImpvdFER8O03O2lspbFFbQOLVo1nJAFEXEZs3WI1/GOfD3GYr2nkwOjwHRPiYp v7+dCsjs6d+DrgcBTYGaFFNDvyCr15vUAUBRJK0cj0dvOyXkSDtn97kmEaTCaAWv0VQx xsS2Mql//8ag+iQTnYT+O4/6re/Gnz06kW/hZNaUuabz3n4eCg/jlPkQp9Z6RMUfCTRH 3LZu4zQx9B+enUTJJVw1pVNmkRPm/Q3cloPf09TlzAgMg5g/iXMdQlX7QJUyReldIhyz GIzA== X-Gm-Message-State: AEkooutPaZG0dmixy+Pxzf8y8JokN0C5vMRIfJXtwupfH5inVibS/uY6Xv29m6d4/BBPAw== X-Received: by 10.55.201.136 with SMTP id m8mr1237723qkl.166.1469144706328; Thu, 21 Jul 2016 16:45:06 -0700 (PDT) Received: from rtp-vpn1-1829.cisco.com ([173.38.117.78]) by smtp.gmail.com with ESMTPSA id e33sm5724375qta.47.2016.07.21.16.45.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 16:45:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Ralph Droms In-Reply-To: Date: Fri, 22 Jul 2016 01:45:02 +0200 Message-Id: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 23:45:09 -0000 --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seems to me this document could easily be a working group document. Why = have you decided to publish it as AD sponsored document? - Ralph > On Jul 18, 2016, at 2:39 PM 7/18/16, Suresh Krishnan = wrote: >=20 > Hi all, > I am considering AD sponsoring the following draft >=20 > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 >=20 > to request the allocation of an 802.15.4 information element from the = IEEE > for use in the IETF protocols that may need it. If you have any = concerns > either with the content of the draft or about requesting the IE at all = please > let me know before 2016/07/29. >=20 > Thanks > Suresh >=20 > NOTE: I have CCed: all the groups that I thought could be potentially > interested in this work. If you think I have missed out some WG(s) = please let > me know. >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223 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 - http://gpgtools.org iQIcBAEBCAAGBQJXkV5+AAoJEINeeBNmFjV5NxYQAIjOdTko0MiOjEAbroyju3FG RiYcOCYrJ7iwbrNJhF86Wf15MPuY9JXHZX2B752yit3PnSuCZQMy1WkJa6YO3YtO 03AzOGhmTX/bX7qkxsrpHv3YbJaxjxQ27crqLZUzLcn2OX5QNETg/nfQkQI/eLN1 lhSZWyrHFhpY5Gr0xAO3nuQY5o9E5dx/LjeHi9aXGCDYBeGBhXhhFmlB3haxCz3+ hkFPx6c54wMMuX+/E+7SDExw2MichBsOO+HMU7jJiQEJGbNm39xBcbm59kP02ezC BpjRHO1QE+xUoyes4+byTGSA2dtzYb8p7EZMzN3+YVWY/FnVaZV8lMAoUdgus6+I VG9UyGjyMa9l8LV88q6ppBWan+8aTLLnIxOXrtzyT5ua2pWH7px3SczgsY18ygbN cRCmtQLT/uiwvfcawdRq1ufp1zsk3uC9/XQR65ml5ebIWSI+z03tryXmY59pAq1s rN3S58xRpjQk/kD408U9rLsSfnl9ojL4JT0Hs0Qfuag/A345dzZia5NNZVFBNGk3 Z7WK5Dwv4ILgpTdWzP6NGPTKseGADzX+ZnS7g/duZhwwjTdOZpj9+/genAK5VLby cypzeAL28SMz86SZmzRcSex/dPtso1MN7D/v2Euo6Jrzz1tceCHiOdI5r9vEU6Un TwQ7/wupFzDXRFhFHJkD =ASZI -----END PGP SIGNATURE----- --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223-- From nobody Fri Jul 22 00:02:30 2016 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 2FD2512D6A5 for ; Fri, 22 Jul 2016 00:02:29 -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 AG0nIRMSe9lj for ; Fri, 22 Jul 2016 00:02:27 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 B0F7B12D699 for ; Fri, 22 Jul 2016 00:02:27 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id s189so145175422vkh.1 for ; Fri, 22 Jul 2016 00:02:27 -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=TPLi82W3gxk27bVa0oh10BWp90CRyzYuOSQYmka4T0M=; b=ZpjRBq7ESrTIOO/dmVvqoefuBCAGU/jNEE8FGCmnkvVrNnlw1ZsPfVzFqPAaIlL2Cs A8q3f3D5btKjxCW2e0t6GZB8sZUE0N9jcrySCM9fe/yWfO75Qawrm0kIeDbcYT3VhjA2 gppFKTB60X38jugtDcPF5WDm+OXmx0ojBcIgTbBfiLrAv3QOlczZaZ4VlzHHp16mvKil XKtkfDdItcpV7+YNpUFVDwABWgQT8mYR7iANMyHm6jD5pBKpbUbLl9FP2B3LpXy1BHI1 0jGS1JvB3O3NhKjb7HpzZQaXRdf0Fzpye4VL8SM7r5duAw8GiYjT9QLPohuCWiwfy8BQ qCsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TPLi82W3gxk27bVa0oh10BWp90CRyzYuOSQYmka4T0M=; b=C/eyPueBK9P0X6R3aHAIhPL7TSsiBrekgxhZBsj7dydqWXoyHfHqoaJ1RwoHVHCxNe TVRhOTXIZOSz7y7c/kDnYzxmsO2NfJQJEhC/tLSXCjNuqWINGbLUZ6oXvVrbS8xUFPMj 7/Q5IpSF6ItwWSiHnVBKYWYa1CN04vC1pAl+bQN/lymjNi3r1vEFLAJKkp5yucH2HdeC M2/nQjufVysOAboCs22JeVOvUpoIJXdDzpXYwKa3/zwoAAzyibKGRLUj42Sr4i4sCKA8 TPOJ92/Rkcf9ubTRwZMy1MZ0d8oVX3GfqShrmQiKrBRGqzzL+97EUzCPyaSEbcJLowzF Nvjg== X-Gm-Message-State: AEkooutdOvKTZqqm66IhY5NYbVB/zZQV4pHwPkx13sbR5gi3/C3H9KVgxmSnVQLQpF6tEX3kgYar0OjZw/hIsg== X-Received: by 10.31.244.194 with SMTP id s185mr1065059vkh.121.1469170946423; Fri, 22 Jul 2016 00:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 22 Jul 2016 00:02:25 -0700 (PDT) From: Andy Bierman Date: Fri, 22 Jul 2016 00:02:25 -0700 Message-ID: To: Core Content-Type: multipart/alternative; boundary=94eb2c03d46c60528e05383404de Archived-At: Subject: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 07:02:29 -0000 --94eb2c03d46c60528e05383404de Content-Type: text/plain; charset=UTF-8 Hi, It seems to me that the only tagging actually needed would be to identify the ordered list of member types within a union type. typedef A { type union { type int32 ; // 1 type string; // 2 type B; // 3, 4, 5 type identityref { base bar; } // 6 } } typedef B { type union { type uint8; type uint16; type uint32; } } leaf foo { type A; } YANG allows the member types to be reordered if it does not change the value set accepted by the type. It is not clear if new member types can be added in new module revisions. If new member types are allowed in typedef B, then the relative position of (6) can change, even if typedef A does not change. YANG does not explicitly state if this is allowed or not. bits and enumerations can be expanded in new revisions, which changes the value set, but existing value and position numbers are not allowed to change. The problematic text is in 6020bis, sec 11 o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but an int8 type cannot be replaced by an int16, since the syntax would change. In practice reordering member types would be very rare, but the SID numbering would need to remember the member type order for each leaf or leaf-list that resolves to a union type. It doesn't help to tag any other type besides union. Andy --94eb2c03d46c60528e05383404de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

It seems to me that the only taggin= g actually needed
would be to identify the ordered list of member= types within a union type.


typedef= A {
=C2=A0 type union {
=C2=A0 =C2=A0 type int32 ; =C2= =A0 // 1
=C2=A0 =C2=A0 type string; // 2
=C2=A0 =C2=A0 = type B; =C2=A0 // 3, 4, 5
=C2=A0 =C2=A0 type identityref { base b= ar; } =C2=A0 // 6
=C2=A0 }
}

<= br>
typedef B {
=C2=A0 type union {
=C2=A0 = =C2=A0 type uint8;
=C2=A0 =C2=A0 type uint16;
=C2=A0 = =C2=A0 type uint32;
=C2=A0 }
}

leaf foo { type A; }

YANG allows the member types= to be reordered if it does not
change the value set accepted by = the type.=C2=A0 It is not clear
if new member types can be added = in new module revisions.

If new member types are a= llowed in typedef B, then the relative
position of (6) can change= , even if typedef A does not change.
YANG does not explicitly sta= te if this is allowed or not.

bits and enumeration= s can be expanded in new revisions,
which changes the value set, = but existing value and position numbers
are not allowed to change= .=C2=A0

The problematic text is in 6020bis, sec 11= 

  o  A "type" statement may be replaced =
with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.


In practice reordering membe= r types would be very rare, but
the SID numbering would need to r= emember the member type order for each leaf
or leaf-list that res= olves to a union type.

It doesn't help to tag = any other type besides union.


Andy<= /div>

--94eb2c03d46c60528e05383404de-- From nobody Fri Jul 22 00:31:15 2016 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 7703712DC13 for ; Fri, 22 Jul 2016 00:31:14 -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 O9i2Q5tVYE8J for ; Fri, 22 Jul 2016 00:31:12 -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 9A61412DC0F for ; Fri, 22 Jul 2016 00:31:12 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:b8cf:13f1:eab7:86a0] (unknown [IPv6:2001:67c:370:160:b8cf:13f1:eab7:86a0]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D182F1720AF; Fri, 22 Jul 2016 09:31:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Fri, 22 Jul 2016 09:31:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <326171CD-FA2F-436B-B8C0-94DD360FCCFD@ackl.io> References: To: Sean Leonard X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core Subject: Re: [core] Editorial fix: "sorely" in draft-ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 07:31:14 -0000 Hi Sean, Thanks for catching this. On the IP address - it is actually an excellent question on how we solve = this. The issue is that YANG defines an IPv6 address as a string with a = regex pattern : typedef ipv6-address { type string { pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + '(%[\p{N}\p{L}]+)?'; pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + '(%.+)?'; } } So, this means that the basic YANG-CBOR machinery converts an IP address = to a string=E2=80=A6 because it is a string.=20 I see two options here: 1) Redefine the basic types, e.g. through SID + conversion functions 2) Find some generic RegEx_compatible_string-to-binary way of doing this 3) Define in YANG-CBOR a binary serialization for the types = ietf-yang-types/ipv6-address, ietf-yang-types/ipv4-address, = ietf-yang-types/date-and-time, ietf-yang-types/mac-address 1) would be pretty straight-forward. We specify a number of = serialization/deserialization functions yang_type_TO_cbor_type and = vice-versa cbor_type_TO_yang_type : - define a couple of useful basic functions (IP + date/time.. not sure = other would be necessary for the moment) - in the SID file, when allocating a SID, the author of a file can = specify serialization/deserialization function. Only standard SID = functions should be supported, so a little caution here. Not sure how the 2) would work. 3) seems the easiest, and least extensible Of course, the simplest thing is to just do nothing in particular and = send IP addresses and dates as strings. Best, Alexander > Le 21 juil. 2016 =C3=A0 18:47, Sean Leonard a = =C3=A9crit : >=20 > Editorial fix: > For instance, CBOR tags are used sorely in the > case of the union datatype to distinguish explicitly the use of > different YANG datatypes encoded using the same CBOR major type. >=20 >=20 > Should be =E2=80=9Csolely=E2=80=9D. >=20 > Unless you are really sore about it. :) >=20 > Sean >=20 > PS The technical (non-editorial) part of this, is related to this text = + the example about IP addresses. Think about that and how to encode = IPv4 and IPv6 addresses more efficiently. Maybe a CBOR tag is useful; = maybe not. However my view is that two different CBOR tags are not = useful; it=E2=80=99s better to distinguish IPv4 vs. IPv6 by the length = of the (byte) string. From nobody Fri Jul 22 01:09:27 2016 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 23D0012D630 for ; Fri, 22 Jul 2016 01:09:26 -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 pModEJXU1osj for ; Fri, 22 Jul 2016 01:09:23 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1C912D5EB for ; Fri, 22 Jul 2016 01:09:21 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id x130so147498739vkc.0 for ; Fri, 22 Jul 2016 01:09:21 -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=UvNGTn7DcSIb5S/ggPQC3h8ppUO5WAb0PdJgYTJGeU4=; b=vnwuOzr1riTTurRtVzR1i3sE2xGzElVIjEcssVRB2fQ5mi93RD0jBBoYQwMX16UziB G2poCJgdpRit5XQydW6n8bMEo5XElV3qyvE7FiPew3PqysR0z/xw2yD1Nx+JxmWFz3M1 pZ+bDcQ152GXYeEV4rsZ+8nAgJ+JKsBctbH7fgj7Q99kTVV3f5lykgGBx1Kt0wAeYJkC MU3EFw5TXKzPO7sgCK4drR0Ay/Veyu/4UTSfLVF5eCaUdBZiuIg4sb0jBcvaosIKxgak EBLIN8KS+NXmyUXFJ1w0YkfgT/Ae60Kg1dUla27d3IWZ+frv4gnuLQ6k7Jmwaaw92U0Q Qayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UvNGTn7DcSIb5S/ggPQC3h8ppUO5WAb0PdJgYTJGeU4=; b=SLvxKYZl7mra42skP8Db3HjNE93SfaONQHuy9O2yWVOjdRQrOkMarxUkkQM2wH9fPE pwILsAyUMvdoZzVMwhI9zsbS/IgN3XFHsWtA+Y95ztRh9BrBi8m0fVVe3y/nfxrEWC/0 hQAK08uUxpdBB0cvNyghRvUCBnJa7rfZA5eUeQqcZdoFkxQ+hZA3nwAAAVSE0AEsKvpa qXwFdD16ek4raVh7oROl3HlLzQas+xfL/LR553WhkGyVJgmmqs+ef6gAkbmloFRWUFqs E/VC8sz/40BIw0Xxz7BfI1ytAOhT2oEInHdUYkKz2cpZCNFyvKhnS53VQ55gTfhCScz0 keZA== X-Gm-Message-State: AEkoous6rcIbu/qBa0GRqT+VvFZAB2+7qugdKyz1hmkXu1vW0X4zpEP7H3WF2tvoXv+juV8JrcPJ+SHSrp+Yrw== X-Received: by 10.31.244.194 with SMTP id s185mr1170439vkh.121.1469174960776; Fri, 22 Jul 2016 01:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 22 Jul 2016 01:09:20 -0700 (PDT) In-Reply-To: <326171CD-FA2F-436B-B8C0-94DD360FCCFD@ackl.io> References: <326171CD-FA2F-436B-B8C0-94DD360FCCFD@ackl.io> From: Andy Bierman Date: Fri, 22 Jul 2016 01:09:20 -0700 Message-ID: To: Alexander Pelov Content-Type: multipart/alternative; boundary=94eb2c03d46ca67efa053834f3f7 Archived-At: Cc: Core Subject: Re: [core] Editorial fix: "sorely" in draft-ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 08:09:26 -0000 --94eb2c03d46ca67efa053834f3f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2016 at 12:31 AM, Alexander Pelov wrote: > Hi Sean, > > Thanks for catching this. > > On the IP address - it is actually an excellent question on how we solve > this. The issue is that YANG defines an IPv6 address as a string with a > regex pattern : > > typedef ipv6-address { > type string { > pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' > + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' > + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' > + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' > + '(%[\p{N}\p{L}]+)?'; > pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' > + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' > + '(%.+)?'; > } > } > > What if the shorthand notation of the IPv6 address is actually shorter than the expanded binary format? The WG seems much more comfortable than me wrt/ accepting massive increases in code complexity in order to save a few bytes once in awhile. As it is, the client and server will need in-depth knowledge of all revisions of each YANG module -- much more than required for XML or JSON. Any flaws in this schema knowledge lead directly to interoperability bugs. Andy So, this means that the basic YANG-CBOR machinery converts an IP address to > a string=E2=80=A6 because it is a string. > > I see two options here: > 1) Redefine the basic types, e.g. through SID + conversion functions > 2) Find some generic RegEx_compatible_string-to-binary way of doing this > 3) Define in YANG-CBOR a binary serialization for the types > ietf-yang-types/ipv6-address, ietf-yang-types/ipv4-address, > ietf-yang-types/date-and-time, ietf-yang-types/mac-address > > > 1) would be pretty straight-forward. We specify a number of > serialization/deserialization functions yang_type_TO_cbor_type and > vice-versa cbor_type_TO_yang_type : > - define a couple of useful basic functions (IP + date/time.. not sure > other would be necessary for the moment) > - in the SID file, when allocating a SID, the author of a file can > specify serialization/deserialization function. Only standard SID functio= ns > should be supported, so a little caution here. > > Not sure how the 2) would work. > > 3) seems the easiest, and least extensible > > > Of course, the simplest thing is to just do nothing in particular and sen= d > IP addresses and dates as strings. > > Best, > Alexander > > > > > > Le 21 juil. 2016 =C3=A0 18:47, Sean Leonard a = =C3=A9crit : > > > > Editorial fix: > > For instance, CBOR tags are used sorely in the > > case of the union datatype to distinguish explicitly the use of > > different YANG datatypes encoded using the same CBOR major type. > > > > > > Should be =E2=80=9Csolely=E2=80=9D. > > > > Unless you are really sore about it. :) > > > > Sean > > > > PS The technical (non-editorial) part of this, is related to this text = + > the example about IP addresses. Think about that and how to encode IPv4 a= nd > IPv6 addresses more efficiently. Maybe a CBOR tag is useful; maybe not. > However my view is that two different CBOR tags are not useful; it=E2=80= =99s better > to distinguish IPv4 vs. IPv6 by the length of the (byte) string. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --94eb2c03d46ca67efa053834f3f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 22, 2016 at 12:31 AM, Alexander Pelov <= ;a@ackl.io> wr= ote:
Hi Sean,

Thanks for catching this.

On the IP address - it is actually an excellent question on how we solve th= is. The issue is that YANG defines an IPv6 address as a string with a regex= pattern :

typedef ipv6-address {
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern '((:|[0-9a-fA-F]{0,4}):)([0-9= a-fA-F]{0,4}:){0,5}'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ '((([0-9a-fA-F= ]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ '(((25[0-5]|2[= 0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ '(25[0-5]|2[0-= 4][0-9]|[01]?[0-9]?[0-9])))'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ '(%[\p{N}\p{L}= ]+)?';
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern '(([^:]+:){6}(([^:]+:[^:]+)|(= .*\..*)))|'
=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+ '(%.+)?';<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
}



What if the shorthand n= otation of the IPv6 address is actually shorter than
the expanded= binary format?

The WG seems much more comfortable= than me wrt/ accepting massive
increases in code complexity =C2= =A0in order to save a few bytes once in awhile.
As it is, the cli= ent and server will need in-depth knowledge of all revisions
of e= ach YANG module -- much more than required for XML or JSON.
Any f= laws in this schema knowledge lead directly to interoperability bugs.
=


Andy

So, this means that the basic YANG-CBOR machinery converts an IP address to= a string=E2=80=A6 because it is a string.

I see two options here:
1) Redefine the basic types, e.g. through SID + conversion functions
2) Find some generic RegEx_compatible_string-to-binary way of doing this 3) Define in YANG-CBOR a binary serialization for the types ietf-yang-types= /ipv6-address, ietf-yang-types/ipv4-address, ietf-yang-types/date-and-time,= ietf-yang-types/mac-address


1) would be pretty straight-forward. We specify a number of serialization/d= eserialization functions yang_type_TO_cbor_type and vice-versa cbor_type_TO= _yang_type :
=C2=A0 - define a couple of useful basic functions (IP + date/time.. not su= re other would be necessary for the moment)
=C2=A0 - in the SID file, when allocating a SID, the author of a file can s= pecify serialization/deserialization function. Only standard SID functions = should be supported, so a little caution here.

Not sure how the 2) would work.

3) seems the easiest, and least extensible


Of course, the simplest thing is to just do nothing in particular and send = IP addresses and dates as strings.

Best,
Alexander




> Le 21 juil. 2016 =C3=A0 18:47, Sean Leonard <dev+ietf@seantek.com> a =C3=A9crit :
>
> Editorial fix:
> For instance, CBOR tags are used sorely in the
>=C2=A0 =C2=A0case of the union datatype to distinguish explicitly the u= se of
>=C2=A0 =C2=A0different YANG datatypes encoded using the same CBOR major= type.
>
>
> Should be =E2=80=9Csolely=E2=80=9D.
>
> Unless you are really sore about it. :)
>
> Sean
>
> PS The technical (non-editorial) part of this, is related to this text= + the example about IP addresses. Think about that and how to encode IPv4 = and IPv6 addresses more efficiently. Maybe a CBOR tag is useful; maybe not.= However my view is that two different CBOR tags are not useful; it=E2=80= =99s better to distinguish IPv4 vs. IPv6 by the length of the (byte) string= .

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

--94eb2c03d46ca67efa053834f3f7-- From nobody Fri Jul 22 01:15:49 2016 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 1B11312D630 for ; Fri, 22 Jul 2016 01:15:48 -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 u-Go39X3-XDb for ; Fri, 22 Jul 2016 01:15:46 -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 3063212D1A4 for ; Fri, 22 Jul 2016 01:15:46 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:401c:825:45e6:764b] (unknown [IPv6:2001:67c:370:160:401c:825:45e6:764b]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 47655A80E6; Fri, 22 Jul 2016 10:15:43 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E399782-D688-4413-977F-851699FCB3A9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Fri, 22 Jul 2016 10:15:48 +0200 Message-Id: <4C7084A0-A821-4D07-925B-0DDD3DD811C2@ackl.io> References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 08:15:48 -0000 --Apple-Mail=_9E399782-D688-4413-977F-851699FCB3A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, That sounds great! We=E2=80=99ll have to see how to actually number the = elements with Tags. Not sure we can have parameters to Tags. So, it = should be something like: (Tag)[order, value] Do you think we can use the SIDs to achieve the same?=20 E.g. a leaf of type A would result in 6 SIDs from your example. The = question here would be if we=E2=80=99ll be losing to much SIDs by doing = this.=20 Best, Alexander > Le 22 juil. 2016 =C3=A0 09:02, Andy Bierman a = =C3=A9crit : >=20 > Hi, >=20 > It seems to me that the only tagging actually needed > would be to identify the ordered list of member types within a union = type. >=20 >=20 > typedef A { > type union { > type int32 ; // 1 > type string; // 2 > type B; // 3, 4, 5 > type identityref { base bar; } // 6 > } > } >=20 >=20 > typedef B { > type union { > type uint8; > type uint16; > type uint32; > } > } >=20 > leaf foo { type A; } >=20 > YANG allows the member types to be reordered if it does not > change the value set accepted by the type. It is not clear > if new member types can be added in new module revisions. >=20 > If new member types are allowed in typedef B, then the relative > position of (6) can change, even if typedef A does not change. > YANG does not explicitly state if this is allowed or not. >=20 > bits and enumerations can be expanded in new revisions, > which changes the value set, but existing value and position numbers > are not allowed to change.=20 >=20 > The problematic text is in 6020bis, sec 11 >=20 > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a = typedef, > but an int8 type cannot be replaced by an int16, since the = syntax > would change. >=20 >=20 > In practice reordering member types would be very rare, but > the SID numbering would need to remember the member type order for = each leaf > or leaf-list that resolves to a union type. >=20 > It doesn't help to tag any other type besides union. >=20 >=20 > Andy >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_9E399782-D688-4413-977F-851699FCB3A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Andy,

That sounds great! We=E2=80=99ll have to see how to actually = number the elements with Tags. Not sure we can have parameters to Tags. = So, it should be something like:
(Tag)[order, = value]

Do you = think we can use the SIDs to achieve the same? 
E.g. a leaf of type A would result in 6 SIDs from your = example. The question here would be if we=E2=80=99ll be losing to much = SIDs by doing this. 

Best,
Alexander


Le 22 juil. 2016 =C3=A0 09:02, = Andy Bierman <andy@yumaworks.com> a =C3=A9crit :

Hi,

It = seems to me that the only tagging actually needed
would be to identify the ordered list of member types within = a union type.


typedef A {
  type union {
    type = int32 ;   // 1
    type string; // = 2
    type B;   // 3, 4, 5
    type identityref { base bar; }   // = 6
  }
}


typedef B {
  type union = {
    type uint8;
    type uint16;
    = type uint32;
  }
}

leaf foo { type A; }

YANG allows the member types to be = reordered if it does not
change the value set = accepted by the type.  It is not clear
if new = member types can be added in new module revisions.

If new member types are = allowed in typedef B, then the relative
position of = (6) can change, even if typedef A does not change.
YANG does not explicitly state if this is allowed or = not.

bits and = enumerations can be expanded in new revisions,
which = changes the value set, but existing value and position numbers
are not allowed to change. 

The problematic text is in 6020bis, sec = 11

  o  =
A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.


In practice reordering member types = would be very rare, but
the SID numbering would = need to remember the member type order for each leaf
or leaf-list that resolves to a union type.

It doesn't help to tag = any other type besides union.


Andy

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

= --Apple-Mail=_9E399782-D688-4413-977F-851699FCB3A9-- From nobody Fri Jul 22 01:29:34 2016 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 CE2CA12DA35; Fri, 22 Jul 2016 01:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbKfsv38oIW2; Fri, 22 Jul 2016 01:29:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 8DAFD12D1A4; Fri, 22 Jul 2016 01:29:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6M8TOvm016279 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jul 2016 11:29:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6M8TNep008324; Fri, 22 Jul 2016 11:29:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22417.55651.808400.872940@fireball.acr.fi> Date: Fri, 22 Jul 2016 11:29:23 +0300 From: Tero Kivinen To: Thomas Watteyne In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 1 min Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6tisch] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 08:29:30 -0000 Thomas Watteyne writes: > I'm attaching the XML of the the -02 version of that draft in which I have > corrected some typos. I'll let Tero and Pat decide what he wants to merge, if > anything. These changes are for the authors' information only, they do NOT > affect my support to publish this document. Thanks, I have taken your most of your changes to my xml version, and I will publish new version soon, with those fixes. -- kivinen@iki.fi From nobody Fri Jul 22 01:33:56 2016 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 A153E12D1A4 for ; Fri, 22 Jul 2016 01:33:54 -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 Tuy9aSDhMT6g for ; Fri, 22 Jul 2016 01:33:52 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 3EE2312DA24 for ; Fri, 22 Jul 2016 01:33:51 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id s189so147685291vkh.1 for ; Fri, 22 Jul 2016 01:33:51 -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=YZXllgszDhg+nmlzPHR7TIEKYM58zZH7VyHP9f6jaXQ=; b=dZKS7HuJ7sryKjgFMatN54kETyhka0h/mBMfjESosB2/Ja+cxF+cDz6uxboxoRPUu/ yK2xVBSyESZXrM5kxrltYIOlgkd2Kx52/LkAKYVKNt+F5JscKT2V220GDBJZ2tBaxsK3 COLU+JLN3WZBKaNlnVRYRvI5ohqVeW5BM3i3wVPOlYlR2f+ehq/5OMIkZkgWI1W8UjkV AHBxGUDDFD14eEjA47t58q89jlQPyhoALYrQln7LlbSNZHl3fqu3Xs+lyKH+JyFUXfc4 fLS9qzQ/4bxFHNEsg/O9L78VxdOv09K7dNgy/ymwp/FO5aTSin0lCkb4Z3Ez6se4FQ8o 94TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YZXllgszDhg+nmlzPHR7TIEKYM58zZH7VyHP9f6jaXQ=; b=A6cMccOixRO0zA0R4kXX1+KjyVpqeXsNS82+U4+MB4DFknLKuJyLeJDoZPFMX5VuOr WsyrMzkAHYuLaFsDUfBT6rscsyFcXPY21WHFA8IRx29mbbvFz2YRIPJwrnTeOcNaNxaN xdepcRidAE61OtbJZEmu7cX9mbCTbPhfTsFbMuKrqA5sUreBYZD5wh6f0isW1undzPk9 Sk7R8kWPKl1xBVXkqQ2YI95pLQ1vUMQnPGhJKrJoaxndhROmD9L51D6bFi1vbQa58xmR gfL6vdBsIW74A7k4PP8NFEzMtFmpQv06LtgXfMsFs+v7qVFciXzXiacOiVp7LahIm9mD YoPw== X-Gm-Message-State: AEkooutyA3eUaa33eAFHlCNZCgp71q1ukgkSum1A8oPLPCdcSQYXWGGXWnrHbovODmnC9c5xMEqF/ZuKt8PXlQ== X-Received: by 10.176.69.210 with SMTP id u76mr1034204uau.16.1469176430413; Fri, 22 Jul 2016 01:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 22 Jul 2016 01:33:49 -0700 (PDT) In-Reply-To: <4C7084A0-A821-4D07-925B-0DDD3DD811C2@ackl.io> References: <4C7084A0-A821-4D07-925B-0DDD3DD811C2@ackl.io> From: Andy Bierman Date: Fri, 22 Jul 2016 01:33:49 -0700 Message-ID: To: Alexander Pelov Content-Type: multipart/alternative; boundary=94eb2c11c3043f5e560538354ba5 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 08:33:55 -0000 --94eb2c11c3043f5e560538354ba5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2016 at 1:15 AM, Alexander Pelov wrote: > Hi Andy, > > That sounds great! We=E2=80=99ll have to see how to actually number the e= lements > with Tags. Not sure we can have parameters to Tags. So, it should be > something like: > (Tag)[order, value] > > Do you think we can use the SIDs to achieve the same? > E.g. a leaf of type A would result in 6 SIDs from your example. The > question here would be if we=E2=80=99ll be losing to much SIDs by doing t= his. > > I don't know the best way to encode this in CBOR. I think you mean (Tag)[sid, value]. This should work, but the client and server might implement this by actually testing a value against the union type and determining the order value. It could be hard-coded with the SID as well. > Best, > Alexander > Andy > > > Le 22 juil. 2016 =C3=A0 09:02, Andy Bierman a =C3=A9= crit : > > Hi, > > It seems to me that the only tagging actually needed > would be to identify the ordered list of member types within a union type= . > > > typedef A { > type union { > type int32 ; // 1 > type string; // 2 > type B; // 3, 4, 5 > type identityref { base bar; } // 6 > } > } > > > typedef B { > type union { > type uint8; > type uint16; > type uint32; > } > } > > leaf foo { type A; } > > YANG allows the member types to be reordered if it does not > change the value set accepted by the type. It is not clear > if new member types can be added in new module revisions. > > If new member types are allowed in typedef B, then the relative > position of (6) can change, even if typedef A does not change. > YANG does not explicitly state if this is allowed or not. > > bits and enumerations can be expanded in new revisions, > which changes the value set, but existing value and position numbers > are not allowed to change. > > The problematic text is in 6020bis, sec 11 > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but an int8 type cannot be replaced by an int16, since the syntax > would change. > > > > In practice reordering member types would be very rare, but > the SID numbering would need to remember the member type order for each > leaf > or leaf-list that resolves to a union type. > > It doesn't help to tag any other type besides union. > > > Andy > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > --94eb2c11c3043f5e560538354ba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 22, 2016 at 1:15 AM, Alexander Pelov <= a@ackl.io> wro= te:
H= i Andy,

That sounds great! We=E2=80=99ll have to see how= to actually number the elements with Tags. Not sure we can have parameters= to Tags. So, it should be something like:
(Tag)[order, value]

Do you think we can use the SIDs to achieve the same= ?=C2=A0
E.g. a leaf of type A would result in 6 SIDs from your ex= ample. The question here would be if we=E2=80=99ll be losing to much SIDs b= y doing this.=C2=A0


<= div>I don't know the best way to encode this in CBOR.
I think= you mean =C2=A0(Tag)[sid, value].
This should work, but the clie= nt and server might implement this by
actually testing a value ag= ainst the union type and determining the order value.
It could be= hard-coded with the SID as well.


= =C2=A0
Best,
Alexander
=
Andy
=C2=A0


Le 22 juil. 2016 =C3=A0 09:02, Andy Bierman <andy@yumaworks.com>= a =C3=A9crit :

Hi,

It se= ems to me that the only tagging actually needed
would be to ident= ify the ordered list of member types within a union type.


typedef A {
=C2=A0 type union {
= =C2=A0 =C2=A0 type int32 ; =C2=A0 // 1
=C2=A0 =C2=A0 type string;= // 2
=C2=A0 =C2=A0 type B; =C2=A0 // 3, 4, 5
=C2=A0 = =C2=A0 type identityref { base bar; } =C2=A0 // 6
=C2=A0 }
<= div>}


typedef B {
=C2=A0 = type union {
=C2=A0 =C2=A0 type uint8;
=C2=A0 =C2=A0 ty= pe uint16;
=C2=A0 =C2=A0 type uint32;
=C2=A0 }
}

leaf foo { type A; }

= YANG allows the member types to be reordered if it does not
chang= e the value set accepted by the type.=C2=A0 It is not clear
if ne= w member types can be added in new module revisions.

If new member types are allowed in typedef B, then the relative
position of (6) can change, even if typedef A does not change.
= YANG does not explicitly state if this is allowed or not.

bits and enumerations can be expanded in new revisions,
w= hich changes the value set, but existing value and position numbers
are not allowed to change.=C2=A0

The problemati= c text is in 6020bis, sec 11

  o  A "type" statement may b=
e replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.


In practice reordering membe= r types would be very rare, but
the SID numbering would need to r= emember the member type order for each leaf
or leaf-list that res= olves to a union type.

It doesn't help to tag = any other type besides union.


Andy<= /div>

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


--94eb2c11c3043f5e560538354ba5-- From nobody Fri Jul 22 02:46:15 2016 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 2CE1212DA7E; Fri, 22 Jul 2016 01:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mqmeRzUQhiA; Fri, 22 Jul 2016 01:12:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 BD0D912DAAC; Fri, 22 Jul 2016 01:12:24 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6M8CJkL019028 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jul 2016 11:12:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6M8CJ8i015184; Fri, 22 Jul 2016 11:12:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22417.54627.526844.924720@fireball.acr.fi> Date: Fri, 22 Jul 2016 11:12:19 +0300 From: Tero Kivinen To: Ralph Droms In-Reply-To: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: X-Mailman-Approved-At: Fri, 22 Jul 2016 02:46:14 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 08:12:38 -0000 Ralph Droms writes: > Seems to me this document could easily be a working group document. > Why have you decided to publish it as AD sponsored document? As this will allocate number for the IETF, not for just one WG, the authors though it would be better to get as wide coverage for it, meaning having longer last call time, and advertising it in several different working groups (who might use it in the future), instead of having it for one WG draft in some WG. Also it was not clear which WG it should be in. I think 6tisch is the one who might need it first, but 6lo is most likely also going to using it etc. -- kivinen@iki.fi From nobody Fri Jul 22 03:22:09 2016 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 C637C12DFB2; Fri, 22 Jul 2016 03:22: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] 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 LxF7oL6VeQLA; Fri, 22 Jul 2016 03:22:05 -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 1D72E12DFB0; Fri, 22 Jul 2016 03:22:05 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A111643043; Fri, 22 Jul 2016 12:22:02 +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 B9B941B2; Fri, 22 Jul 2016 12:21:58 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-b449.meeting.ietf.org [31.133.180.73]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 19EF5D2; Fri, 22 Jul 2016 12:21:57 +0200 (CEST) Received: (nullmailer pid 1193 invoked by uid 1000); Fri, 22 Jul 2016 10:21:49 -0000 Date: Fri, 22 Jul 2016 12:21:49 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list , Cullen Jennings Message-ID: <20160722102148.GS26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VjP/dwTbBl6I9PQk" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: [core] SenML: bn/n URI clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 10:22:08 -0000 --VjP/dwTbBl6I9PQk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello SenML users, I've read the current draft in the sense that `bn` and `n` are URI-concatenated; yesterdays' 1400 meeting has shown that this is not the authors' intent, and the following WG meeting that we don't want to go that way either because names are not necessarily URIs and actually used thusly. The semantics of `bn` and `n` will therefore stay such that `bn` and `n` are joint using string concatenation. To keep SenML suitable for representing linked batches, I suggest that if the names have URI semantics (which the application would probably know because the interface it's using on says so, ie. core-interfaces et al should be updated to say that representations are SenML with URI semantics), the `bn+n` concatenation should be treated as relative to the requested URI. That facilitates expressing both external and internal URIs without the need to know and repeat one's own URI. This would need changes in the 4.3 section (maybe also other occurrences of Base Name) which currently says that an absent base name has the semantics of the requested URI being the base name, and given the general tendency not to have slash-terminated URIs, an empty base name would give unexpected results. My impression is that people who treat their names as non-URI strings might not want that (or even have interpreted it that way for otherwise it would have come up) -- or are you all just always setting bn? Cullen (as you've most prominently spoken out against URIs here) and others, what is your take on this? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --VjP/dwTbBl6I9PQk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXkfO1AAoJEDmNERLTpL3hI2UP/1bunagiUUXNevXUlBjPdLUa 820YgqafyIFAbQwbjLjRfkKLQo2tXkUCQjyU8LtGid0z2DUYD5V5CVmz50xCBP5t spooQamazM4dA+KPrU5q8DOaMii0zQ/YYFaZcRQx8O8707+/wM07L1Ou3hzVVeb8 fe+Dcg2zg11+Zqt3QTRCbu7cMMvtF48pHnK13pUD+WDVBxAbhiTCBvBWhG/4NNXG KKIM2GfgU2jARqe/T01obY3p9XtQFbHcl4zzWDn995L/icZhYZf5Q66apEojjCaL l+oDqa3I7RQ2mgCfnVMPQJE5sIsWuNR3dA63wLdSnbJbDnrLH3H3QE+AUsbsrBp0 dJN0a8pLf3FvUe59d+gtBbScPyPkE5vd5hQT+ctooa30unIV/dewrLoLL0m7vDuD klQW1nupwNdA7GrINcUR/8bMnXcn0aPFh2HCWzMRIxa07otH/kGPJQiwwzIg90L4 jaZBfeJdmqMN4+YWXbTzEyFE9qFA2yEWrDp4P66VXBk9k+7Expm6+d51usP2m7sQ caXra4fx5X6YL1OyJLdfN7ylDvAWhyolZQI8B2g/lBjUSzNmjFpOrU4uXq3gS3Qz 2fcBxXFCEbdmWeiEqsmD18nUYhqA/HzW4XWl5lK8O6BfoqD7Qs1zlYT6okRUWhFX rR9xqnMVfJ6KTJIpxIdI =4Xu4 -----END PGP SIGNATURE----- --VjP/dwTbBl6I9PQk-- From nobody Fri Jul 22 04:11:40 2016 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 6211412DCD3 for ; Fri, 22 Jul 2016 04:11:38 -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 Y872ewCVS18A for ; Fri, 22 Jul 2016 04:11:36 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 2541B12DCD1 for ; Fri, 22 Jul 2016 04:11:36 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id z8so78326574ywa.1 for ; Fri, 22 Jul 2016 04:11:36 -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=OQAsErAO2lfSOhRd0Cww4q2csdDL4wLAP8/sKSL5W1Y=; b=ugIL5LpxCOA098g1UO1hFROulEKxXIWpXOaex9aFo6PLWKWdruOHfD2+lW+A7Za93G WcNzZ8KGWTfqGoboVs8LO8tgPAA4ETtUWa3ZkLORIP7lFJH/QZcdPiUQN4KvescHI1TU WHdkBzhIo8Yi+ii97qbIgsOuU8Xtje83yaeauhyzOCY9MbjK5iLLZnsKrmgoq5oylOlw F27eYyZSJyH+iPrPn9j4pGkzYovgY8eqBzat1e9Nf4YrjdY2V5qKtqURXbRpeTjaQ+dZ t3WQJ6KPVoDEcj+YMa6jcnZoiPJOFoA5w4TN/m1Cixm2gEQv8tJHlKcLrHQUos0/wF03 odtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OQAsErAO2lfSOhRd0Cww4q2csdDL4wLAP8/sKSL5W1Y=; b=bveaWvfH9JXBg6NKSMd/W1thJRFSPLMq/sS4QH/6NVJ5+56RZemTL+Sl6jIwY5iADn SMs/NW3B/oLbeIZtgdaHQPjbfWijyBAu4kZQE/GZ9jCeb6Ed8cprNQ2NkI1vIicplByM 21Ulb19sD3YmQb2r1xuQEZuImxJBs9lOL7gulauAcmRx9bqtiSpPb3JRf3od+b+Q+MUX n02j/DL5QIYxX6apxpogDlgYjytto+wWEOoZc4HUwvBxibRWRbuPudtdeFgSt07V6dSA ScrXmdO1N1s6hMLOrXn4lGP7LwG0+MDdFLOoCWOxYLA9B3xbvzCC6uwtDCiYvL9n5Lgh VrVQ== X-Gm-Message-State: AEkoouu/LCQZ4xtWPUvCWGLNWO5KzBE5tcEUplNLkYFhIwE0dsk5IK+znBe3atvYFBAijg== X-Received: by 10.129.57.215 with SMTP id g206mr2416720ywa.37.1469185895342; Fri, 22 Jul 2016 04:11:35 -0700 (PDT) Received: from aither.local ([107.7.143.114]) by smtp.gmail.com with ESMTPSA id l81sm5161457ywb.56.2016.07.22.04.11.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 04:11:34 -0700 (PDT) To: Andy Bierman , Alexander Pelov References: <326171CD-FA2F-436B-B8C0-94DD360FCCFD@ackl.io> From: Peter Saint-Andre - Filament Message-ID: Date: Fri, 22 Jul 2016 07:11:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Core Subject: Re: [core] Editorial fix: "sorely" in draft-ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 11:11:38 -0000 On 7/22/16 4:09 AM, Andy Bierman wrote: > > > On Fri, Jul 22, 2016 at 12:31 AM, Alexander Pelov > wrote: > > Hi Sean, > > Thanks for catching this. > > On the IP address - it is actually an excellent question on how we > solve this. The issue is that YANG defines an IPv6 address as a > string with a regex pattern : > > typedef ipv6-address { > type string { > pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' > + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' > + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' > + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' > + '(%[\p{N}\p{L}]+)?'; > pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' > + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' > + '(%.+)?'; > } > } > > > > What if the shorthand notation of the IPv6 address is actually shorter than > the expanded binary format? > > The WG seems much more comfortable than me wrt/ accepting massive > increases in code complexity in order to save a few bytes once in awhile. > As it is, the client and server will need in-depth knowledge of all > revisions > of each YANG module -- much more than required for XML or JSON. > Any flaws in this schema knowledge lead directly to interoperability bugs. +1! Peter -- Peter Saint-Andre https://filament.com/ From nobody Fri Jul 22 04:16:48 2016 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 C60B012DCFB for ; Fri, 22 Jul 2016 04:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu30ffIIWduq for ; Fri, 22 Jul 2016 04:16:43 -0700 (PDT) Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.125]) (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 9FECE12DCF9 for ; Fri, 22 Jul 2016 04:16:43 -0700 (PDT) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E55C2C0126; Fri, 22 Jul 2016 07:16:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7885BC00F2; Fri, 22 Jul 2016 07:16:39 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-61-102-16.cisco.com ([UNAVAILABLE]. [173.38.220.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Fri, 22 Jul 2016 07:16:39 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20160722102148.GS26784@hephaistos.amsuess.com> Date: Fri, 22 Jul 2016 13:16:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160722102148.GS26784@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , Core WG mailing list Subject: Re: [core] SenML: bn/n URI clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 11:16:46 -0000 I=E2=80=99d prefer to just form an extension that was similar to bn and = n but had URI concatenation semantics.=20 One of my worries is that people that are naming things like = bn=3D=E2=80=9Cfoo=E2=80=9D and n=3D"/bar=E2=80=9D would be very = surprised when the result used to be =E2=80=9Cfoo/bar=E2=80=9D and it = suddenly became =E2=80=9C/bar=E2=80=9D I=E2=80=99d be glad to help write and extension like this=20 > On Jul 22, 2016, at 12:21 PM, Christian Ams=C3=BCss = wrote: >=20 > Hello SenML users, >=20 > I've read the current draft in the sense that `bn` and `n` are > URI-concatenated; yesterdays' 1400 meeting has shown that this is not > the authors' intent, and the following WG meeting that we don't want = to > go that way either because names are not necessarily URIs and actually > used thusly. The semantics of `bn` and `n` will therefore stay such = that > `bn` and `n` are joint using string concatenation. >=20 > To keep SenML suitable for representing linked batches, I suggest that > if the names have URI semantics (which the application would probably > know because the interface it's using on says so, ie. core-interfaces = et > al should be updated to say that representations are SenML with URI > semantics), the `bn+n` concatenation should be treated as relative to > the requested URI. That facilitates expressing both external and > internal URIs without the need to know and repeat one's own URI. >=20 > This would need changes in the 4.3 section (maybe also other = occurrences > of Base Name) which currently says that an absent base name has the > semantics of the requested URI being the base name, and given the > general tendency not to have slash-terminated URIs, an empty base name > would give unexpected results. My impression is that people who treat > their names as non-URI strings might not want that (or even have > interpreted it that way for otherwise it would have come up) -- or are > you all just always setting bn? >=20 > Cullen (as you've most prominently spoken out against URIs here) and > others, what is your take on this? >=20 > Best regards > Christian >=20 > --=20 > Christian Ams=C3=BCss | Energy Harvesting = Solutions GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > | ATU68476614 From nobody Fri Jul 22 05:44:36 2016 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 B44FE12D1F0; Fri, 22 Jul 2016 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 5OyDcoL8Y0pf; Fri, 22 Jul 2016 05:44:21 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 69B9812D62A; Fri, 22 Jul 2016 05:44:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,404,1464645600"; d="scan'208,217";a="227601884" Received: from mail-lf0-f41.google.com ([209.85.215.41]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jul 2016 14:44:18 +0200 Received: by mail-lf0-f41.google.com with SMTP id b199so84876429lfe.0; Fri, 22 Jul 2016 05:44:18 -0700 (PDT) X-Gm-Message-State: AEkooutVTV+wXjqVl5gni5zY2MkpPmjgG+/EfJQVVWhFV5fj6I/EnyrIQ0CJSK4uT58/QynUpuwPKISFqlsWuw== X-Received: by 10.25.89.65 with SMTP id n62mr2608729lfb.89.1469191457615; Fri, 22 Jul 2016 05:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.84 with HTTP; Fri, 22 Jul 2016 05:43:57 -0700 (PDT) In-Reply-To: <22417.55651.808400.872940@fireball.acr.fi> References: <22417.55651.808400.872940@fireball.acr.fi> From: Thomas Watteyne Date: Fri, 22 Jul 2016 14:43:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11411eb8f045cd053838ca21 Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6tisch] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 12:44:24 -0000 --001a11411eb8f045cd053838ca21 Content-Type: text/plain; charset=UTF-8 Awesome, thanks On Fri, Jul 22, 2016 at 10:29 AM, Tero Kivinen wrote: > Thomas Watteyne writes: > > I'm attaching the XML of the the -02 version of that draft in which I > have > > corrected some typos. I'll let Tero and Pat decide what he wants to > merge, if > > anything. These changes are for the authors' information only, they do > NOT > > affect my support to publish this document. > > Thanks, I have taken your most of your changes to my xml version, and > I will publish new version soon, with those fixes. > -- > kivinen@iki.fi > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11411eb8f045cd053838ca21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Awesome, thanks

On Fri, Jul 22, 2016 at 10:29 AM, Tero Kivinen <kivinen@= iki.fi> wrote:
Thomas Watte= yne writes:
> I'm attaching the XML of the the -02 version of that draft in whic= h I have
> corrected some typos. I'll let Tero and Pat decide what he wants t= o merge, if
> anything. These changes are for the authors' information only, the= y do NOT
> affect my support to publish this document.

Thanks, I have taken your most of your changes to my xml version, and
I will publish new version soon, with those fixes.
--
kivinen@iki.fi



--
_______________________________________

<= /font>
Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
= Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkele= y OpenWSN
Co-chair, IETF 6TiSCH

__________= _____________________________
--001a11411eb8f045cd053838ca21-- From nobody Fri Jul 22 11:02:42 2016 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 54A9B12DF7E; Fri, 22 Jul 2016 11:02:40 -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 73uZooi69Gca; Fri, 22 Jul 2016 11:02:38 -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 1C9FD12DF3E; Fri, 22 Jul 2016 11:02:37 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7AAEE4307B; Fri, 22 Jul 2016 20:02:35 +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 AA0C22F; Fri, 22 Jul 2016 20:02:34 +0200 (CEST) Received: from hephaistos.amsuess.com (prometheus.amsuess.com [5.9.147.112]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2DEC344; Fri, 22 Jul 2016 20:02:34 +0200 (CEST) Received: (nullmailer pid 32453 invoked by uid 1000); Fri, 22 Jul 2016 18:02:32 -0000 Date: Fri, 22 Jul 2016 20:02:32 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Cullen Jennings Message-ID: <20160722180232.GX7974@hephaistos.amsuess.com> References: <20160722102148.GS26784@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qicHaSekiYEWE95x" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , Core WG mailing list Subject: Re: [core] SenML: bn/n URI clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 18:02:40 -0000 --qicHaSekiYEWE95x Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Cullen, hello group, On Fri, Jul 22, 2016 at 01:16:36PM +0200, Cullen Jennings wrote: > I=E2=80=99d prefer to just form an extension that was similar to bn and n= but > had URI concatenation semantics.=20 This is worth considering IMO ("u" for URL is alredy used, href / base href might be candidates). It would separate name and URI users -- I'm not sure yet whether this would be good (because it clears things up and reduces conflict) or bad (because it limits interoperability). > One of my worries is that people that are naming things like bn=3D=E2=80= =9Cfoo=E2=80=9D > and n=3D"/bar=E2=80=9D would be very surprised when the result used to be > =E2=80=9Cfoo/bar=E2=80=9D and it suddenly became =E2=80=9C/bar=E2=80=9D The suggestion I have made in the quoted mail would not have that effect, we'd stick to string-concatenating bn and n. Just when an application wants to treat the resulting string as a URI, that would be interpreted in the context of the site (instead of, as the draft is now, always requiring full absolute URIs whenever a bn is given). Right now bn defaults to being the requested URI. I do not know whether "plain name users" are aware of that and always set a base name to a unique prefix (global uniqueness of the result is required right now), whether they are aware and are OK with the resulting name being an URI, or whether they'd be surprised if an implementation did a string concatenation of the requested URI and the name. Which patterns are actually useful or in use when using plain names? Best regards Christian --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --qicHaSekiYEWE95x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXkl+0AAoJEDmNERLTpL3hFAgQAIpBjgeAGDIDolRdPOvxQ9Yt HioAm1OryMa8xli7GpAoR3RzqN5zcA+c+ZtPm1ucLQT8euGZkXyHbWnmOKBhJUr7 nCzErZaPMtSSDcDa7tnk6frdo4K9TkSaAoSKDFuvh5rE4mr7fujOjvEmRdaRo+iP UPucOqIJZgvS/QP3ET5xHhemmUuggKr3r1xJc0Fz4qKczK6G+jwyOO91XcOnE2ad 0R6zZE4Q4SRbE79ifVM/kZ+Hp4OQyL4ATx76rYkrVGVn3a4fSuBPc/XcY6tMgvc/ jmLafb9ZnWMMn9LIkiFacISvgJH5SgPyjnQ5k4XhuYOdmcD63fEXZsM+PRzumynA t9e0LDQ51wE4jlo06Rw4QG5M8KBmE3mZwqA6v3TC40+GIQvFjKgFJ8UDvTx3sC2Q 4HS4SJGz9ysmuo1tzyUebzVu9XqP+jfmTXCbr5V0nddNUoAn5fsKqvO/NS3DwRFb ICNevcfA7i8Wu2aZKT2oNIz/jBrwx7k4frsRLIh4+y/GTR1hxKcv34mdYuIPC+0O 5/fqtitSj7sFY3OT6Jr/om9STW+HGWJZMH5g4wbdNy2EAwVVkf53kwAXQedoK8pH RaA12V3mz6PfLXROUlbVc4dc0B1aj51SA2cdSbz2/JO5gSttKINJWD/eo23y7na+ H9d44Z7Os7/VYNSVjx8b =E/Rc -----END PGP SIGNATURE----- --qicHaSekiYEWE95x-- From nobody Fri Jul 22 13:16:45 2016 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 618B712E11E; Fri, 22 Jul 2016 13:16:44 -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 OPMpPEB6wSv6; Fri, 22 Jul 2016 13:16:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE0412D8C7; Fri, 22 Jul 2016 13:16:40 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-4b-57927f256deb Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.27.12516.52F72975; Fri, 22 Jul 2016 22:16:38 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.150]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 22:16:37 +0200 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] SenML metadata label Thread-Index: AQHR4pEzyPh4RjwOs02hyOsOXsA5TKAhnIOAgAMPAoA= Date: Fri, 22 Jul 2016 20:16:36 +0000 Message-ID: References: <11450E74-8CDF-4EB3-903A-658BBC33509D@ericsson.com> <08ebaaca-3139-6db9-a498-ab315cbb8736@nteczone.com> In-Reply-To: <08ebaaca-3139-6db9-a498-ab315cbb8736@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="Windows-1252" Content-ID: <465CEEE88207A342934CE7E9D490A462@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2J7uK5a/aRwg9nPuSz2vV3PbPHz3RJm ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl7Hi5ibHgNFfFm+61zA2M+zm6GDk5JARMJP4dmMoI YYtJXLi3nq2LkYtDSOAIo8Tjjz8YIZwljBKnzuxgBqliE3CUOPVwLSuILSIgIdH5dT87iM0s 4Crxe+1NoAYODmEBDYkT+z0gSjQlJs7oYIOwrSTuzH3PBGKzCKhKXJuxlQXE5hWwl5i15AeY LSRQKvHk8gQwm1PAQWLqlhawVYxAx30/tYYJYpW4xK0n85kgjhaQWLLnPDOELSrx8vE/Vghb SWLF9kuMEPUGEu/PzWeGsK0lFu+ZDzVHW2LZwtfMEDcISpyc+YRlAqP4LCQrZiFpn4WkfRaS 9llI2hcwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyyg1t+6+5gXP3a8RCjAAejEg+v QvykcCHWxLLiytxDjBIczEoivB3VQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNL UrNTUwtSi2CyTBycUg2MqvdqhdKLM803GrwRv81SeO3+E7MdbF+mZZz71rvSgpH18B+Zxh6F DeH/XBpMv+meSCmramdKNshLMmdzOj73JofSzzz/lxMWne7x2mOzTblsvrFw7/OuwOI4n41O P3+v9FNODbrx3s8k8fu+vz++iJi5fE9+vvsSq4WR/mGnlQaFkw5OEt2uxFKckWioxVxUnAgA yCbwrK4CAAA= Archived-At: Cc: "draft-ietf-core-senml@ietf.org" Subject: Re: [core] SenML metadata label X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 20:16:44 -0000 Hi, Closing this thread: the proposed metadata would have been roughly similar = to "name" construct, but at Berlin meeting we decided that such metadata is= better to be handled with web links.=20 Cheers, Ari > On 20 Jul 2016, at 22:02, Christian Groves wrote: >=20 > Hello Ari, >=20 > Would this be roughly equivalent to the "name": construct from the propos= ed W3C thing descriptions? >=20 > Regards, Christian >=20 >=20 > On 21/07/2016 12:15 AM, Ari Ker=E4nen wrote: >> Hi, >>=20 >> Another proposed extension for SenML not yet in the draft is a "metadata= " field for SenML Records. This could be free-form UTF-8 text, like string = value (sv). Unlike sv, you can have this *and* a value. >>=20 >> Use cases include "international names" that you can't use as part of "n= " label due to the URI compatible restriction, adding "tags" that describe = your data, etc. >>=20 >> This seems like a simple thing with reasonable trade-off between value a= nd extra complexity. >>=20 >> We welcome proposals for the name and label of this thing. I'd suggest "= metadata" and "m". >>=20 >>=20 >> Cheers, >> Ari >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 From nobody Sat Jul 23 02:52:58 2016 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 0F43512B054 for ; Sat, 23 Jul 2016 02:52:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3_44Fn-I4gN for ; Sat, 23 Jul 2016 02:52:55 -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 60FC512B056 for ; Sat, 23 Jul 2016 02:52:55 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7F1B8A00EC; Sat, 23 Jul 2016 05:52:50 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id EB65DA00E7; Sat, 23 Jul 2016 05:52:49 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.167.19] ([UNAVAILABLE]. [173.38.220.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sat, 23 Jul 2016 05:52:50 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_961F01FF-A1A6-4B0F-8BE0-BA44B56FF38C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20160722180232.GX7974@hephaistos.amsuess.com> Date: Sat, 23 Jul 2016 03:52:48 -0600 Message-Id: <26C2E2B5-AE40-42A5-A0A5-0DCAEDAC168C@iii.ca> References: <20160722102148.GS26784@hephaistos.amsuess.com> <20160722180232.GX7974@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-core-senml@ietf.org" , Core WG mailing list Subject: Re: [core] SenML: bn/n URI clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jul 2016 09:52:57 -0000 --Apple-Mail=_961F01FF-A1A6-4B0F-8BE0-BA44B56FF38C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 22, 2016, at 12:02 PM, Christian Ams=C3=BCss = wrote: >=20 >>=20 >> One of my worries is that people that are naming things like = bn=3D=E2=80=9Cfoo=E2=80=9D >> and n=3D"/bar=E2=80=9D would be very surprised when the result used = to be >> =E2=80=9Cfoo/bar=E2=80=9D and it suddenly became =E2=80=9C/bar=E2=80=9D= >=20 > The suggestion I have made in the quoted mail would not have that > effect, we'd stick to string-concatenating bn and n. Just when an > application wants to treat the resulting string as a URI, that would = be > interpreted in the context of the site (instead of, as the draft is = now, > always requiring full absolute URIs whenever a bn is given). I=E2=80=99m less keen on things where what stuff means changes depending = on what applications is using it. For things that perhaps just validate = and pretty print SenML they might not even know what the context was. = We=E2=80=99ve been using SenML as a normalized format for storage of = data in a big data system and there it is also no clear the context.=20 --Apple-Mail=_961F01FF-A1A6-4B0F-8BE0-BA44B56FF38C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 22, 2016, at 12:02 PM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:


One of my worries is that people = that are naming things like bn=3D=E2=80=9Cfoo=E2=80=9D
and = n=3D"/bar=E2=80=9D would be very surprised when the result used to be
=E2=80=9Cfoo/bar=E2=80=9D and it suddenly became = =E2=80=9C/bar=E2=80=9D

The suggestion I = have made in the quoted mail would not have that
effect, we'd stick = to string-concatenating bn and n. Just when an
application wants = to treat the resulting string as a URI, that would be
interpreted in the = context of the site (instead of, as the draft is now,
always requiring = full absolute URIs whenever a bn is = given).

I=E2=80=99m less keen on things where what stuff means = changes depending on what applications is using it. For things that = perhaps just validate and pretty print SenML they might not even know = what the context was. We=E2=80=99ve been using SenML as a normalized = format for storage of data in a big data system and there it is also no = clear the context. 


= --Apple-Mail=_961F01FF-A1A6-4B0F-8BE0-BA44B56FF38C-- From nobody Sat Jul 23 03:18:41 2016 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 0F8F912D948 for ; Sat, 23 Jul 2016 03:18:35 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Mbb-qx7Ee4Jl for ; Sat, 23 Jul 2016 03:17:58 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFED12D91A for ; Sat, 23 Jul 2016 03:17:57 -0700 (PDT) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id C47ECFB8B8; Sat, 23 Jul 2016 12:17:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id g-vUUUDXTQYU; Sat, 23 Jul 2016 12:17:53 +0200 (CEST) X-Originating-IP: 109.45.1.36 Received: from nar-3.local (ip-109-45-1-36.web.vodafone.de [109.45.1.36]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id F1441FB8B9; Sat, 23 Jul 2016 12:17:52 +0200 (CEST) Message-ID: <57934454.2090205@tzi.org> Date: Sat, 23 Jul 2016 12:17:56 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] CoRE @ IETF96: summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jul 2016 10:18:35 -0000 While the minutes are being prepared, here is a summary of the results of the CoRE meetings at IETF96. (Please send any corrections needed to the chairs or to the list; we will prefix this summary to the minutes.) Jaime and Carsten # Tuesday 2016-07-19 * draft-ietf-core-block-21.txt is in the RFC editor queue. * draft-ietf-core-etch–01: WGLC is completed, issues discussed. To be determined: 4.12 vs. 4.09. When that is settled, updated version to be submitted to IESG. * draft-ietf-core-links-json–06 is in the middle of WGLC (till 2016-07-30) and was briefly discussed. There are some claims in the document that it considers a larger world of JSON-LD etc.; the intention however is to be a simple RFC 6690 mapping and those claims will be cut down. * draft-ietf-core-coap-tcp-tls–03: The merge of TCP/TLS, Websockets, Signaling, and BERT was completed in this version. Several issues discussed. In particular, there was in-room consensus to follow the lead of RFC 7252 and make the use of TLS mandatory to implement. * with the larger number of transport schemes now available, draft-silverajan-core-coap-protocol-negotiation-03 was discussed. There is good interest in this ongoing work, some of which is also related to other ongoing work in T2TRG. * draft-ietf-core-resource-directory–08 is nearing WGLC; reviewers have been identified. * Brief introductions were made for draft-gomez-core-tcp-constrained-node-networks–00, draft-groves-coap-webrtcdc–00, draft-zheng-core-coap-lantency-evaluation–00. * For draft-bormann-core-cocoa-04, there was in-room consensus for working-group adoption; to be confirmed on the list. # Thursday 2016-07-21 * draft-ietf-core-http-mapping-13 took some minor fixes and has been submitted to IESG on 2016-07-22. * For the core-interfaces draft, the split was confirmed into draft-ietf-core-interfaces–05 and draft-groves-core-dynlink–00 (plus some material that was removed and maybe can be picked up by T2TRG); as not enough people had read the split-off draft-groves, we will take the otherwise obvious adoption to the list. * draft-ietf-core-yang-cbor–02: target is to do some additional validation with the NetMod experts and check again by end of September. There are a couple of implementations ongoing. * draft-somaraju-core-sid–01. One suggestion wsas to use a OID subtree. Too few people had read the newest version for room consensus on working-group adoption, but noone against; to be taken to the list. * draft-veillette-core-cool & draft-vanderstok-comi: around 6 people read the draft, agreement on splitting out the more advanced features so a basic specification can be completed by the end of the year. Work ongoing on mapping YANG and LWM2M/IPSO objects. Some concerns about the diagnostic value of SIDs in debugging and possible problems with YANG "choice", work needs to continue. * draft-hartke-core-e2e-security-reqs–01: good rewrite; further requirements are being identified, discussion to be taken to the mailing list. * draft-selander-ace-object-security–05: room consensus to adopt as WG item, to be confirmed on the mailing list. * draft-ietf-core-senml–02: good ongoing discussion that should be completed on the mailing list. * draft-koster-core-coap-pubsub–05: brokerless pubsub has been added. Take adoption to mailing list but clear room consensus already (~10 people), reviewers identified. From nobody Sat Jul 23 06:47:10 2016 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 3BAA712DA57; Sat, 23 Jul 2016 04:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 IugFUxgXJ9DV; Sat, 23 Jul 2016 04:30:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F38912D110; Sat, 23 Jul 2016 04:30:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BD3B2203AD; Sat, 23 Jul 2016 07:39:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B0170638BE; Sat, 23 Jul 2016 07:30:18 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22417.54627.526844.924720@fireball.acr.fi> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-Mailman-Approved-At: Sat, 23 Jul 2016 06:47:09 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , Ralph Droms , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jul 2016 11:30:22 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > meaning having longer last call time, and advertising it in several > different working groups (who might use it in the future), instead of > having it for one WG draft in some WG. > Also it was not clear which WG it should be in. I think 6tisch is the > one who might need it first, but 6lo is most likely also going to > using it etc. This makes me ask a question about 802.15.9: would a new KMP created by the IETF for 15.9 (such as OSCOAP or DTLS) need to use an IE under this subtype? Or does 15.9 have it's own registry, and if so would we need different liason request for that? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5NVR4CLcPvd0N1lAQIR7gf+PqzBdKtG9KHlsMZ+8Qadn0/717on1htM jmmFgtDNZGQZbqJEGhMcCHsOEgi7y6pwcrTiWgs8gQtV2y5NLEH5bmUL1W67TCa+ 7ggnoZuRNqU6404TmI/1XrLvjcPTamjMbeKv1JFhbUSUBhLUj7gOUisGNtIJW52u b3Sgxt9X69hcJ+Q17KTIZxdyMlqnMp8FmdrHYYMMP9vniYySzRZm6dL7eCrOQpFd iP952rBehCygTEpzHlSPRw5A9cBPCM/an/QGZzFuOhz920MlqPHlNp6XN7EqlzG8 07SB7UhuZ2jtH4fT59abialUpncY+aSnVLBFSvzqfPDJcswjKMwTyA== =jcGn -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 23 16:05:00 2016 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 93AC112D61B for ; Sat, 23 Jul 2016 16:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOsumuJ40Ymq for ; Sat, 23 Jul 2016 16:04:57 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 24F3112D13E for ; Sat, 23 Jul 2016 16:04:57 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u134so132182914ywg.3 for ; Sat, 23 Jul 2016 16:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ZoB5RIj15OzCGtAh/sEBT9XnTbC2KODnTppd/Nt03Vo=; b=wkOp1EGgo7ru56N8uGl/nj1XUeFjXEfK9sH96Rp5LSQN7mfkO1hGkUVffCsHMcH6g3 SI14VPpMb/wbBxLtKhxWpkp8Tj6xMYsxRqacY9UCp2oyNQQ/stI2XxTOFrU5ZhiA/Tsf vQoGwd9WJj7x5kmswneXr+JPVd6RrOou8f3SZgxl+R1c08rz8Dhh44O5okq00r6j3W+h DqhxVf3l9cBMOJzZwGRFwpW2RTUP01O6KOx7XvYd88eD5RXaqqX5luy0n8dkbPubs1Oz suO4qOoUosNXrcsJ4eoC8rab1wRTfinAjWOQOfKIXi83zSxAoWJgl2porJ8JkkGS/Cvv T0yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZoB5RIj15OzCGtAh/sEBT9XnTbC2KODnTppd/Nt03Vo=; b=T5m2ETZrPxzk6bNgkmT8SWS0Hc5uA/Pf9m48rA3TQTnOVa0Hh0bARkmAuhvUq5UMKx SWR4BIAJnKDgLhqFeVRG5Kl0P8Zv1fOsVTAj2828MAJkRlnNWAj8uMsTDF4n3EtA4Aus tZDP9xYxB6k7GK8GjaBlE+MRhBhPrge/Yw2N5/vwm7HjZRtwrvPTrya9JnQ4d0V20zNN YA2mZWii2Bphevj+JarBP7fhnueUROnQlbGW69czK/yZjBWMNOFXuLk/syRP9ZobEGVd aJwn0tauKtaUtjDTeBVSurHzFnPz3/Ko1yedcJrHx9sAmSUTYcwBesYWXGLNSYCkBHMP s4DQ== X-Gm-Message-State: AEkooutiCPncseMoAvvX0GIfMlXe9eNkewZjbVHpIh4H7dACFwVGRHxFacPb7k+PvZ/0xbQhh7/i3WQUf0RnIw== X-Received: by 10.37.230.141 with SMTP id d135mr9318996ybh.111.1469315096412; Sat, 23 Jul 2016 16:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.13 with HTTP; Sat, 23 Jul 2016 16:04:55 -0700 (PDT) In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5C04299F@NABESITE.InterDigital.com> References: <36F5869FE31AB24485E5E3222C288E1F5C03FB20@NABESITE.InterDigital.com> <36F5869FE31AB24485E5E3222C288E1F5C04299F@NABESITE.InterDigital.com> From: Badis Djamaa Date: Sun, 24 Jul 2016 01:04:55 +0200 Message-ID: To: "Rahman, Akbar" , "core@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03e3126288cf0538559485 Archived-At: Subject: Re: [core] FYI - Resource Directory article in The Internet Protocol Journal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jul 2016 23:04:59 -0000 --94eb2c03e3126288cf0538559485 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Akbar for the reminder. Hi Akbar, members, Thank you for posting this informative article. The RD draft employs reactive resource discovery to detect the presence of an RD, which might be inefficient when the number of providers/clients increases. We have proposed Proactive RD Discovery (PRD) allowing an RD to advertise its presence to the network. I thought it maybe useful to share a first version of this work-in-progress with list members for eventual discussions. http://www.sciencedirect.com/science/article/pii/S1877050916301296 Best, badis On Thursday, 21 July 2016, Rahman, Akbar wrote: > Hi Badis, > > > > Thanks for the nice link and I will look at it. But you didn=E2=80=99t c= opy the > CORE lis so if you want other people to read your article please resend t= he > email to the whole list! > > > > Akbar > > > > *From:* Badis Djamaa [mailto:badis.djamaa@gmail.com > ] > *Sent:* Thursday, July 21, 2016 11:05 AM > *To:* Rahman, Akbar > *Subject:* Re: [core] FYI - Resource Directory article in The Internet > Protocol Journal > > > > Hi Akbar, members, > > Thank you for posting this informative article. > > The RD draft employs reactive resource discovery to detect the presence o= f > an RD, which might be inefficient when the number of providers/clients > increases. We have proposed Proactive RD Discovery (PRD) allowing an RD t= o > advertise its presence to the network. I thought it maybe useful to share= a > first version of this work-in-progress with list members for eventual > discussions. > > http://www.sciencedirect.com/science/article/pii/S1877050916301296 > > Best, badis > > > > > > > > > This e-mail is intended only for the use of the individual or entity to > which it is addressed, and may contain information that is privileged, > confidential and/or otherwise protected from disclosure to anyone other > than its intended recipient. Unintended transmission shall not constitute > waiver of any privilege or confidentiality obligation. If you received th= is > communication in error, please do not review, copy or distribute it, noti= fy > me immediately by email, and delete the original message and any > attachments. Unless expressly stated in this e-mail, nothing in this > message or any attachment should be construed as a digital or electronic > signature. > > On 19 July 2016 at 16:43, Rahman, Akbar > wrote: > > FYI =E2=80=93 Some people suggested I send this info to the list for back= ground > reading on the RD (especially as the RD draft is now nearing for WGLC). > > > > We wrote a tutorial style article on =E2=80=9CResource Discovery for the = IoT=E2=80=9D that > was published in the June Internet Protocol Journal. Since it describes > the work done in CORE WG related to the RD it will hopefully be interesti= ng > to the members of this list. > > > > > > http://ipj.dreamhosters.com/wp-content/uploads/issues/2016/ipj19-2.pdf > > > > > > > > Best Regards, > > > > > > Akbar > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > --94eb2c03e3126288cf0538559485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank yo= u Akbar for the reminder.

Hi Akbar, members,

Thank you for posting this informative article.=C2= =A0

The RD draft employs reactive resource discovery to detect the p= resence of an RD, which might be inefficient when the number of providers/c= lients increases. We have proposed Proactive RD Discovery (PRD) allowing an= RD to advertise its presence to the network. I thought it maybe useful to = share a first version of this work-in-progress with list members for eventu= al discussions.

http://www.sciencedirect.com/s= cience/article/pii/S1877050916301296

Best, badis=C2=A0


On Thur= sday, 21 July 2016, Rahman, Akbar <Akbar.Rahman@interdigital.com> wrote:

Hi Badis,

=C2=A0

Thanks for the nice link and I will l= ook at it.=C2=A0 But you didn=E2=80=99t copy the CORE lis so if you want ot= her people to read your article please resend the email to the whole list!

=C2=A0

Akbar

=C2=A0

From: Badis Djamaa [mailto:badis.djamaa@gmail.com]
Sent: Thursday, July 21, 2016 11:05 AM
To: Rahman, Akbar <Akbar.Rahman@InterDigital.com>
Subject: Re: [core] FYI - Resource Directory article in The Internet= Protocol Journal

=C2=A0

Hi Akbar, members,=

Thank you for posting= this informative article.

The RD draft employs reactive resource discovery to detect the presence of = an RD, which might be inefficient when the number of providers/clients incr= eases. We have proposed Proactive RD Discovery (PRD) allowing an RD to adve= rtise its presence to the network. I thought it maybe useful to share a first version of this work-in-progres= s with list members for eventual discussions.

http://www.sciencedirect.com/science/article/pii/S187= 7050916301296

Best, badis

=C2=A0






This e-mail is intended onl= y for the use of the individual or entity to which it is addressed, and may= contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other th= an its intended recipient. Unintended transmission shall not constitute wai= ver of any privilege or confidentiality obligation. If you received this co= mmunication in error, please do not review, copy or distribute it, notify me immediately by email, and del= ete the original message and any attachments. Unless expressly stated in th= is e-mail, nothing in this message or any attachment should be construed as= a digital or electronic signature.

On 19 July 2016 at 16:43, Rahman, Akbar <Akbar.Rahman@interdigital.com> wrote:

FYI =E2=80=93 Some people suggested I send this info= to the list for background reading on the RD (especially as the RD draft i= s now nearing for WGLC).=C2=A0

=C2=A0

We wrote a tutorial style article on =E2=80=9CResour= ce Discovery for the IoT=E2=80=9D that was published in the June Internet P= rotocol Journal.=C2=A0 Since it describes the work done in CORE WG related to the RD it will hopefully be interesting to the members of this list.=

=C2=A0

=C2=A0

http://ipj.dreamhosters.co= m/wp-content/uploads/issues/2016/ipj19-2.pdf

=C2=A0

=C2=A0

=C2=A0

Best Regards,

=C2=A0

=C2=A0

Akbar


_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

=C2=A0

--94eb2c03e3126288cf0538559485-- From nobody Sat Jul 23 23:04:27 2016 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 8EFE112D639 for ; Sat, 23 Jul 2016 12:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.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 UI49AhjQWbcg for ; Sat, 23 Jul 2016 12:26:34 -0700 (PDT) Received: from nm47-vm5.bullet.mail.ne1.yahoo.com (nm47-vm5.bullet.mail.ne1.yahoo.com [98.138.121.101]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DB812D77B for ; Sat, 23 Jul 2016 12:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1469301991; bh=N7v2GMKFE2NmnZumKgBTMmJH2KBK14YVaxesBSz2jNU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=SSWeqUOBfYj9aN6MbKkVgFmgYgzHcmEkR/TF9m1kJnjlQbFQac4TN4Ci2+H++SY8mZlUmYm14EVWvfzelsmo4kOcq0Hzt4C4RP6955OA1EkkMEcFpGFuaZzXWlRmbfCF22HIafA3kdtws7bTYDZ7pfDMQvWCqVW9/8jzmHwbMeQ= Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:26:31 -0000 Received: from [98.138.226.177] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:23:42 -0000 Received: from [98.138.226.58] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:20:54 -0000 Received: from [127.0.0.1] by smtp209.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:20:54 -0000 X-Yahoo-Newman-Id: 54038.44352.bm@smtp209.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: qRHBZqQVM1lXX.5le6Fw0oW3FhlNwv2H0MiGDH4ZPOyqkLQ CHo0a8ggOR3wDfmkvqw1_vPGn8lMEDgkDzhFQ_zKh3opf8oSEwQb2nsJJLu_ ciUjT8ZctkEhBAU4bZ9SNgyhD_0qc5hP08vC9M9AChKUX1fx6lXCjwQhjiNO NQoKsqapWlcxz3CQdzaCCHF5nOWMIxvs6IKEPAIJn35t6v5Rv4PpQiWb4C_R DNztc8Q4sa1tEBvVyJ.NFkx0eQZmLju04yWILHeAnk07VFzoaqYB_.D5x9Oi 9zsMhxrY0I4NpgS_U_j_3YCobD1NCpat0CgDU8ttzZwPQKCMBT8GhCiS.vOq rnCcAJhiUBQJE3e_G5VEy.Ee2uiA7nKZvQjGDKjwKSuAe9f24vWicKTBslaZ v9JX4sdjCZdnup8aODXT3dbLpQuWUDsXJqVPB1XOQ7DIO_mw4MM.XTXZnd1v VcGPS4us.bWyZLFB95wDfu16FBHfqK8wNm.8lllGX6sZbpIPnqK5zkT_h454 E08I8a5FBevX5_7QniBoiayP0_8brUoX1SwzjxJEvfRH0uQZTRgmc3FM2JlD qIAEF1klzxnD4vOSkNJULRg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Don Sturek X-Mailer: iPad Mail (13F69) In-Reply-To: <31079.1469273418@obiwan.sandelman.ca> Date: Sat, 23 Jul 2016 12:20:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> <31079.1469273418@obiwan.sandelman.ca> To: Michael Richardson Archived-At: X-Mailman-Approved-At: Sat, 23 Jul 2016 23:04:25 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org>, Ralph Droms Subject: Re: [core] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jul 2016 19:26:35 -0000 Hi Michael IEEE 802.15.9 defines a multiplex ID covered by the IEEE 802.15 ANA. To def= ine a new KMP would only require a new annex that describes how the KMP work= s and an allocation of a new Multiplex ID. There is also a vendor specific multiplex ID that could be used now without a= ny written description in IEEE 802.15 Don Sent from my iPad > On Jul 23, 2016, at 4:30 AM, Michael Richardson wr= ote: >=20 >=20 > Tero Kivinen wrote: >> meaning having longer last call time, and advertising it in several >> different working groups (who might use it in the future), instead of >> having it for one WG draft in some WG. >=20 >> Also it was not clear which WG it should be in. I think 6tisch is the >> one who might need it first, but 6lo is most likely also going to >> using it etc. >=20 > This makes me ask a question about 802.15.9: would a new KMP created by t= he > IETF for 15.9 (such as OSCOAP or DTLS) need to use an IE under this subtyp= e? > Or does 15.9 have it's own registry, and if so would we need different lia= son > request for that? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Mon Jul 25 05:59:58 2016 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 AEF3112D853 for ; Mon, 25 Jul 2016 05:59:56 -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 qijG3w2Za4oH for ; Mon, 25 Jul 2016 05:59:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 033C812D84A for ; Mon, 25 Jul 2016 05:59:52 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id F3B0D1CC0282; Mon, 25 Jul 2016 14:59:56 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Core In-Reply-To: References: User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 25 Jul 2016 15:00:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 12:59:57 -0000 Andy Bierman writes: > Hi, > > It seems to me that the only tagging actually needed > would be to identify the ordered list of member types within a union type. > > > typedef A { > type union { > type int32 ; // 1 > type string; // 2 > type B; // 3, 4, 5 > type identityref { base bar; } // 6 > } > } > > > typedef B { > type union { > type uint8; > type uint16; > type uint32; > } > } > > leaf foo { type A; } > > YANG allows the member types to be reordered if it does not > change the value set accepted by the type. It is not clear I don't think this is true. The only statement in 6020bis that is related to this issue is the bullet that you cite below, but IMO reordering member types in a union type definition may change the type semantics because the receiving side resolves the type according to the order of member types. Lada > if new member types can be added in new module revisions. > > If new member types are allowed in typedef B, then the relative > position of (6) can change, even if typedef A does not change. > YANG does not explicitly state if this is allowed or not. > > bits and enumerations can be expanded in new revisions, > which changes the value set, but existing value and position numbers > are not allowed to change. > > The problematic text is in 6020bis, sec 11 > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but an int8 type cannot be replaced by an int16, since the syntax > would change. > > > > In practice reordering member types would be very rare, but > the SID numbering would need to remember the member type order for each leaf > or leaf-list that resolves to a union type. > > It doesn't help to tag any other type besides union. > > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 07:22:06 2016 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 CC12B12D8C0 for ; Mon, 25 Jul 2016 07:22:05 -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 fIqA98JHrFFH for ; Mon, 25 Jul 2016 07:22:04 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 A61F712D8CB for ; Mon, 25 Jul 2016 07:22:00 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id s189so245248614vkh.1 for ; Mon, 25 Jul 2016 07:22:00 -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=+7uwA5d5i54VYUQdjMcsMXOIo7sQWjnaZ3uv85fcEGA=; b=pMblytu3+V9MXjLKfKH3u/YZ+Z9Ot2gMDbi9W9wc1yBu8xEYArYEpcIuB8jQDvb7pQ nR//vVRV05gMUv27spauKyeE4TIItV7qpeWkBlxNBnOj4vQuTOYJoqRWiI7VeSZLz9l6 X1q4Tw7LPDMcNJJiVK3TM20FP5H8x6SGwZRflV5X/oxNc0mbcmcA4HTOFaumHj/SCfi0 bsVicJvCAXnDaNFdn6E+CjL4/57NFXMugPva32QjXU5PsS86ZZJOmAet57DPWUQmT6Qk nNHl4MgxTsWkvWAkHvHIovRAqHy/Xs72jShtpMIL/dfVzNImK0fg2UZq0VwQ4JfxHbtA Vsxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+7uwA5d5i54VYUQdjMcsMXOIo7sQWjnaZ3uv85fcEGA=; b=GC7sXJSwU5dNK2+I6egr7JmQ+wmHjXNmTPElZOfelpQ8RcqAEuzFHJCpoR44jsgjDp 2qAWLyt8xHb7MjxOOHuStvFeL+C6IXB6sp91Lt1L82lCR/ZwIj6IDJRPFQYZbQ5hDKIo UPdzVyM83D2eqafzDtU1V/6Cxe1pAo3kA6UoP9zyNLsJB7nTY4xwfBcHQBHUmV5IDGTt 3bnipyGf4+Re0bJM4jZWMQV0yBIZuLnOvoIq9i6jZrHzSLtnWsP/63yGFNxFbMWI5Cf/ Pgy1Mp3qWQBfC1PbJWYt+NNQNBNV2Hj86ONBZcjFCq3vGf2sVSOErw72gNWhiVqYES7V 0HjA== X-Gm-Message-State: AEkooutmeuvE0ihlTaNVbAn/wmvuraHXPO6vrrxlToB2DLqrPaPCOsPEhqwEuX9E/WB+x/IGyncGQrWF/nT8Jw== X-Received: by 10.31.252.203 with SMTP id a194mr7272820vki.44.1469456519743; Mon, 25 Jul 2016 07:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 25 Jul 2016 07:21:59 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Mon, 25 Jul 2016 07:21:59 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c149bd4df5b3c053876811f Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 14:22:06 -0000 --94eb2c149bd4df5b3c053876811f Content-Type: text/plain; charset=UTF-8 On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > It seems to me that the only tagging actually needed > > would be to identify the ordered list of member types within a union > type. > > > > > > typedef A { > > type union { > > type int32 ; // 1 > > type string; // 2 > > type B; // 3, 4, 5 > > type identityref { base bar; } // 6 > > } > > } > > > > > > typedef B { > > type union { > > type uint8; > > type uint16; > > type uint32; > > } > > } > > > > leaf foo { type A; } > > > > YANG allows the member types to be reordered if it does not > > change the value set accepted by the type. It is not clear > > I don't think this is true. The only statement in 6020bis that is > related to this issue is the bullet that you cite below, but IMO > reordering member types in a union type definition may change the type > semantics because the receiving side resolves the type according to the > order of member types. > > This depends on the format, but non-overlapping member types can change position without changing syntax or semantics. The exact member type that matches is not important. typedef foo1 { type union { type int32 { range "1..10"; } type int32 { range "11..20"; } } } typedef foo2 { type union { type int32 { range "11..20"; } type int32 { range "1..10"; } } } Lada > Andy > > > if new member types can be added in new module revisions. > > > > If new member types are allowed in typedef B, then the relative > > position of (6) can change, even if typedef A does not change. > > YANG does not explicitly state if this is allowed or not. > > > > bits and enumerations can be expanded in new revisions, > > which changes the value set, but existing value and position numbers > > are not allowed to change. > > > > The problematic text is in 6020bis, sec 11 > > > > o A "type" statement may be replaced with another "type" statement > > that does not change the syntax or semantics of the type. For > > example, an inline type definition may be replaced with a typedef, > > but an int8 type cannot be replaced by an int16, since the syntax > > would change. > > > > > > > > In practice reordering member types would be very rare, but > > the SID numbering would need to remember the member type order for each > leaf > > or leaf-list that resolves to a union type. > > > > It doesn't help to tag any other type besides union. > > > > > > Andy > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --94eb2c149bd4df5b3c053876811f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> It seems to me that the only tagging actually needed
> would be to identify the ordered list of member types within a union t= ype.
>
>
> typedef A {
>=C2=A0 =C2=A0type union {
>=C2=A0 =C2=A0 =C2=A0type int32 ;=C2=A0 =C2=A0// 1
>=C2=A0 =C2=A0 =C2=A0type string; // 2
>=C2=A0 =C2=A0 =C2=A0type B;=C2=A0 =C2=A0// 3, 4, 5
>=C2=A0 =C2=A0 =C2=A0type identityref { base bar; }=C2=A0 =C2=A0// 6
>=C2=A0 =C2=A0}
> }
>
>
> typedef B {
>=C2=A0 =C2=A0type union {
>=C2=A0 =C2=A0 =C2=A0type uint8;
>=C2=A0 =C2=A0 =C2=A0type uint16;
>=C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0}
> }
>
> leaf foo { type A; }
>
> YANG allows the member types to be reordered if it does not
> change the value set accepted by the type.=C2=A0 It is not clear

I don't think this is true. The only statement in 6020bis that is
related to this issue is the bullet that you cite below, but IMO
reordering member types in a union type definition may change the type
semantics because the receiving side resolves the type according to the
order of member types.



This depends on the for= mat, but non-overlapping member types
can change position without= changing syntax or semantics.
The exact member type that matches= is not important.

=C2=A0 =C2=A0typedef foo1 {
=C2=A0 =C2=A0 =C2=A0 type union {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0type int32 { range "1..10"; }
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0type int32 { range "11..20"; }
= =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

<= div>=C2=A0=C2=A0typedef foo2 {
=C2=A0 =C2=A0 =C2=A0 type union {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "11..20= "; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { rang= e "1..10"; }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 = =C2=A0 }



Lada

Andy
=C2=A0

> if new member types can be added in new module revisions.
>
> If new member types are allowed in typedef B, then the relative
> position of (6) can change, even if typedef A does not change.
> YANG does not explicitly state if this is allowed or not.
>
> bits and enumerations can be expanded in new revisions,
> which changes the value set, but existing value and position numbers > are not allowed to change.
>
> The problematic text is in 6020bis, sec 11
>
>=C2=A0 =C2=A0o=C2=A0 A "type" statement may be replaced with = another "type" statement
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that does not change the syntax or semantics= of the type.=C2=A0 For
>=C2=A0 =C2=A0 =C2=A0 =C2=A0example, an inline type definition may be re= placed with a typedef,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0but an int8 type cannot be replaced by an in= t16, since the syntax
>=C2=A0 =C2=A0 =C2=A0 =C2=A0would change.
>
>
>
> In practice reordering member types would be very rare, but
> the SID numbering would need to remember the member type order for eac= h leaf
> or leaf-list that resolves to a union type.
>
> It doesn't help to tag any other type besides union.
>
>
> Andy
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--94eb2c149bd4df5b3c053876811f-- From nobody Mon Jul 25 07:41:20 2016 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 A7CF312D0B6 for ; Mon, 25 Jul 2016 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yQH5bBCKgJ0 for ; Mon, 25 Jul 2016 07:41:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2E412B042 for ; Mon, 25 Jul 2016 07:41:16 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e068:c1e3:3a4a:5298] (unknown [IPv6:2001:718:1a02:1:e068:c1e3:3a4a:5298]) by mail.nic.cz (Postfix) with ESMTPSA id E6DD860869; Mon, 25 Jul 2016 16:41:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469457674; bh=5U/qNsiJPPfqD9jdQ3aifRjK5rxW/x3tnDjWo/ybonQ=; h=From:Date:To; b=eOhc1Tc+tFifVAIF/SvWTIeY7G7YsopmLpImVmBq7kHXzHMje01GB3A7wuglZrXng vLy1ZMX/7oqRO0YS5qcyUMDalQpxJP8rv+YwCIik+NIFdlcx4jsFN5C45e7umUFplL 4ht/TFlqExDKpc+nmJncWkM6XWMJFbSYlDKpE77U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 25 Jul 2016 16:41:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 14:41:19 -0000 > On 25 Jul 2016, at 16:21, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > Hi, > > > > It seems to me that the only tagging actually needed > > would be to identify the ordered list of member types within a union = type. > > > > > > typedef A { > > type union { > > type int32 ; // 1 > > type string; // 2 > > type B; // 3, 4, 5 > > type identityref { base bar; } // 6 > > } > > } > > > > > > typedef B { > > type union { > > type uint8; > > type uint16; > > type uint32; > > } > > } > > > > leaf foo { type A; } > > > > YANG allows the member types to be reordered if it does not > > change the value set accepted by the type. It is not clear >=20 > I don't think this is true. The only statement in 6020bis that is > related to this issue is the bullet that you cite below, but IMO > reordering member types in a union type definition may change the type > semantics because the receiving side resolves the type according to = the > order of member types. >=20 >=20 >=20 > This depends on the format, but non-overlapping member types > can change position without changing syntax or semantics. Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping = members: "1.2.3.4" is valid as both "inet:ip-address" and = "inet:domain-name". Lada > The exact member type that matches is not important. >=20 > typedef foo1 { > type union { > type int32 { range "1..10"; } > type int32 { range "11..20"; } > } > } >=20 > typedef foo2 { > type union { > type int32 { range "11..20"; } > type int32 { range "1..10"; } > } > } >=20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > if new member types can be added in new module revisions. > > > > If new member types are allowed in typedef B, then the relative > > position of (6) can change, even if typedef A does not change. > > YANG does not explicitly state if this is allowed or not. > > > > bits and enumerations can be expanded in new revisions, > > which changes the value set, but existing value and position numbers > > are not allowed to change. > > > > The problematic text is in 6020bis, sec 11 > > > > o A "type" statement may be replaced with another "type" = statement > > that does not change the syntax or semantics of the type. For > > example, an inline type definition may be replaced with a = typedef, > > but an int8 type cannot be replaced by an int16, since the = syntax > > would change. > > > > > > > > In practice reordering member types would be very rare, but > > the SID numbering would need to remember the member type order for = each leaf > > or leaf-list that resolves to a union type. > > > > It doesn't help to tag any other type besides union. > > > > > > Andy > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 09:05:44 2016 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 9072712D107 for ; Mon, 25 Jul 2016 09:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 2OboYeAoJvFt for ; Mon, 25 Jul 2016 09:05:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE48712D728 for ; Mon, 25 Jul 2016 09:05:41 -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=TQERZWVyDJAb7joD0a6z03t01XhzpNmy4rSQQ/gjIjQ=; b=tBwtmh8cu4eCysp8HXjXmQ8vBEop4iU5FsnysYZmPyzMLkf8R4NQT/DiZjx1xT8CkIImUBifmpHxbH6DJIql7uTGpQ0MZcSeFl6CHjje6ZaIkBTiKt4777s+E77Ip8zABV3JBb+oCVEjWrHI5DhZWwWNxGNOiQSBASyl7UMIiPM= 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_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 16:05:39 +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.0544.014; Mon, 25 Jul 2016 16:05:39 +0000 From: Michel Veillette To: Ladislav Lhotka , Andy Bierman Thread-Topic: [core] fixing YANG to CBOR Thread-Index: AQHR4+cJQt79bN4pMU+XasZI/tqalKApIRsAgAAW5YCAAAVwAIAAEGZQ Date: Mon, 25 Jul 2016 16:05:38 +0000 Message-ID: References: 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 61215d1d-30e0-4793-60db-08d3b4a5856f x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 6:pUgYEGPLEwaAeebBBPs8Jj6uML6LF2Fk7rk+E65Fm3EMuwbceQAFkP5FJ6YnFz9vcYbLCpIuyo4aWTlCtzSZe8+Ur/nFtGhmvMO0/XNmHtCKtPsXtZdtZQz4ix13FAylGLczNJ8Xr9cttx1m9euO3KU33hr1NQsIZyQv1NYBezHT7p0cAlx5d3csYHjgZxpcIp4uD1bWoYAOAW7gPi2/3gxqSiy7bsh1Yw7x7e6F1ujr2osqvcr4kub0RF5tXl5htHypWFms6oU/9Os1prkurpZEY4yE98IVAN/PzVQ7FSU=; 5:+wxKIsItsct/J07mpuW4XjGPh1fl1I1/PqbQaizDtqkWJs1xmIX1LWyJmTrECBOHn4Yva5faM8vSqZWYQFXHAbS3u9LAOl5lGoDNmALE264oi7TSLT2mX+sDJ3XuCYWPe9NLJCnPLTff4tTV8hAAwA==; 24:181LxmysTHNRNkCgEFR9MxxfWth70sKE2Jo1nHuX+nlbsDeEXwoUHw63dTrCHkFG0/k3Yj7hGWOCcn5KF2SFEd6bbLCIh7J36Nqof7RS5Pc=; 7:nyFXBBZhPRXmHMGMQBPkOKjIMoID4+kKppI8PfV1tlfViJdaQwgRCBOcyoDY36touwVrNT8Vgaj7+/KsTZbtbczKVQwLinaGvdOOM09yFXbewxnWATsge1xOiOVfhjc8ux9hINaTKZZ2cPBl++6ZkOngqvl0Ejff/iwkfGhFKCxoRqsoNFRz5RlvoE5g2anXl0WpOxskbPBDz5p6+NKC9SziQ6N3+AbNEJUszorF3Qid/ZuHLMV4ivOhnFQBZ+9J x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(13464003)(199003)(189002)(74316002)(2950100001)(101416001)(76576001)(2900100001)(7736002)(2906002)(33656002)(7696003)(5003600100003)(5002640100001)(97736004)(305945005)(5001770100001)(93886004)(86362001)(122556002)(575784001)(81166006)(68736007)(8676002)(81156014)(87936001)(15975445007)(77096005)(66066001)(10400500002)(8936002)(106356001)(54356999)(106116001)(50986999)(92566002)(19580405001)(11100500001)(105586002)(9686002)(7846002)(99286002)(4326007)(19580395003)(3280700002)(189998001)(586003)(3660700001)(3846002)(6116002)(102836003)(76176999); 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 16:05:38.8923 (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: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 16:05:43 -0000 Hi Lada, Hi Andy The important questions we need answer to validate the current solution are= the following. - In a union, is it valid to define multiple enumerations which reuse the s= ame value(s) with a different semantic meaning? - In a union, is it valid to define multiple bits which reuse the same posi= tion(s) with a different semantic meaning? In the following examples, value or position 0 means both white and red whi= ch I believe it's invalid. If this is the case, the currently proposed solution to tag some specific d= atatype (bits, enumeration, identityref, instance-identifier) when used in= a union resolve any potential ambiguities. Can we move ahead with the current solution? ENUMERATION EXAMPLE typedef A { type union { type enumeration { enum white { value 0; } enum black { value 1; } } =20 type enumeration { enum red { value 0; } enum green { value 1; } enum blue { value 2; } } =20 } } BITS EXAMPLE typedef B { type union { type bits { bit white { position 0; } bit black { position 1; } } type bits { bit red { position 0; } bit green { position 1; } bit blue { position 2; } } } } Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Monday, July 25, 2016 10:41 AM To: Andy Bierman Cc: Core Subject: Re: [core] fixing YANG to CBOR > On 25 Jul 2016, at 16:21, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka wrote: > Andy Bierman writes: >=20 > > Hi, > > > > It seems to me that the only tagging actually needed would be to=20 > > identify the ordered list of member types within a union type. > > > > > > typedef A { > > type union { > > type int32 ; // 1 > > type string; // 2 > > type B; // 3, 4, 5 > > type identityref { base bar; } // 6 > > } > > } > > > > > > typedef B { > > type union { > > type uint8; > > type uint16; > > type uint32; > > } > > } > > > > leaf foo { type A; } > > > > YANG allows the member types to be reordered if it does not change=20 > > the value set accepted by the type. It is not clear >=20 > I don't think this is true. The only statement in 6020bis that is=20 > related to this issue is the bullet that you cite below, but IMO=20 > reordering member types in a union type definition may change the type=20 > semantics because the receiving side resolves the type according to=20 > the order of member types. >=20 >=20 >=20 > This depends on the format, but non-overlapping member types can=20 > change position without changing syntax or semantics. Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping me= mbers: "1.2.3.4" is valid as both "inet:ip-address" and "inet:domain-name". Lada > The exact member type that matches is not important. >=20 > typedef foo1 { > type union { > type int32 { range "1..10"; } > type int32 { range "11..20"; } > } > } >=20 > typedef foo2 { > type union { > type int32 { range "11..20"; } > type int32 { range "1..10"; } > } > } >=20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > if new member types can be added in new module revisions. > > > > If new member types are allowed in typedef B, then the relative=20 > > position of (6) can change, even if typedef A does not change. > > YANG does not explicitly state if this is allowed or not. > > > > bits and enumerations can be expanded in new revisions, which=20 > > changes the value set, but existing value and position numbers are=20 > > not allowed to change. > > > > The problematic text is in 6020bis, sec 11 > > > > o A "type" statement may be replaced with another "type" statement > > that does not change the syntax or semantics of the type. For > > example, an inline type definition may be replaced with a typedef= , > > but an int8 type cannot be replaced by an int16, since the syntax > > would change. > > > > > > > > In practice reordering member types would be very rare, but the SID=20 > > numbering would need to remember the member type order for each leaf=20 > > or leaf-list that resolves to a union type. > > > > It doesn't help to tag any other type besides union. > > > > > > Andy > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 25 09:17:31 2016 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 746C012D1ED for ; Mon, 25 Jul 2016 09:17:30 -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 vEaiciCyTXee for ; Mon, 25 Jul 2016 09:17:28 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B306312D131 for ; Mon, 25 Jul 2016 09:17:27 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id s189so250273121vkh.1 for ; Mon, 25 Jul 2016 09:17:27 -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=aQrEKgsia9kVVVphewAVDo5wiD7rKeMJjO+ggNtJvK8=; b=XqXaHppvuSMVywyp5Unmyw6CPnhDhRDMYr+DXbympiJcO/qBbFU6sNuWaxY+oYM9i9 BwBmq5cRyLF3VTK+b/IYhodw+9J5T2SBRFdrUez8/9WnHmkJ1EmNY8RW+apYesWCq15i UPUGGs/WdJ1fMOJCXI5ARv1NEYpyfn8rT5Gq3EKxFErMgdf0bsgmyhEob/NwgDqCNJuz 9631lDsN8cDm6CMIsWDcxNh46ummcqboExb5LOkQ6ezF8C3e2c61te9wTC8NcMx1xd0f QQ7WSCNjhKjpONOnWOSZGpeMef69jx+tiNXndTwKx+6JZfRYZzwoiqNrbYSLy0k+xyBK 9lMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aQrEKgsia9kVVVphewAVDo5wiD7rKeMJjO+ggNtJvK8=; b=K8o6VHRKvvfiH7QI4bi0IdIMZuTouC2shL3eA2C4i6akgImk6Siax5r0ZrXbiLwTQk sF6pb8ki5kkSmqxq3izNirTak53mvTdMLLU5PEh07TgRUKdUEzeadokrnBfRxP+5Qquh o+F50baNmn28rhhcRZdr6SuGBsTJiSYeaT7+6DQHtdx1LgE+aVmjejg6PmUmNkjpZEmk hhP7AOiNe85s3gBwXqtG0O/jRe1Vu7S7nGZUpl1rN5F5XNXvdSDej2jgXUvn3PiqzC3W a2GaflZk6gefDU2CMlE+PZBXjTNqnkhcu/mKC6XfftNHN5JDajMnn+fSJX5XdhdegWqj U1/g== X-Gm-Message-State: AEkoouud2me/6DIsOY7080S+aHQsH7LmKx/d+NgUOnP7qH3gtq9kXBDUsS8o84VqWvAi8pRNBG0N9YxBe4sGtQ== X-Received: by 10.31.9.67 with SMTP id 64mr8728467vkj.89.1469463446790; Mon, 25 Jul 2016 09:17:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 25 Jul 2016 09:17:26 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Mon, 25 Jul 2016 09:17:26 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=001a11440ef4c1be0b0538781eb0 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 16:17:30 -0000 --001a11440ef4c1be0b0538781eb0 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 25, 2016 at 9:05 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Lada, Hi Andy > > The important questions we need answer to validate the current solution > are the following. > > - In a union, is it valid to define multiple enumerations which reuse the > same value(s) with a different semantic meaning? > Remember that the enum "value" and bit "position" are irrelevant. They are not defined in YANG to be used on the wire. So Carsten's examples (2 different enumeration types) is valid and not a problem for XML and JSON. They are only a problem because CBOR is attempting to use something defined NOT to be sent on the wire. Lada, There are examples that can be constructed that break, and others that don't break. So what? Doesn't help solve anything. Andy - In a union, is it valid to define multiple bits which reuse the same > position(s) with a different semantic meaning? > > In the following examples, value or position 0 means both white and red > which I believe it's invalid. > If this is the case, the currently proposed solution to tag some specific > datatype (bits, enumeration, identityref, instance-identifier) when used > in a union resolve any potential ambiguities. > Can we move ahead with the current solution? > > ENUMERATION EXAMPLE > > typedef A { > type union { > type enumeration { > enum white { > value 0; > } > enum black { > value 1; > } > } > type enumeration { > enum red { > value 0; > } > enum green { > value 1; > } > enum blue { > value 2; > } > } > } > } > > BITS EXAMPLE > > typedef B { > type union { > type bits { > bit white { > position 0; > } > bit black { > position 1; > } > } > type bits { > bit red { > position 0; > } > bit green { > position 1; > } > bit blue { > position 2; > } > } > } > } > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Monday, July 25, 2016 10:41 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] fixing YANG to CBOR > > > > On 25 Jul 2016, at 16:21, Andy Bierman wrote: > > > > > > > > On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > Hi, > > > > > > It seems to me that the only tagging actually needed would be to > > > identify the ordered list of member types within a union type. > > > > > > > > > typedef A { > > > type union { > > > type int32 ; // 1 > > > type string; // 2 > > > type B; // 3, 4, 5 > > > type identityref { base bar; } // 6 > > > } > > > } > > > > > > > > > typedef B { > > > type union { > > > type uint8; > > > type uint16; > > > type uint32; > > > } > > > } > > > > > > leaf foo { type A; } > > > > > > YANG allows the member types to be reordered if it does not change > > > the value set accepted by the type. It is not clear > > > > I don't think this is true. The only statement in 6020bis that is > > related to this issue is the bullet that you cite below, but IMO > > reordering member types in a union type definition may change the type > > semantics because the receiving side resolves the type according to > > the order of member types. > > > > > > > > This depends on the format, but non-overlapping member types can > > change position without changing syntax or semantics. > > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping > members: "1.2.3.4" is valid as both "inet:ip-address" and > "inet:domain-name". > > Lada > > > The exact member type that matches is not important. > > > > typedef foo1 { > > type union { > > type int32 { range "1..10"; } > > type int32 { range "11..20"; } > > } > > } > > > > typedef foo2 { > > type union { > > type int32 { range "11..20"; } > > type int32 { range "1..10"; } > > } > > } > > > > > > > > Lada > > > > Andy > > > > > > > if new member types can be added in new module revisions. > > > > > > If new member types are allowed in typedef B, then the relative > > > position of (6) can change, even if typedef A does not change. > > > YANG does not explicitly state if this is allowed or not. > > > > > > bits and enumerations can be expanded in new revisions, which > > > changes the value set, but existing value and position numbers are > > > not allowed to change. > > > > > > The problematic text is in 6020bis, sec 11 > > > > > > o A "type" statement may be replaced with another "type" statement > > > that does not change the syntax or semantics of the type. For > > > example, an inline type definition may be replaced with a > typedef, > > > but an int8 type cannot be replaced by an int16, since the syntax > > > would change. > > > > > > > > > > > > In practice reordering member types would be very rare, but the SID > > > numbering would need to remember the member type order for each leaf > > > or leaf-list that resolves to a union type. > > > > > > It doesn't help to tag any other type besides union. > > > > > > > > > Andy > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11440ef4c1be0b0538781eb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25, 2016 at 9:05 AM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:
Hi Lada, Hi Andy

The important questions we need answer to validate the current solution are= the following.

- In a union, is it valid to define multiple enumerations which reuse the s= ame value(s) with a different semantic meaning?


Remember that the enum "value" and bit &q= uot;position" are irrelevant.
They are not defined in YANG t= o be used on the wire.
So Carsten's examples (2 different enu= meration types) is valid
and not a problem for XML and JSON.=C2= =A0 They are only a problem
because CBOR is attempting to use som= ething defined NOT to be sent on the wire.

Lada, T= here are examples that can be constructed that break,
and others = that don't break. So what? Doesn't help solve anything.


Andy


- In a union, is it valid to define multiple bits which reuse the same posi= tion(s) with a different semantic meaning?

In the following examples, value or position 0 means both white and red whi= ch I believe it's invalid.
If this is the case, the currently proposed solution to tag some specific d= atatype (bits,=C2=A0 enumeration, identityref, instance-identifier) when us= ed in a union resolve any potential ambiguities.
Can we move ahead with the current solution?

ENUMERATION EXAMPLE

typedef A {
=C2=A0 type union {
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 enum white {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum black {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 enum red {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum green {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum blue {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
}

BITS EXAMPLE

typedef B {
=C2=A0 type union {
=C2=A0 =C2=A0 type bits {
=C2=A0 =C2=A0 =C2=A0 bit white {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 bit black {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 type bits {
=C2=A0 =C2=A0 =C2=A0 bit red {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 bit green {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 bit blue {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 2;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
}

Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of Ladislav Lhotka
Sent: Monday, July 25, 2016 10:41 AM
To: Andy Bierman <andy@yumaworks.c= om>
Cc: Core <core@ietf.org>
Subject: Re: [core] fixing YANG to CBOR


> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > Hi,
> >
> > It seems to me that the only tagging actually needed would be to<= br> > > identify the ordered list of member types within a union type. > >
> >
> > typedef A {
> >=C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0type int32 ;=C2=A0 =C2=A0// 1
> >=C2=A0 =C2=A0 =C2=A0type string; // 2
> >=C2=A0 =C2=A0 =C2=A0type B;=C2=A0 =C2=A0// 3, 4, 5
> >=C2=A0 =C2=A0 =C2=A0type identityref { base bar; }=C2=A0 =C2=A0// = 6
> >=C2=A0 =C2=A0}
> > }
> >
> >
> > typedef B {
> >=C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0type uint16;
> >=C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0}
> > }
> >
> > leaf foo { type A; }
> >
> > YANG allows the member types to be reordered if it does not chang= e
> > the value set accepted by the type.=C2=A0 It is not clear
>
> I don't think this is true. The only statement in 6020bis that is<= br> > related to this issue is the bullet that you cite below, but IMO
> reordering member types in a union type definition may change the type=
> semantics because the receiving side resolves the type according to > the order of member types.
>
>
>
> This depends on the format, but non-overlapping member types can
> change position without changing syntax or semantics.

Yes, but, for instance, the "inet:host" type in RFC 6991 has over= lapping members: "1.2.3.4" is valid as both "inet:ip-address= " and "inet:domain-name".

Lada

> The exact member type that matches is not important.
>
>=C2=A0 =C2=A0 typedef foo1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type union {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "1..10"= ; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "11..20"= ;; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0typedef foo2 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type union {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "11..20"= ;; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "1..10"= ; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>
>
>
> Lada
>
> Andy
>
>
> > if new member types can be added in new module revisions.
> >
> > If new member types are allowed in typedef B, then the relative > > position of (6) can change, even if typedef A does not change. > > YANG does not explicitly state if this is allowed or not.
> >
> > bits and enumerations can be expanded in new revisions, which
> > changes the value set, but existing value and position numbers ar= e
> > not allowed to change.
> >
> > The problematic text is in 6020bis, sec 11
> >
> >=C2=A0 =C2=A0o=C2=A0 A "type" statement may be replaced = with another "type" statement
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0that does not change the syntax or sema= ntics of the type.=C2=A0 For
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0example, an inline type definition may = be replaced with a typedef,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0but an int8 type cannot be replaced by = an int16, since the syntax
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0would change.
> >
> >
> >
> > In practice reordering member types would be very rare, but the S= ID
> > numbering would need to remember the member type order for each l= eaf
> > or leaf-list that resolves to a union type.
> >
> > It doesn't help to tag any other type besides union.
> >
> >
> > Andy
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core >
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

--001a11440ef4c1be0b0538781eb0-- From nobody Mon Jul 25 09:33:57 2016 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 69D5C12D7E7 for ; Mon, 25 Jul 2016 09:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_H2=-0.001, 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 6OKrYreSesEA for ; Mon, 25 Jul 2016 09:33:53 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0133.outbound.protection.outlook.com [104.47.41.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907A412D1E6 for ; Mon, 25 Jul 2016 09:33:53 -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=dvpRTZZowXynlD+LLNUg4h5rzwBLw+hVHWYKk3X890M=; b=J6v7WgDBYYtzOJBm8zqOlF3GIHOVO1SwDSwHORtjg7b1em70A6aZ9mpCRtaU4F7GvSad1sQH+P9Ksz5v5C+DU0lkuehMvZG+DhXvJYEd2QAIYib5DGxxGkNbZ9Bf+OYEVhtRq04qXrycL0Lb1uuJxW+KK+Orgs9EkvPR12o4sik= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 16:33:50 +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.0544.014; Mon, 25 Jul 2016 16:33:50 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] fixing YANG to CBOR Thread-Index: AQHR4+cJQt79bN4pMU+XasZI/tqalKApIRsAgAAW5YCAAAVwAIAAEGZQgAAKbACAAAJAoA== Date: Mon, 25 Jul 2016 16:33:50 +0000 Message-ID: References: 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 153c3e0a-e90b-403b-cc21-08d3b4a975bd x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:qPsRpopki4/bANW+0IOcRNiqeRdZY3AVWn2/clfmw8vNDQNM12eOuLUR9NWMFhvLWONw2MVrlTzhS3XHHgPljhwhane3C/hYydMps/VkCowzJANjN5jN8BueV6qt9KKfTtlI/c8LvS9bbGn03iJ0IKqMftaGXlELP6gLJ6xYgao3Mk6jVGDwVGiRZX4IRjPmF6KIhUbubo0qCysDC5kArcrl5tSMY0nVtlMFUUI0URZQLrbyR/HX/G2Je0rd/7bqujsv2xbef5qv5W/73zmbkwbfrIRA2xmcgH5jfQawbI0=; 5:LTsatmOSGcujRRwmXrrHmn17J/U2Crc7j8Sygj8BkM+KAqopwBcJ4S4FZWgg+mvA+UmpjujXhp/LrVLD6D+e1YiLq3Ew6kXlaBPmQE+pYDIjsaYtPEoKnwy8a1HgB7Xpxkj0Mi1ntZwpxnEgxG4iTA==; 24:xOhpft2FwlyZd+IJ45g4HPyXG0EjFJDNsjeFJFwwykbaTk1JUiMU3/ZV2YzePRy9OeRLqyUBhOtmNiXg/t+wUESPChRqTqXKugAqeQJo6N4=; 7:xUS1tdEAbrRSdwYJkdcyfJEP6q/H+2/VviFJrNh+jUXsII0LaK1a+zacwHo9EyHHMqE4AxVORBwQyZtOqy0j1JB8NB9FU7r9ZpsEX592EQeTo3+bOEX4iPyIelsddkBb3eC3tS8INk5jlskqBA+cjSOUy9XF+de/rmaysZ33QD1bQSGW2M6E3RHWkxnUEWWV+FhKtr4Q4U+RvMj1cnWAM1MsMTbnPvgQPurMQF5tidkq/jPY3vwjm3yXmLXRK7qk x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(13464003)(24454002)(199003)(6116002)(102836003)(3846002)(9686002)(790700001)(68736007)(8676002)(106356001)(50986999)(76576001)(19609705001)(11100500001)(76176999)(54356999)(92566002)(8936002)(2900100001)(33656002)(99286002)(77096005)(19300405004)(93886004)(2950100001)(15975445007)(2906002)(189998001)(586003)(16236675004)(110136002)(4326007)(106116001)(97736004)(101416001)(3660700001)(10400500002)(7846002)(7696003)(5003600100003)(7736002)(7906003)(105586002)(3280700002)(87936001)(19625215002)(19580405001)(66066001)(19580395003)(575784001)(86362001)(19617315012)(81156014)(81166006)(122556002)(5002640100001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.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: multipart/alternative; boundary="_000_BN6PR06MB23084F78C289308C22F2930BFE0D0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 16:33:50.5315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 16:33:56 -0000 --_000_BN6PR06MB23084F78C289308C22F2930BFE0D0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgZW51bWVyYXRpb24gdmFsdWVzIGFuZCBi aXQgcG9zaXRpb25zIGhhdmUgbm90IGJlZW4gdXNlZCBvdmVyIHRoZSB3aXJlIGZvciBORVRjb25m IGFuZCBSRVNUY29uZi4gSG93ZXZlciwgdGhpcyBkb2Vzbid0IG1lYW5zIHRoZXkgYXJlIGlycmVs ZXZhbnQgYW5kIGNhbid0IGJlIHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgYSBuZXcgcHJvdG9jb2wu IFVubGVzcyB5b3UgcG9pbnQgbWUgb24gYSBwYXJhZ3JhcGggaW4gZHJhZnQtaWV0Zi1uZXRtb2Qt cmZjNjAyMGJpcyB3aGljaCBzYXkgdGhhdCB0aGVzZSBudW1iZXJzIGhhdmUgYmVlbiBkZWZpbmVk IGZvciBubyByZWFzb25zIGFuZCBjYW4ndCBiZSB1c2VkLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoN Cg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDog TW9uZGF5LCBKdWx5IDI1LCAyMDE2IDEyOjE3IFBNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhv dGthQG5pYy5jej47IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIGZp eGluZyBZQU5HIHRvIENCT1INCg0KDQoNCk9uIE1vbiwgSnVsIDI1LCAyMDE2IGF0IDk6MDUgQU0s IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTxtYWls dG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPj4gd3JvdGU6DQpIaSBMYWRhLCBI aSBBbmR5DQoNClRoZSBpbXBvcnRhbnQgcXVlc3Rpb25zIHdlIG5lZWQgYW5zd2VyIHRvIHZhbGlk YXRlIHRoZSBjdXJyZW50IHNvbHV0aW9uIGFyZSB0aGUgZm9sbG93aW5nLg0KDQotIEluIGEgdW5p b24sIGlzIGl0IHZhbGlkIHRvIGRlZmluZSBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgd2hpY2ggcmV1 c2UgdGhlIHNhbWUgdmFsdWUocykgd2l0aCBhIGRpZmZlcmVudCBzZW1hbnRpYyBtZWFuaW5nPw0K DQoNClJlbWVtYmVyIHRoYXQgdGhlIGVudW0gInZhbHVlIiBhbmQgYml0ICJwb3NpdGlvbiIgYXJl IGlycmVsZXZhbnQuDQpUaGV5IGFyZSBub3QgZGVmaW5lZCBpbiBZQU5HIHRvIGJlIHVzZWQgb24g dGhlIHdpcmUuDQpTbyBDYXJzdGVuJ3MgZXhhbXBsZXMgKDIgZGlmZmVyZW50IGVudW1lcmF0aW9u IHR5cGVzKSBpcyB2YWxpZA0KYW5kIG5vdCBhIHByb2JsZW0gZm9yIFhNTCBhbmQgSlNPTi4gIFRo ZXkgYXJlIG9ubHkgYSBwcm9ibGVtDQpiZWNhdXNlIENCT1IgaXMgYXR0ZW1wdGluZyB0byB1c2Ug c29tZXRoaW5nIGRlZmluZWQgTk9UIHRvIGJlIHNlbnQgb24gdGhlIHdpcmUuDQoNCkxhZGEsIFRo ZXJlIGFyZSBleGFtcGxlcyB0aGF0IGNhbiBiZSBjb25zdHJ1Y3RlZCB0aGF0IGJyZWFrLA0KYW5k IG90aGVycyB0aGF0IGRvbid0IGJyZWFrLiBTbyB3aGF0PyBEb2Vzbid0IGhlbHAgc29sdmUgYW55 dGhpbmcuDQoNCg0KQW5keQ0KDQoNCi0gSW4gYSB1bmlvbiwgaXMgaXQgdmFsaWQgdG8gZGVmaW5l IG11bHRpcGxlIGJpdHMgd2hpY2ggcmV1c2UgdGhlIHNhbWUgcG9zaXRpb24ocykgd2l0aCBhIGRp ZmZlcmVudCBzZW1hbnRpYyBtZWFuaW5nPw0KDQpJbiB0aGUgZm9sbG93aW5nIGV4YW1wbGVzLCB2 YWx1ZSBvciBwb3NpdGlvbiAwIG1lYW5zIGJvdGggd2hpdGUgYW5kIHJlZCB3aGljaCBJIGJlbGll dmUgaXQncyBpbnZhbGlkLg0KSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhlIGN1cnJlbnRseSBwcm9w b3NlZCBzb2x1dGlvbiB0byB0YWcgc29tZSBzcGVjaWZpYyBkYXRhdHlwZSAoYml0cywgIGVudW1l cmF0aW9uLCBpZGVudGl0eXJlZiwgaW5zdGFuY2UtaWRlbnRpZmllcikgd2hlbiB1c2VkIGluIGEg dW5pb24gcmVzb2x2ZSBhbnkgcG90ZW50aWFsIGFtYmlndWl0aWVzLg0KQ2FuIHdlIG1vdmUgYWhl YWQgd2l0aCB0aGUgY3VycmVudCBzb2x1dGlvbj8NCg0KRU5VTUVSQVRJT04gRVhBTVBMRQ0KDQp0 eXBlZGVmIEEgew0KICB0eXBlIHVuaW9uIHsNCiAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAg IGVudW0gd2hpdGUgew0KICAgICAgICB2YWx1ZSAwOw0KICAgICAgfQ0KICAgICAgZW51bSBibGFj ayB7DQogICAgICAgIHZhbHVlIDE7DQogICAgICB9DQogICAgfQ0KICAgIHR5cGUgZW51bWVyYXRp b24gew0KICAgICAgZW51bSByZWQgew0KICAgICAgICB2YWx1ZSAwOw0KICAgICAgfQ0KICAgICAg ZW51bSBncmVlbiB7DQogICAgICAgIHZhbHVlIDE7DQogICAgICB9DQogICAgICBlbnVtIGJsdWUg ew0KICAgICAgICB2YWx1ZSAyOw0KICAgICAgfQ0KICAgIH0NCiAgfQ0KfQ0KDQpCSVRTIEVYQU1Q TEUNCg0KdHlwZWRlZiBCIHsNCiAgdHlwZSB1bmlvbiB7DQogICAgdHlwZSBiaXRzIHsNCiAgICAg IGJpdCB3aGl0ZSB7DQogICAgICAgIHBvc2l0aW9uIDA7DQogICAgICB9DQogICAgICBiaXQgYmxh Y2sgew0KICAgICAgICBwb3NpdGlvbiAxOw0KICAgICAgfQ0KICAgIH0NCiAgICB0eXBlIGJpdHMg ew0KICAgICAgYml0IHJlZCB7DQogICAgICAgIHBvc2l0aW9uIDA7DQogICAgICB9DQogICAgICBi aXQgZ3JlZW4gew0KICAgICAgICBwb3NpdGlvbiAxOw0KICAgICAgfQ0KICAgICAgYml0IGJsdWUg ew0KICAgICAgICBwb3NpdGlvbiAyOw0KICAgICAgfQ0KICAgIH0NCiAgfQ0KfQ0KDQpSZWdhcmRz LA0KTWljaGVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgTGFkaXNsYXYgTGhvdGthDQpTZW50OiBNb25kYXksIEp1bHkgMjUsIDIwMTYg MTA6NDEgQU0NClRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tPj4NCkNjOiBDb3JlIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbY29yZV0gZml4aW5nIFlBTkcgdG8gQ0JPUg0KDQoNCj4g T24gMjUgSnVsIDIwMTYsIGF0IDE2OjIxLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNv bTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQo+DQo+DQo+DQo+IE9uIE1vbiwg SnVsIDI1LCAyMDE2IGF0IDY6MDAgQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxt YWlsdG86bGhvdGthQG5pYy5jej4+IHdyb3RlOg0KPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JpdGVzOg0KPg0KPiA+IEhpLA0K PiA+DQo+ID4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgb25seSB0YWdnaW5nIGFjdHVhbGx5IG5l ZWRlZCB3b3VsZCBiZSB0bw0KPiA+IGlkZW50aWZ5IHRoZSBvcmRlcmVkIGxpc3Qgb2YgbWVtYmVy IHR5cGVzIHdpdGhpbiBhIHVuaW9uIHR5cGUuDQo+ID4NCj4gPg0KPiA+IHR5cGVkZWYgQSB7DQo+ ID4gICB0eXBlIHVuaW9uIHsNCj4gPiAgICAgdHlwZSBpbnQzMiA7ICAgLy8gMQ0KPiA+ICAgICB0 eXBlIHN0cmluZzsgLy8gMg0KPiA+ICAgICB0eXBlIEI7ICAgLy8gMywgNCwgNQ0KPiA+ICAgICB0 eXBlIGlkZW50aXR5cmVmIHsgYmFzZSBiYXI7IH0gICAvLyA2DQo+ID4gICB9DQo+ID4gfQ0KPiA+ DQo+ID4NCj4gPiB0eXBlZGVmIEIgew0KPiA+ICAgdHlwZSB1bmlvbiB7DQo+ID4gICAgIHR5cGUg dWludDg7DQo+ID4gICAgIHR5cGUgdWludDE2Ow0KPiA+ICAgICB0eXBlIHVpbnQzMjsNCj4gPiAg IH0NCj4gPiB9DQo+ID4NCj4gPiBsZWFmIGZvbyB7IHR5cGUgQTsgfQ0KPiA+DQo+ID4gWUFORyBh bGxvd3MgdGhlIG1lbWJlciB0eXBlcyB0byBiZSByZW9yZGVyZWQgaWYgaXQgZG9lcyBub3QgY2hh bmdlDQo+ID4gdGhlIHZhbHVlIHNldCBhY2NlcHRlZCBieSB0aGUgdHlwZS4gIEl0IGlzIG5vdCBj bGVhcg0KPg0KPiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdHJ1ZS4gVGhlIG9ubHkgc3RhdGVtZW50 IGluIDYwMjBiaXMgdGhhdCBpcw0KPiByZWxhdGVkIHRvIHRoaXMgaXNzdWUgaXMgdGhlIGJ1bGxl dCB0aGF0IHlvdSBjaXRlIGJlbG93LCBidXQgSU1PDQo+IHJlb3JkZXJpbmcgbWVtYmVyIHR5cGVz IGluIGEgdW5pb24gdHlwZSBkZWZpbml0aW9uIG1heSBjaGFuZ2UgdGhlIHR5cGUNCj4gc2VtYW50 aWNzIGJlY2F1c2UgdGhlIHJlY2VpdmluZyBzaWRlIHJlc29sdmVzIHRoZSB0eXBlIGFjY29yZGlu ZyB0bw0KPiB0aGUgb3JkZXIgb2YgbWVtYmVyIHR5cGVzLg0KPg0KPg0KPg0KPiBUaGlzIGRlcGVu ZHMgb24gdGhlIGZvcm1hdCwgYnV0IG5vbi1vdmVybGFwcGluZyBtZW1iZXIgdHlwZXMgY2FuDQo+ IGNoYW5nZSBwb3NpdGlvbiB3aXRob3V0IGNoYW5naW5nIHN5bnRheCBvciBzZW1hbnRpY3MuDQoN ClllcywgYnV0LCBmb3IgaW5zdGFuY2UsIHRoZSAiaW5ldDpob3N0IiB0eXBlIGluIFJGQyA2OTkx IGhhcyBvdmVybGFwcGluZyBtZW1iZXJzOiAiMS4yLjMuNCIgaXMgdmFsaWQgYXMgYm90aCAiaW5l dDppcC1hZGRyZXNzIiBhbmQgImluZXQ6ZG9tYWluLW5hbWUiLg0KDQpMYWRhDQoNCj4gVGhlIGV4 YWN0IG1lbWJlciB0eXBlIHRoYXQgbWF0Y2hlcyBpcyBub3QgaW1wb3J0YW50Lg0KPg0KPiAgICB0 eXBlZGVmIGZvbzEgew0KPiAgICAgICB0eXBlIHVuaW9uIHsNCj4gICAgICAgICAgdHlwZSBpbnQz MiB7IHJhbmdlICIxLi4xMCI7IH0NCj4gICAgICAgICAgdHlwZSBpbnQzMiB7IHJhbmdlICIxMS4u MjAiOyB9DQo+ICAgICAgIH0NCj4gICAgIH0NCj4NCj4gICB0eXBlZGVmIGZvbzIgew0KPiAgICAg ICB0eXBlIHVuaW9uIHsNCj4gICAgICAgICAgdHlwZSBpbnQzMiB7IHJhbmdlICIxMS4uMjAiOyB9 DQo+ICAgICAgICAgIHR5cGUgaW50MzIgeyByYW5nZSAiMS4uMTAiOyB9DQo+ICAgICAgIH0NCj4g ICAgIH0NCj4NCj4NCj4NCj4gTGFkYQ0KPg0KPiBBbmR5DQo+DQo+DQo+ID4gaWYgbmV3IG1lbWJl ciB0eXBlcyBjYW4gYmUgYWRkZWQgaW4gbmV3IG1vZHVsZSByZXZpc2lvbnMuDQo+ID4NCj4gPiBJ ZiBuZXcgbWVtYmVyIHR5cGVzIGFyZSBhbGxvd2VkIGluIHR5cGVkZWYgQiwgdGhlbiB0aGUgcmVs YXRpdmUNCj4gPiBwb3NpdGlvbiBvZiAoNikgY2FuIGNoYW5nZSwgZXZlbiBpZiB0eXBlZGVmIEEg ZG9lcyBub3QgY2hhbmdlLg0KPiA+IFlBTkcgZG9lcyBub3QgZXhwbGljaXRseSBzdGF0ZSBpZiB0 aGlzIGlzIGFsbG93ZWQgb3Igbm90Lg0KPiA+DQo+ID4gYml0cyBhbmQgZW51bWVyYXRpb25zIGNh biBiZSBleHBhbmRlZCBpbiBuZXcgcmV2aXNpb25zLCB3aGljaA0KPiA+IGNoYW5nZXMgdGhlIHZh bHVlIHNldCwgYnV0IGV4aXN0aW5nIHZhbHVlIGFuZCBwb3NpdGlvbiBudW1iZXJzIGFyZQ0KPiA+ IG5vdCBhbGxvd2VkIHRvIGNoYW5nZS4NCj4gPg0KPiA+IFRoZSBwcm9ibGVtYXRpYyB0ZXh0IGlz IGluIDYwMjBiaXMsIHNlYyAxMQ0KPiA+DQo+ID4gICBvICBBICJ0eXBlIiBzdGF0ZW1lbnQgbWF5 IGJlIHJlcGxhY2VkIHdpdGggYW5vdGhlciAidHlwZSIgc3RhdGVtZW50DQo+ID4gICAgICAgdGhh dCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHN5bnRheCBvciBzZW1hbnRpY3Mgb2YgdGhlIHR5cGUuICBG b3INCj4gPiAgICAgICBleGFtcGxlLCBhbiBpbmxpbmUgdHlwZSBkZWZpbml0aW9uIG1heSBiZSBy ZXBsYWNlZCB3aXRoIGEgdHlwZWRlZiwNCj4gPiAgICAgICBidXQgYW4gaW50OCB0eXBlIGNhbm5v dCBiZSByZXBsYWNlZCBieSBhbiBpbnQxNiwgc2luY2UgdGhlIHN5bnRheA0KPiA+ICAgICAgIHdv dWxkIGNoYW5nZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJbiBwcmFjdGljZSByZW9yZGVyaW5nIG1l bWJlciB0eXBlcyB3b3VsZCBiZSB2ZXJ5IHJhcmUsIGJ1dCB0aGUgU0lEDQo+ID4gbnVtYmVyaW5n IHdvdWxkIG5lZWQgdG8gcmVtZW1iZXIgdGhlIG1lbWJlciB0eXBlIG9yZGVyIGZvciBlYWNoIGxl YWYNCj4gPiBvciBsZWFmLWxpc3QgdGhhdCByZXNvbHZlcyB0byBhIHVuaW9uIHR5cGUuDQo+ID4N Cj4gPiBJdCBkb2Vzbid0IGhlbHAgdG8gdGFnIGFueSBvdGhlciB0eXBlIGJlc2lkZXMgdW5pb24u DQo+ID4NCj4gPg0KPiA+IEFuZHkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gY29yZUBpZXRmLm9y ZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvcmUNCj4NCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0K PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KDQotLQ0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFi cw0KUEdQIEtleSBJRDogRTc0RThDMEMNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3Jn PG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQoNCg== --_000_BN6PR06MB23084F78C289308C22F2930BFE0D0BN6PR06MB2308namp_ 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+SSB1bmRlcnN0YW5kIHRoYXQgdGhlIGVudW1lcmF0 aW9uIHZhbHVlcyBhbmQgYml0IHBvc2l0aW9ucyBoYXZlIG5vdCBiZWVuIHVzZWQgb3ZlciB0aGUg d2lyZSBmb3IgTkVUY29uZiBhbmQgUkVTVGNvbmYuIEhvd2V2ZXIsIHRoaXMgZG9lc24ndCBtZWFu cyB0aGV5IGFyZQ0KPC9zcGFuPmlycmVsZXZhbnQgYW5kIGNhbid0IGJlIHVzZWQgaW4gdGhlIGNv bnRleHQgb2YgYSBuZXcgcHJvdG9jb2wuIFVubGVzcyB5b3UgcG9pbnQgbWUgb24gYSBwYXJhZ3Jh cGggaW4gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJpcyB3aGljaCBzYXkgdGhhdCB0aGVzZSBu dW1iZXJzIGhhdmUgYmVlbiBkZWZpbmVkIGZvciBubyByZWFzb25zIGFuZCBjYW4ndCBiZSB1c2Vk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWljaGVsIDxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5 dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAyNSwgMjAxNiAx MjoxNyBQTTxicj4NCjxiPlRvOjwvYj4gTWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxs ZXR0ZUB0cmlsbGlhbnRpbmMuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTGFkaXNsYXYgTGhvdGth ICZsdDtsaG90a2FAbmljLmN6Jmd0OzsgQ29yZSAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSBmaXhpbmcgWUFORyB0byBDQk9SPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdWwgMjUsIDIwMTYgYXQgOTowNSBBTSwgTWljaGVsIFZl aWxsZXR0ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5j LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIExhZGEsIEhpIEFuZHk8YnI+DQo8YnI+DQpUaGUgaW1wb3J0YW50IHF1ZXN0aW9u cyB3ZSBuZWVkIGFuc3dlciB0byB2YWxpZGF0ZSB0aGUgY3VycmVudCBzb2x1dGlvbiBhcmUgdGhl IGZvbGxvd2luZy48YnI+DQo8YnI+DQotIEluIGEgdW5pb24sIGlzIGl0IHZhbGlkIHRvIGRlZmlu ZSBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgd2hpY2ggcmV1c2UgdGhlIHNhbWUgdmFsdWUocykgd2l0 aCBhIGRpZmZlcmVudCBzZW1hbnRpYyBtZWFuaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZW1lbWJlciB0aGF0IHRoZSBl bnVtICZxdW90O3ZhbHVlJnF1b3Q7IGFuZCBiaXQgJnF1b3Q7cG9zaXRpb24mcXVvdDsgYXJlIGly cmVsZXZhbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGV5IGFyZSBub3QgZGVmaW5lZCBpbiBZQU5HIHRvIGJlIHVzZWQgb24gdGhlIHdpcmUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBD YXJzdGVuJ3MgZXhhbXBsZXMgKDIgZGlmZmVyZW50IGVudW1lcmF0aW9uIHR5cGVzKSBpcyB2YWxp ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5k IG5vdCBhIHByb2JsZW0gZm9yIFhNTCBhbmQgSlNPTi4mbmJzcDsgVGhleSBhcmUgb25seSBhIHBy b2JsZW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmJlY2F1c2UgQ0JPUiBpcyBhdHRlbXB0aW5nIHRvIHVzZSBzb21ldGhpbmcgZGVmaW5lZCBOT1Qg dG8gYmUgc2VudCBvbiB0aGUgd2lyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFkYSwgVGhlcmUgYXJlIGV4YW1wbGVzIHRoYXQgY2FuIGJl IGNvbnN0cnVjdGVkIHRoYXQgYnJlYWssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgb3RoZXJzIHRoYXQgZG9uJ3QgYnJlYWsuIFNvIHdoYXQ/ IERvZXNuJ3QgaGVscCBzb2x2ZSBhbnl0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJbiBhIHVuaW9uLCBpcyBp dCB2YWxpZCB0byBkZWZpbmUgbXVsdGlwbGUgYml0cyB3aGljaCByZXVzZSB0aGUgc2FtZSBwb3Np dGlvbihzKSB3aXRoIGEgZGlmZmVyZW50IHNlbWFudGljIG1lYW5pbmc/PGJyPg0KPGJyPg0KSW4g dGhlIGZvbGxvd2luZyBleGFtcGxlcywgdmFsdWUgb3IgcG9zaXRpb24gMCBtZWFucyBib3RoIHdo aXRlIGFuZCByZWQgd2hpY2ggSSBiZWxpZXZlIGl0J3MgaW52YWxpZC48YnI+DQpJZiB0aGlzIGlz IHRoZSBjYXNlLCB0aGUgY3VycmVudGx5IHByb3Bvc2VkIHNvbHV0aW9uIHRvIHRhZyBzb21lIHNw ZWNpZmljIGRhdGF0eXBlIChiaXRzLCZuYnNwOyBlbnVtZXJhdGlvbiwgaWRlbnRpdHlyZWYsIGlu c3RhbmNlLWlkZW50aWZpZXIpIHdoZW4gdXNlZCBpbiBhIHVuaW9uIHJlc29sdmUgYW55IHBvdGVu dGlhbCBhbWJpZ3VpdGllcy48YnI+DQpDYW4gd2UgbW92ZSBhaGVhZCB3aXRoIHRoZSBjdXJyZW50 IHNvbHV0aW9uPzxicj4NCjxicj4NCkVOVU1FUkFUSU9OIEVYQU1QTEU8YnI+DQo8YnI+DQp0eXBl ZGVmIEEgezxicj4NCiZuYnNwOyB0eXBlIHVuaW9uIHs8YnI+DQombmJzcDsgJm5ic3A7IHR5cGUg ZW51bWVyYXRpb24gezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0gd2hpdGUgezxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2YWx1ZSAwOzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtIGJsYWNrIHs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdmFsdWUgMTs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyB9PGJyPg0KJm5ic3A7ICZuYnNwOyB9PGJyPg0KJm5ic3A7ICZuYnNwOyB0eXBlIGVudW1lcmF0 aW9uIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtIHJlZCB7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHZhbHVlIDA7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0gZ3JlZW4gezxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB2YWx1ZSAxOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtIGJsdWUgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB2YWx1ZSAyOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQombmJzcDsg Jm5ic3A7IH08YnI+DQombmJzcDsgfTxicj4NCn08YnI+DQo8YnI+DQpCSVRTIEVYQU1QTEU8YnI+ DQo8YnI+DQp0eXBlZGVmIEIgezxicj4NCiZuYnNwOyB0eXBlIHVuaW9uIHs8YnI+DQombmJzcDsg Jm5ic3A7IHR5cGUgYml0cyB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYml0IHdoaXRlIHs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcG9zaXRpb24gMDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyB9PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYml0IGJsYWNrIHs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcG9zaXRpb24gMTs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyB9PGJyPg0KJm5ic3A7ICZuYnNwOyB9PGJyPg0KJm5ic3A7ICZuYnNwOyB0eXBl IGJpdHMgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpdCByZWQgezxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBwb3NpdGlvbiAwOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiaXQgZ3JlZW4gezxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBwb3NpdGlvbiAxOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiaXQgYmx1ZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHBvc2l0aW9uIDI7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4N CiZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyB9PGJyPg0KfTxicj4NCjxicj4NClJlZ2FyZHMs PGJyPg0KTWljaGVsPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBjb3JlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyI+ Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIExhZGlzbGF2IExob3RrYTxi cj4NClNlbnQ6IE1vbmRheSwgSnVseSAyNSwgMjAxNiAxMDo0MSBBTTxicj4NClRvOiBBbmR5IEJp ZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdv cmtzLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IENvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGll dGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW2NvcmVdIGZp eGluZyBZQU5HIHRvIENCT1I8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IE9uIDI1IEp1bCAyMDE2LCBh dCAxNjoyMSwgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1vbiwgSnVsIDI1LCAyMDE2IGF0IDY6MDAgQU0sIExh ZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiPmxob3RrYUBu aWMuY3o8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3Jp dGVzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgSGksPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIG9ubHkgdGFnZ2luZyBhY3R1YWxseSBuZWVk ZWQgd291bGQgYmUgdG88YnI+DQomZ3Q7ICZndDsgaWRlbnRpZnkgdGhlIG9yZGVyZWQgbGlzdCBv ZiBtZW1iZXIgdHlwZXMgd2l0aGluIGEgdW5pb24gdHlwZS48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgdHlwZWRlZiBBIHs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7dHlwZSB1bmlvbiB7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBl IGludDMyIDsmbmJzcDsgJm5ic3A7Ly8gMTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7dHlwZSBzdHJpbmc7IC8vIDI8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3R5 cGUgQjsmbmJzcDsgJm5ic3A7Ly8gMywgNCwgNTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7dHlwZSBpZGVudGl0eXJlZiB7IGJhc2UgYmFyOyB9Jm5ic3A7ICZuYnNwOy8vIDY8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyB9PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHR5cGVkZWYgQiB7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwO3R5cGUgdW5pb24gezxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7dHlwZSB1aW50ODs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdWlu dDE2Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSB1aW50MzI7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgfTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBsZWFmIGZvbyB7IHR5cGUgQTsgfTxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBZQU5HIGFsbG93cyB0aGUgbWVtYmVyIHR5cGVzIHRvIGJlIHJlb3JkZXJlZCBpZiBp dCBkb2VzIG5vdCBjaGFuZ2U8YnI+DQomZ3Q7ICZndDsgdGhlIHZhbHVlIHNldCBhY2NlcHRlZCBi eSB0aGUgdHlwZS4mbmJzcDsgSXQgaXMgbm90IGNsZWFyPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBk b24ndCB0aGluayB0aGlzIGlzIHRydWUuIFRoZSBvbmx5IHN0YXRlbWVudCBpbiA2MDIwYmlzIHRo YXQgaXM8YnI+DQomZ3Q7IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZSBpcyB0aGUgYnVsbGV0IHRoYXQg eW91IGNpdGUgYmVsb3csIGJ1dCBJTU88YnI+DQomZ3Q7IHJlb3JkZXJpbmcgbWVtYmVyIHR5cGVz IGluIGEgdW5pb24gdHlwZSBkZWZpbml0aW9uIG1heSBjaGFuZ2UgdGhlIHR5cGU8YnI+DQomZ3Q7 IHNlbWFudGljcyBiZWNhdXNlIHRoZSByZWNlaXZpbmcgc2lkZSByZXNvbHZlcyB0aGUgdHlwZSBh Y2NvcmRpbmcgdG88YnI+DQomZ3Q7IHRoZSBvcmRlciBvZiBtZW1iZXIgdHlwZXMuPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGRlcGVuZHMgb24gdGhlIGZvcm1h dCwgYnV0IG5vbi1vdmVybGFwcGluZyBtZW1iZXIgdHlwZXMgY2FuPGJyPg0KJmd0OyBjaGFuZ2Ug cG9zaXRpb24gd2l0aG91dCBjaGFuZ2luZyBzeW50YXggb3Igc2VtYW50aWNzLjxicj4NCjxicj4N ClllcywgYnV0LCBmb3IgaW5zdGFuY2UsIHRoZSAmcXVvdDtpbmV0Omhvc3QmcXVvdDsgdHlwZSBp biBSRkMgNjk5MSBoYXMgb3ZlcmxhcHBpbmcgbWVtYmVyczogJnF1b3Q7MS4yLjMuNCZxdW90OyBp cyB2YWxpZCBhcyBib3RoICZxdW90O2luZXQ6aXAtYWRkcmVzcyZxdW90OyBhbmQgJnF1b3Q7aW5l dDpkb21haW4tbmFtZSZxdW90Oy48YnI+DQo8YnI+DQpMYWRhPGJyPg0KPGJyPg0KJmd0OyBUaGUg ZXhhY3QgbWVtYmVyIHR5cGUgdGhhdCBtYXRjaGVzIGlzIG5vdCBpbXBvcnRhbnQuPGJyPg0KJmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHR5cGVkZWYgZm9vMSB7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdW5pb24gezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgaW50MzIgeyByYW5nZSAmcXVvdDsxLi4xMCZxdW90Ozsg fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgaW50MzIg eyByYW5nZSAmcXVvdDsxMS4uMjAmcXVvdDs7IH08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDt0eXBlZGVmIGZvbzIgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0eXBlIHVuaW9uIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0eXBlIGludDMyIHsgcmFuZ2UgJnF1b3Q7MTEuLjIwJnF1b3Q7OyB9PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSBpbnQzMiB7IHJhbmdl ICZxdW90OzEuLjEwJnF1b3Q7OyB9PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O308YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBMYWRhPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5keTxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGlmIG5ldyBtZW1iZXIgdHlwZXMgY2FuIGJlIGFkZGVk IGluIG5ldyBtb2R1bGUgcmV2aXNpb25zLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJ ZiBuZXcgbWVtYmVyIHR5cGVzIGFyZSBhbGxvd2VkIGluIHR5cGVkZWYgQiwgdGhlbiB0aGUgcmVs YXRpdmU8YnI+DQomZ3Q7ICZndDsgcG9zaXRpb24gb2YgKDYpIGNhbiBjaGFuZ2UsIGV2ZW4gaWYg dHlwZWRlZiBBIGRvZXMgbm90IGNoYW5nZS48YnI+DQomZ3Q7ICZndDsgWUFORyBkb2VzIG5vdCBl eHBsaWNpdGx5IHN0YXRlIGlmIHRoaXMgaXMgYWxsb3dlZCBvciBub3QuPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IGJpdHMgYW5kIGVudW1lcmF0aW9ucyBjYW4gYmUgZXhwYW5kZWQgaW4g bmV3IHJldmlzaW9ucywgd2hpY2g8YnI+DQomZ3Q7ICZndDsgY2hhbmdlcyB0aGUgdmFsdWUgc2V0 LCBidXQgZXhpc3RpbmcgdmFsdWUgYW5kIHBvc2l0aW9uIG51bWJlcnMgYXJlPGJyPg0KJmd0OyAm Z3Q7IG5vdCBhbGxvd2VkIHRvIGNoYW5nZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg VGhlIHByb2JsZW1hdGljIHRleHQgaXMgaW4gNjAyMGJpcywgc2VjIDExPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO28mbmJzcDsgQSAmcXVvdDt0eXBlJnF1b3Q7IHN0 YXRlbWVudCBtYXkgYmUgcmVwbGFjZWQgd2l0aCBhbm90aGVyICZxdW90O3R5cGUmcXVvdDsgc3Rh dGVtZW50PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBkb2Vz IG5vdCBjaGFuZ2UgdGhlIHN5bnRheCBvciBzZW1hbnRpY3Mgb2YgdGhlIHR5cGUuJm5ic3A7IEZv cjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4YW1wbGUsIGFuIGlu bGluZSB0eXBlIGRlZmluaXRpb24gbWF5IGJlIHJlcGxhY2VkIHdpdGggYSB0eXBlZGVmLDxicj4N CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2J1dCBhbiBpbnQ4IHR5cGUgY2Fu bm90IGJlIHJlcGxhY2VkIGJ5IGFuIGludDE2LCBzaW5jZSB0aGUgc3ludGF4PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d291bGQgY2hhbmdlLjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJbiBwcmFjdGlj ZSByZW9yZGVyaW5nIG1lbWJlciB0eXBlcyB3b3VsZCBiZSB2ZXJ5IHJhcmUsIGJ1dCB0aGUgU0lE PGJyPg0KJmd0OyAmZ3Q7IG51bWJlcmluZyB3b3VsZCBuZWVkIHRvIHJlbWVtYmVyIHRoZSBtZW1i ZXIgdHlwZSBvcmRlciBmb3IgZWFjaCBsZWFmPGJyPg0KJmd0OyAmZ3Q7IG9yIGxlYWYtbGlzdCB0 aGF0IHJlc29sdmVzIHRvIGEgdW5pb24gdHlwZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgSXQgZG9lc24ndCBoZWxwIHRvIHRhZyBhbnkgb3RoZXIgdHlwZSBiZXNpZGVzIHVuaW9uLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBbmR5PGJyPg0KJmd0 OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyAmZ3Q7IGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+PGJy Pg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExh YnM8YnI+DQomZ3Q7IFBHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPg0KPGJyPg0KLS08YnI+DQpMYWRp c2xhdiBMaG90a2EsIENaLk5JQyBMYWJzPGJyPg0KUEdQIEtleSBJRDogRTc0RThDMEM8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR06MB23084F78C289308C22F2930BFE0D0BN6PR06MB2308namp_-- From nobody Mon Jul 25 10:09:06 2016 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 D801312D50A for ; Mon, 25 Jul 2016 10:09:04 -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 fdlc8VV7fvTT for ; Mon, 25 Jul 2016 10:09:02 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 4C90412D09F for ; Mon, 25 Jul 2016 10:09:02 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id x130so252887797vkc.0 for ; Mon, 25 Jul 2016 10:09:02 -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=3qU0tCOgaWZc+DiXnnhSjtydo55Mkg3G3Elz+CnN8yY=; b=yA7IOdexWDfnPn0RjOXP0CZG55VFidcByJYRLTVCXw5lHVEkk/rk7lYIPBrGBk/Qj2 jpE5xIX4/3ogdYzxNwVx/3JEYerhtbn/LiU4afUXs+M+7Ifdnhmc93wa/CgJhCsMhgz6 cXxiT98xBUJdurmTj62ukF9vrkoGvpdfR5qukRuE7rwLX4iUuX4+/aP9R+iLeLxcC20S hi4GV1DWIllwSfra7D04f3eDw1quf8Pd9c4X1v5whg0I1cI6D+it+9Ggy/9ic2YgGTZM oY2TsgNbiofmdRw6kUHcxLHwmwSC1VcvWBr0bYdPSCf9cCsG79COCWZ8rb+F8bzTgXIS XpIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3qU0tCOgaWZc+DiXnnhSjtydo55Mkg3G3Elz+CnN8yY=; b=CIV0jHkvCTK9BVvKX6YItoYG8/l+hCI7ClIaUtUzCkt49D4Ye0MC9hlCdBOpEQSQ75 lJKdXJJJIVcaKeIoW1AaKo5f8MH9pVtuIklRHmbIBzL/XUhvpT6ETdfMwzqT1SjGNA3/ B8iQFtWv+alxB9DKWdD+Um0eHpI0PRNS3itynKQc2V4T4GMzOr0fy9I+CJJ+2GtuogmR RJg5W0VRGMlW8as4g71v9YL+Cv0JJVabN+Do2z0cGn7WFWHHS35o6UHLhQncNS9nzEUh u0scMoZ5B9rMZPEQKMmESswdkiHx5N5ASdKEw40pxjTD5Gq7ZXsVFDSPkNO1QXc+qChk 1fZA== X-Gm-Message-State: AEkoouu4ppPGG4wgaLIttxGiSjpUS22VNCijkaPRUopCJVyF1JrZPK/bdPYQFFTCkdlSwKRUEpUwh5UUaBnfKw== X-Received: by 10.159.36.205 with SMTP id 71mr8968441uar.121.1469466541297; Mon, 25 Jul 2016 10:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 25 Jul 2016 10:09:00 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Mon, 25 Jul 2016 10:09:00 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=001a113e5dde342f7e053878d780 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 17:09:05 -0000 --001a113e5dde342f7e053878d780 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 25, 2016 at 9:33 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > > > I understand that the enumeration values and bit positions have not been > used over the wire for NETconf and RESTconf. However, this doesn't means > they are irrelevant and can't be used in the context of a new protocol. > Unless you point me on a paragraph in draft-ietf-netmod-rfc6020bis which > say that these numbers have been defined for no reasons and can't be used. > > > There is no text in YANG, NETCONF, or RESTCONF that says these values are sent on the wire. There is no defined purpose for them at all in YANG. They were completely ignored when the union type was designed. Perhaps this is a bug or not. The text I cited is very vague. It does say if "syntax and semantics" is limited to external API behavior or includes internal implementation details. > Regards, > > Michel > > > > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, July 25, 2016 12:17 PM > *To:* Michel Veillette > *Cc:* Ladislav Lhotka ; Core > *Subject:* Re: [core] fixing YANG to CBOR > > > > > > > > On Mon, Jul 25, 2016 at 9:05 AM, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > Hi Lada, Hi Andy > > The important questions we need answer to validate the current solution > are the following. > > - In a union, is it valid to define multiple enumerations which reuse the > same value(s) with a different semantic meaning? > > > > > > Remember that the enum "value" and bit "position" are irrelevant. > > They are not defined in YANG to be used on the wire. > > So Carsten's examples (2 different enumeration types) is valid > > and not a problem for XML and JSON. They are only a problem > > because CBOR is attempting to use something defined NOT to be sent on the > wire. > > > > Lada, There are examples that can be constructed that break, > > and others that don't break. So what? Doesn't help solve anything. > > > > > > Andy > > > > > > - In a union, is it valid to define multiple bits which reuse the same > position(s) with a different semantic meaning? > > In the following examples, value or position 0 means both white and red > which I believe it's invalid. > If this is the case, the currently proposed solution to tag some specific > datatype (bits, enumeration, identityref, instance-identifier) when used > in a union resolve any potential ambiguities. > Can we move ahead with the current solution? > > ENUMERATION EXAMPLE > > typedef A { > type union { > type enumeration { > enum white { > value 0; > } > enum black { > value 1; > } > } > type enumeration { > enum red { > value 0; > } > enum green { > value 1; > } > enum blue { > value 2; > } > } > } > } > > BITS EXAMPLE > > typedef B { > type union { > type bits { > bit white { > position 0; > } > bit black { > position 1; > } > } > type bits { > bit red { > position 0; > } > bit green { > position 1; > } > bit blue { > position 2; > } > } > } > } > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Monday, July 25, 2016 10:41 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] fixing YANG to CBOR > > > > On 25 Jul 2016, at 16:21, Andy Bierman wrote: > > > > > > > > On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > Hi, > > > > > > It seems to me that the only tagging actually needed would be to > > > identify the ordered list of member types within a union type. > > > > > > > > > typedef A { > > > type union { > > > type int32 ; // 1 > > > type string; // 2 > > > type B; // 3, 4, 5 > > > type identityref { base bar; } // 6 > > > } > > > } > > > > > > > > > typedef B { > > > type union { > > > type uint8; > > > type uint16; > > > type uint32; > > > } > > > } > > > > > > leaf foo { type A; } > > > > > > YANG allows the member types to be reordered if it does not change > > > the value set accepted by the type. It is not clear > > > > I don't think this is true. The only statement in 6020bis that is > > related to this issue is the bullet that you cite below, but IMO > > reordering member types in a union type definition may change the type > > semantics because the receiving side resolves the type according to > > the order of member types. > > > > > > > > This depends on the format, but non-overlapping member types can > > change position without changing syntax or semantics. > > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping > members: "1.2.3.4" is valid as both "inet:ip-address" and > "inet:domain-name". > > Lada > > > The exact member type that matches is not important. > > > > typedef foo1 { > > type union { > > type int32 { range "1..10"; } > > type int32 { range "11..20"; } > > } > > } > > > > typedef foo2 { > > type union { > > type int32 { range "11..20"; } > > type int32 { range "1..10"; } > > } > > } > > > > > > > > Lada > > > > Andy > > > > > > > if new member types can be added in new module revisions. > > > > > > If new member types are allowed in typedef B, then the relative > > > position of (6) can change, even if typedef A does not change. > > > YANG does not explicitly state if this is allowed or not. > > > > > > bits and enumerations can be expanded in new revisions, which > > > changes the value set, but existing value and position numbers are > > > not allowed to change. > > > > > > The problematic text is in 6020bis, sec 11 > > > > > > o A "type" statement may be replaced with another "type" statement > > > that does not change the syntax or semantics of the type. For > > > example, an inline type definition may be replaced with a > typedef, > > > but an int8 type cannot be replaced by an int16, since the syntax > > > would change. > > > > > > > > > > > > In practice reordering member types would be very rare, but the SID > > > numbering would need to remember the member type order for each leaf > > > or leaf-list that resolves to a union type. > > > > > > It doesn't help to tag any other type besides union. > > > > > > > > > Andy > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > --001a113e5dde342f7e053878d780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25, 2016 at 9:33 AM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:

Hi Andy

=C2=A0

I understand that the enumeration va= lues and bit positions have not been used over the wire for NETconf and RES= Tconf. However, this doesn't means they are irrelevant and can't be used in the context of a new protocol. U= nless you point me on a paragraph in draft-ietf-netmod-rfc6020bis which say= that these numbers have been defined for no reasons and can't be used.=

=C2=A0


<= /div>
There is no text in YANG, NETCONF, or RESTCONF that says these va= lues are sent on the wire.
There is no defined purpose for them a= t all in YANG.=C2=A0
They were completely ignored when the union = type was designed.
Perhaps this is a bug or not.=C2=A0 The text I= cited is very vague.
It does say if "syntax and semantics&q= uot; is limited to external API behavior or
includes internal imp= lementation details.

=C2=A0
<= p class=3D"MsoNormal">

Regards,

Michel

=C2=A0


Andy
=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, July 25, 2016 12:17 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>; Core <core@ietf.org>
Subject: Re: [core] fixing YANG to CBOR

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 25, 2016 at 9:05 AM, Michel Veillette &l= t;Mi= chel.Veillette@trilliantinc.com> wrote:

Hi Lada, Hi Andy

The important questions we need answer to validate the current solution are= the following.

- In a union, is it valid to define multiple enumerations which reuse the s= ame value(s) with a different semantic meaning?

=C2=A0

=C2=A0

Remember that the enum "value" and bit &qu= ot;position" are irrelevant.

They are not defined in YANG to be used on the wire.=

So Carsten's examples (2 different enumeration t= ypes) is valid

and not a problem for XML and JSON.=C2=A0 They are o= nly a problem

because CBOR is attempting to use something defined = NOT to be sent on the wire.

=C2=A0

Lada, There are examples that can be constructed tha= t break,

and others that don't break. So what? Doesn'= t help solve anything.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

- In a union, is it valid to define multiple bits wh= ich reuse the same position(s) with a different semantic meaning?

In the following examples, value or position 0 means both white and red whi= ch I believe it's invalid.
If this is the case, the currently proposed solution to tag some specific d= atatype (bits,=C2=A0 enumeration, identityref, instance-identifier) when us= ed in a union resolve any potential ambiguities.
Can we move ahead with the current solution?

ENUMERATION EXAMPLE

typedef A {
=C2=A0 type union {
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 enum white {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum black {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 enum red {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum green {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum blue {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
}

BITS EXAMPLE

typedef B {
=C2=A0 type union {
=C2=A0 =C2=A0 type bits {
=C2=A0 =C2=A0 =C2=A0 bit white {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 bit black {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 type bits {
=C2=A0 =C2=A0 =C2=A0 bit red {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 bit green {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 bit blue {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 2;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
}

Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Monday, July 25, 2016 10:41 AM
To: Andy Bierman <andy@yumaworks.com>
Cc: Core <core@ietf.o= rg>
Subject: Re: [core] fixing YANG to CBOR


> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.com> writes:
>
> > Hi,
> >
> > It seems to me that the only tagging actually needed would be to<= br> > > identify the ordered list of member types within a union type. > >
> >
> > typedef A {
> >=C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0type int32 ;=C2=A0 =C2=A0// 1
> >=C2=A0 =C2=A0 =C2=A0type string; // 2
> >=C2=A0 =C2=A0 =C2=A0type B;=C2=A0 =C2=A0// 3, 4, 5
> >=C2=A0 =C2=A0 =C2=A0type identityref { base bar; }=C2=A0 =C2=A0// = 6
> >=C2=A0 =C2=A0}
> > }
> >
> >
> > typedef B {
> >=C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0type uint16;
> >=C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0}
> > }
> >
> > leaf foo { type A; }
> >
> > YANG allows the member types to be reordered if it does not chang= e
> > the value set accepted by the type.=C2=A0 It is not clear
>
> I don't think this is true. The only statement in 6020bis that is<= br> > related to this issue is the bullet that you cite below, but IMO
> reordering member types in a union type definition may change the type=
> semantics because the receiving side resolves the type according to > the order of member types.
>
>
>
> This depends on the format, but non-overlapping member types can
> change position without changing syntax or semantics.

Yes, but, for instance, the "inet:host" type in RFC 6991 has over= lapping members: "1.2.3.4" is valid as both "inet:ip-address= " and "inet:domain-name".

Lada

> The exact member type that matches is not important.
>
>=C2=A0 =C2=A0 typedef foo1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type union {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "1..10"= ; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "11..20"= ;; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0typedef foo2 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type union {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "11..20"= ;; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32 { range "1..10"= ; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>
>
>
> Lada
>
> Andy
>
>
> > if new member types can be added in new module revisions.
> >
> > If new member types are allowed in typedef B, then the relative > > position of (6) can change, even if typedef A does not change. > > YANG does not explicitly state if this is allowed or not.
> >
> > bits and enumerations can be expanded in new revisions, which
> > changes the value set, but existing value and position numbers ar= e
> > not allowed to change.
> >
> > The problematic text is in 6020bis, sec 11
> >
> >=C2=A0 =C2=A0o=C2=A0 A "type" statement may be replaced = with another "type" statement
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0that does not change the syntax or sema= ntics of the type.=C2=A0 For
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0example, an inline type definition may = be replaced with a typedef,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0but an int8 type cannot be replaced by = an int16, since the syntax
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0would change.
> >
> >
> >
> > In practice reordering member types would be very rare, but the S= ID
> > numbering would need to remember the member type order for each l= eaf
> > or leaf-list that resolves to a union type.
> >
> > It doesn't help to tag any other type besides union.
> >
> >
> > Andy
> > _______________________________________________
> > core mailing list
> > core@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/core
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

=C2=A0


--001a113e5dde342f7e053878d780-- From nobody Mon Jul 25 11:00:41 2016 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 880A812D9AA for ; Mon, 25 Jul 2016 11:00:39 -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 EKn7vXTd8eMQ for ; Mon, 25 Jul 2016 11:00:36 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0139.outbound.protection.outlook.com [104.47.37.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D11A12D9B1 for ; Mon, 25 Jul 2016 11:00:36 -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=z+D8coOLUa849HuBoQVS2sAjasw6+6nj1SZ9tIzWQmg=; b=Ywj5n9bBW8qVDo9vtnefiBlCQzbuGP7ByKz4tAz/7zvUeDOHGXeRyrfGH7Ayr82e8koOrWn19W9x/zSnLlEP5lN3VpZOXB50KlP5/8iutD2tg6tdR+kSEGKb+7zlpKWe8qvgC1d17WwMNasFpBOUxFjAwzkunl+J1Q7/Rqaeul8= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 18:00:33 +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.0544.014; Mon, 25 Jul 2016 18:00:33 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] fixing YANG to CBOR Thread-Index: AQHR4+cJQt79bN4pMU+XasZI/tqalKApIRsAgAAW5YCAAAVwAIAAEGZQgAAKbACAAAJAoIAADCgAgAAH7CA= Date: Mon, 25 Jul 2016 18:00:32 +0000 Message-ID: References: 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: bf059442-f554-40db-378d-08d3b4b59293 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:+efwMIfUNe0j6/soqS3ekDEw42lPXMHVSxDdFC9b0XyVBuc45H3ihT4BxooCeAhuOkuvR9lQYIl0rCgrgOdjQ0ChYhG8sLLpsPIEQdIfiU4oGu5nOh1qomEeWFJWTKdDVa0gyO4hd4cfSuKUVRUvZoHwLUlvtfUKA5lR8HZr48+WIeNefd6XbLCxejADU8GxadRCV4gXkoUx6T37BSF7PudUHge5OOE2Pr62uHdw+pumF5wCjRimkyaoJ/0BOjHW7bcRQT1mVpYqoZUKIycyPc12N7fU1DuZauSqaXjmPFw=; 5:FJVk2/TPlFY4J+nTENV6ZrHuU7cbyWMcuKXIeIpbDibv23bnngCJkVjQmDBYF9E4vGNBhI1gGeRYXxOF/B4PSRP+hU1yPbahc8UmT1PGbrp72aiz3MPP0AcGp/vf9v4Vm2Y9ExdDhDso3GlWVGDQOg==; 24:I1PsYeqNqYoi8jkYrbC6n0vblosbzd0RBQiiWT2nhBiYJ5LpEoARYn2jn24p4byoi3OmznxszKrsV/TLdKKnUf/wmJPNkQ3SGP0PVnDI55c=; 7:VL/bn+7lp8QJKZLWeEsGbyLttEpd9kRaWbh9k+JMa3a4EBv0yNYkcHUmid1iSYzm21YXPv0qWYpjznRA35dGOmK9rx0RH2+Bj0jvF8se/hANfo0mCQV0gE4edaMl3nSGerVNAJd0sRDCPHM0bh7BkmN19jCE6tOY64+IqVcfVD3y58kGPDo3y8LC3b4jkqDH5FHTM1GpRm3lwfolAxoU0y4NQFVSM1x2Kap8uh0/29+Utbc+7/IQ40rSXP9q6e0G x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(199003)(13464003)(377454003)(7906003)(3280700002)(105586002)(87936001)(101416001)(3660700001)(5003600100003)(7736002)(7846002)(7696003)(10400500002)(81166006)(19617315012)(86362001)(81156014)(122556002)(5002640100001)(74316002)(19625215002)(19580405001)(19580395003)(575784001)(66066001)(2900100001)(11100500001)(76176999)(8936002)(92566002)(54356999)(77096005)(99286002)(33656002)(790700001)(9686002)(68736007)(6116002)(3846002)(102836003)(50986999)(76576001)(106356001)(19609705001)(8676002)(16236675004)(2906002)(189998001)(586003)(110136002)(97736004)(106116001)(4326007)(15975445007)(19300405004)(2950100001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.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: multipart/alternative; boundary="_000_BN6PR06MB2308607F33BCA0215107F345FE0D0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 18:00:32.7090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 18:00:39 -0000 --_000_BN6PR06MB2308607F33BCA0215107F345FE0D0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW55DQoNCllBTkcgaXMgYSBtb2RlbGluZyBsYW5ndWFnZSBhbmQgc2hhbGwgbm90IGNhcmUg YWJvdXQgd2hhdCBpcyBzZW50IG9uIHRoZSB3aXJlLg0KWUFORyBqdXN0IGRlZmluZXMgdGhlIHNl bWFudGljIChhc3NpZ24gYSB0ZXh0IGFuZCBhIG51bWJlciBmb3IgZWFjaCBlbnVtZXJhdGlvbiBh bmQgYml0IHBvc2l0aW9uKS4NCg0KQm90aCBORVRDT05GIGFuZCBSRVNUQ09ORiBhcmUgbm9uIGNv bnN0cmFpbmVkIGFuZCB0ZXh0IGJhc2VkLg0KSW4gdGhpcyBjb250ZXh0LCB0aGUgdXNlIG9mIHRo ZSB0ZXh0IHRvIHRyYW5zZmVyIHRoZSB2YWx1ZSBvZiBhbiBlbnVtZXJhdGlvbiBvciBhIGZsYWcg d2l0aGluIGEgYml0cyB3YXMgbG9naWNhbC4NCkluIHRoZSBjb250ZXh0IG9mIGEgY29uc3RyYWlu ZWQgcHJvdG9jb2wsIGl0IHNob3VsZCBub3cgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBudW1iZXIu DQoNCkl0IGlzIHZlcnkgcG9zc2libGUgdGhhdCBzb21lIGluZGl2aWR1YWxzIGZvY3VzZWQgTkVU Q09ORiBvciBSRVNUQ09ORiBkaWRuJ3QgY2FyZSBhYm91dCB0aG9zZSBudW1iZXJzLCBidXQgSSds bCBiZSBzdXJwcmlzZWQgaWYgWUFORyBkZXNpZ24gdGVhbSBoYXZlIGludHJvZHVjZWQgdGhlc2Ug bnVtYmVycyBqdXN0IGZvciBmdW4uDQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KRnJvbTogQW5keSBC aWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5IDI1 LCAyMDE2IDE6MDkgUE0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRy aWxsaWFudGluYy5jb20+DQpDYzogTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PjsgQ29y ZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gZml4aW5nIFlBTkcgdG8gQ0JP Ug0KDQoNCg0KT24gTW9uLCBKdWwgMjUsIDIwMTYgYXQgOTozMyBBTSwgTWljaGVsIFZlaWxsZXR0 ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNoZWwuVmVpbGxl dHRlQHRyaWxsaWFudGluYy5jb20+PiB3cm90ZToNCkhpIEFuZHkNCg0KSSB1bmRlcnN0YW5kIHRo YXQgdGhlIGVudW1lcmF0aW9uIHZhbHVlcyBhbmQgYml0IHBvc2l0aW9ucyBoYXZlIG5vdCBiZWVu IHVzZWQgb3ZlciB0aGUgd2lyZSBmb3IgTkVUY29uZiBhbmQgUkVTVGNvbmYuIEhvd2V2ZXIsIHRo aXMgZG9lc24ndCBtZWFucyB0aGV5IGFyZSBpcnJlbGV2YW50IGFuZCBjYW4ndCBiZSB1c2VkIGlu IHRoZSBjb250ZXh0IG9mIGEgbmV3IHByb3RvY29sLiBVbmxlc3MgeW91IHBvaW50IG1lIG9uIGEg cGFyYWdyYXBoIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwMjBiaXMgd2hpY2ggc2F5IHRoYXQg dGhlc2UgbnVtYmVycyBoYXZlIGJlZW4gZGVmaW5lZCBmb3Igbm8gcmVhc29ucyBhbmQgY2FuJ3Qg YmUgdXNlZC4NCg0KDQpUaGVyZSBpcyBubyB0ZXh0IGluIFlBTkcsIE5FVENPTkYsIG9yIFJFU1RD T05GIHRoYXQgc2F5cyB0aGVzZSB2YWx1ZXMgYXJlIHNlbnQgb24gdGhlIHdpcmUuDQpUaGVyZSBp cyBubyBkZWZpbmVkIHB1cnBvc2UgZm9yIHRoZW0gYXQgYWxsIGluIFlBTkcuDQpUaGV5IHdlcmUg Y29tcGxldGVseSBpZ25vcmVkIHdoZW4gdGhlIHVuaW9uIHR5cGUgd2FzIGRlc2lnbmVkLg0KUGVy aGFwcyB0aGlzIGlzIGEgYnVnIG9yIG5vdC4gIFRoZSB0ZXh0IEkgY2l0ZWQgaXMgdmVyeSB2YWd1 ZS4NCkl0IGRvZXMgc2F5IGlmICJzeW50YXggYW5kIHNlbWFudGljcyIgaXMgbGltaXRlZCB0byBl eHRlcm5hbCBBUEkgYmVoYXZpb3Igb3INCmluY2x1ZGVzIGludGVybmFsIGltcGxlbWVudGF0aW9u IGRldGFpbHMuDQoNCg0KUmVnYXJkcywNCk1pY2hlbA0KDQoNCkFuZHkNCg0KDQpGcm9tOiBBbmR5 IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbT5dDQpTZW50OiBNb25kYXksIEp1bHkgMjUsIDIwMTYgMTI6MTcgUE0NClRvOiBNaWNoZWwg VmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hl bC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT4+DQpDYzogTGFkaXNsYXYgTGhvdGthIDxsaG90 a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6Pj47IENvcmUgPGNvcmVAaWV0Zi5vcmc8bWFp bHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBmaXhpbmcgWUFORyB0byBD Qk9SDQoNCg0KDQpPbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA5OjA1IEFNLCBNaWNoZWwgVmVpbGxl dHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hlbC5WZWls bGV0dGVAdHJpbGxpYW50aW5jLmNvbT4+IHdyb3RlOg0KSGkgTGFkYSwgSGkgQW5keQ0KDQpUaGUg aW1wb3J0YW50IHF1ZXN0aW9ucyB3ZSBuZWVkIGFuc3dlciB0byB2YWxpZGF0ZSB0aGUgY3VycmVu dCBzb2x1dGlvbiBhcmUgdGhlIGZvbGxvd2luZy4NCg0KLSBJbiBhIHVuaW9uLCBpcyBpdCB2YWxp ZCB0byBkZWZpbmUgbXVsdGlwbGUgZW51bWVyYXRpb25zIHdoaWNoIHJldXNlIHRoZSBzYW1lIHZh bHVlKHMpIHdpdGggYSBkaWZmZXJlbnQgc2VtYW50aWMgbWVhbmluZz8NCg0KDQpSZW1lbWJlciB0 aGF0IHRoZSBlbnVtICJ2YWx1ZSIgYW5kIGJpdCAicG9zaXRpb24iIGFyZSBpcnJlbGV2YW50Lg0K VGhleSBhcmUgbm90IGRlZmluZWQgaW4gWUFORyB0byBiZSB1c2VkIG9uIHRoZSB3aXJlLg0KU28g Q2Fyc3RlbidzIGV4YW1wbGVzICgyIGRpZmZlcmVudCBlbnVtZXJhdGlvbiB0eXBlcykgaXMgdmFs aWQNCmFuZCBub3QgYSBwcm9ibGVtIGZvciBYTUwgYW5kIEpTT04uICBUaGV5IGFyZSBvbmx5IGEg cHJvYmxlbQ0KYmVjYXVzZSBDQk9SIGlzIGF0dGVtcHRpbmcgdG8gdXNlIHNvbWV0aGluZyBkZWZp bmVkIE5PVCB0byBiZSBzZW50IG9uIHRoZSB3aXJlLg0KDQpMYWRhLCBUaGVyZSBhcmUgZXhhbXBs ZXMgdGhhdCBjYW4gYmUgY29uc3RydWN0ZWQgdGhhdCBicmVhaywNCmFuZCBvdGhlcnMgdGhhdCBk b24ndCBicmVhay4gU28gd2hhdD8gRG9lc24ndCBoZWxwIHNvbHZlIGFueXRoaW5nLg0KDQoNCkFu ZHkNCg0KDQotIEluIGEgdW5pb24sIGlzIGl0IHZhbGlkIHRvIGRlZmluZSBtdWx0aXBsZSBiaXRz IHdoaWNoIHJldXNlIHRoZSBzYW1lIHBvc2l0aW9uKHMpIHdpdGggYSBkaWZmZXJlbnQgc2VtYW50 aWMgbWVhbmluZz8NCg0KSW4gdGhlIGZvbGxvd2luZyBleGFtcGxlcywgdmFsdWUgb3IgcG9zaXRp b24gMCBtZWFucyBib3RoIHdoaXRlIGFuZCByZWQgd2hpY2ggSSBiZWxpZXZlIGl0J3MgaW52YWxp ZC4NCklmIHRoaXMgaXMgdGhlIGNhc2UsIHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgc29sdXRpb24g dG8gdGFnIHNvbWUgc3BlY2lmaWMgZGF0YXR5cGUgKGJpdHMsICBlbnVtZXJhdGlvbiwgaWRlbnRp dHlyZWYsIGluc3RhbmNlLWlkZW50aWZpZXIpIHdoZW4gdXNlZCBpbiBhIHVuaW9uIHJlc29sdmUg YW55IHBvdGVudGlhbCBhbWJpZ3VpdGllcy4NCkNhbiB3ZSBtb3ZlIGFoZWFkIHdpdGggdGhlIGN1 cnJlbnQgc29sdXRpb24/DQoNCkVOVU1FUkFUSU9OIEVYQU1QTEUNCg0KdHlwZWRlZiBBIHsNCiAg dHlwZSB1bmlvbiB7DQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICBlbnVtIHdoaXRlIHsN CiAgICAgICAgdmFsdWUgMDsNCiAgICAgIH0NCiAgICAgIGVudW0gYmxhY2sgew0KICAgICAgICB2 YWx1ZSAxOw0KICAgICAgfQ0KICAgIH0NCiAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgIGVu dW0gcmVkIHsNCiAgICAgICAgdmFsdWUgMDsNCiAgICAgIH0NCiAgICAgIGVudW0gZ3JlZW4gew0K ICAgICAgICB2YWx1ZSAxOw0KICAgICAgfQ0KICAgICAgZW51bSBibHVlIHsNCiAgICAgICAgdmFs dWUgMjsNCiAgICAgIH0NCiAgICB9DQogIH0NCn0NCg0KQklUUyBFWEFNUExFDQoNCnR5cGVkZWYg QiB7DQogIHR5cGUgdW5pb24gew0KICAgIHR5cGUgYml0cyB7DQogICAgICBiaXQgd2hpdGUgew0K ICAgICAgICBwb3NpdGlvbiAwOw0KICAgICAgfQ0KICAgICAgYml0IGJsYWNrIHsNCiAgICAgICAg cG9zaXRpb24gMTsNCiAgICAgIH0NCiAgICB9DQogICAgdHlwZSBiaXRzIHsNCiAgICAgIGJpdCBy ZWQgew0KICAgICAgICBwb3NpdGlvbiAwOw0KICAgICAgfQ0KICAgICAgYml0IGdyZWVuIHsNCiAg ICAgICAgcG9zaXRpb24gMTsNCiAgICAgIH0NCiAgICAgIGJpdCBibHVlIHsNCiAgICAgICAgcG9z aXRpb24gMjsNCiAgICAgIH0NCiAgICB9DQogIH0NCn0NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIExh ZGlzbGF2IExob3RrYQ0KU2VudDogTW9uZGF5LCBKdWx5IDI1LCAyMDE2IDEwOjQxIEFNDQpUbzog QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv bT4+DQpDYzogQ29yZSA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW2NvcmVdIGZpeGluZyBZQU5HIHRvIENCT1INCg0KDQo+IE9uIDI1IEp1bCAyMDE2 LCBhdCAxNjoyMSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KPg0KPg0KPg0KPiBPbiBNb24sIEp1bCAyNSwgMjAxNiBh dCA2OjAwIEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBu aWMuY3o+PiB3cm90ZToNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyaXRlczoNCj4NCj4gPiBIaSwNCj4gPg0KPiA+IEl0IHNl ZW1zIHRvIG1lIHRoYXQgdGhlIG9ubHkgdGFnZ2luZyBhY3R1YWxseSBuZWVkZWQgd291bGQgYmUg dG8NCj4gPiBpZGVudGlmeSB0aGUgb3JkZXJlZCBsaXN0IG9mIG1lbWJlciB0eXBlcyB3aXRoaW4g YSB1bmlvbiB0eXBlLg0KPiA+DQo+ID4NCj4gPiB0eXBlZGVmIEEgew0KPiA+ICAgdHlwZSB1bmlv biB7DQo+ID4gICAgIHR5cGUgaW50MzIgOyAgIC8vIDENCj4gPiAgICAgdHlwZSBzdHJpbmc7IC8v IDINCj4gPiAgICAgdHlwZSBCOyAgIC8vIDMsIDQsIDUNCj4gPiAgICAgdHlwZSBpZGVudGl0eXJl ZiB7IGJhc2UgYmFyOyB9ICAgLy8gNg0KPiA+ICAgfQ0KPiA+IH0NCj4gPg0KPiA+DQo+ID4gdHlw ZWRlZiBCIHsNCj4gPiAgIHR5cGUgdW5pb24gew0KPiA+ICAgICB0eXBlIHVpbnQ4Ow0KPiA+ICAg ICB0eXBlIHVpbnQxNjsNCj4gPiAgICAgdHlwZSB1aW50MzI7DQo+ID4gICB9DQo+ID4gfQ0KPiA+ DQo+ID4gbGVhZiBmb28geyB0eXBlIEE7IH0NCj4gPg0KPiA+IFlBTkcgYWxsb3dzIHRoZSBtZW1i ZXIgdHlwZXMgdG8gYmUgcmVvcmRlcmVkIGlmIGl0IGRvZXMgbm90IGNoYW5nZQ0KPiA+IHRoZSB2 YWx1ZSBzZXQgYWNjZXB0ZWQgYnkgdGhlIHR5cGUuICBJdCBpcyBub3QgY2xlYXINCj4NCj4gSSBk b24ndCB0aGluayB0aGlzIGlzIHRydWUuIFRoZSBvbmx5IHN0YXRlbWVudCBpbiA2MDIwYmlzIHRo YXQgaXMNCj4gcmVsYXRlZCB0byB0aGlzIGlzc3VlIGlzIHRoZSBidWxsZXQgdGhhdCB5b3UgY2l0 ZSBiZWxvdywgYnV0IElNTw0KPiByZW9yZGVyaW5nIG1lbWJlciB0eXBlcyBpbiBhIHVuaW9uIHR5 cGUgZGVmaW5pdGlvbiBtYXkgY2hhbmdlIHRoZSB0eXBlDQo+IHNlbWFudGljcyBiZWNhdXNlIHRo ZSByZWNlaXZpbmcgc2lkZSByZXNvbHZlcyB0aGUgdHlwZSBhY2NvcmRpbmcgdG8NCj4gdGhlIG9y ZGVyIG9mIG1lbWJlciB0eXBlcy4NCj4NCj4NCj4NCj4gVGhpcyBkZXBlbmRzIG9uIHRoZSBmb3Jt YXQsIGJ1dCBub24tb3ZlcmxhcHBpbmcgbWVtYmVyIHR5cGVzIGNhbg0KPiBjaGFuZ2UgcG9zaXRp b24gd2l0aG91dCBjaGFuZ2luZyBzeW50YXggb3Igc2VtYW50aWNzLg0KDQpZZXMsIGJ1dCwgZm9y IGluc3RhbmNlLCB0aGUgImluZXQ6aG9zdCIgdHlwZSBpbiBSRkMgNjk5MSBoYXMgb3ZlcmxhcHBp bmcgbWVtYmVyczogIjEuMi4zLjQiIGlzIHZhbGlkIGFzIGJvdGggImluZXQ6aXAtYWRkcmVzcyIg YW5kICJpbmV0OmRvbWFpbi1uYW1lIi4NCg0KTGFkYQ0KDQo+IFRoZSBleGFjdCBtZW1iZXIgdHlw ZSB0aGF0IG1hdGNoZXMgaXMgbm90IGltcG9ydGFudC4NCj4NCj4gICAgdHlwZWRlZiBmb28xIHsN Cj4gICAgICAgdHlwZSB1bmlvbiB7DQo+ICAgICAgICAgIHR5cGUgaW50MzIgeyByYW5nZSAiMS4u MTAiOyB9DQo+ICAgICAgICAgIHR5cGUgaW50MzIgeyByYW5nZSAiMTEuLjIwIjsgfQ0KPiAgICAg ICB9DQo+ICAgICB9DQo+DQo+ICAgdHlwZWRlZiBmb28yIHsNCj4gICAgICAgdHlwZSB1bmlvbiB7 DQo+ICAgICAgICAgIHR5cGUgaW50MzIgeyByYW5nZSAiMTEuLjIwIjsgfQ0KPiAgICAgICAgICB0 eXBlIGludDMyIHsgcmFuZ2UgIjEuLjEwIjsgfQ0KPiAgICAgICB9DQo+ICAgICB9DQo+DQo+DQo+ DQo+IExhZGENCj4NCj4gQW5keQ0KPg0KPg0KPiA+IGlmIG5ldyBtZW1iZXIgdHlwZXMgY2FuIGJl IGFkZGVkIGluIG5ldyBtb2R1bGUgcmV2aXNpb25zLg0KPiA+DQo+ID4gSWYgbmV3IG1lbWJlciB0 eXBlcyBhcmUgYWxsb3dlZCBpbiB0eXBlZGVmIEIsIHRoZW4gdGhlIHJlbGF0aXZlDQo+ID4gcG9z aXRpb24gb2YgKDYpIGNhbiBjaGFuZ2UsIGV2ZW4gaWYgdHlwZWRlZiBBIGRvZXMgbm90IGNoYW5n ZS4NCj4gPiBZQU5HIGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUgaWYgdGhpcyBpcyBhbGxvd2Vk IG9yIG5vdC4NCj4gPg0KPiA+IGJpdHMgYW5kIGVudW1lcmF0aW9ucyBjYW4gYmUgZXhwYW5kZWQg aW4gbmV3IHJldmlzaW9ucywgd2hpY2gNCj4gPiBjaGFuZ2VzIHRoZSB2YWx1ZSBzZXQsIGJ1dCBl eGlzdGluZyB2YWx1ZSBhbmQgcG9zaXRpb24gbnVtYmVycyBhcmUNCj4gPiBub3QgYWxsb3dlZCB0 byBjaGFuZ2UuDQo+ID4NCj4gPiBUaGUgcHJvYmxlbWF0aWMgdGV4dCBpcyBpbiA2MDIwYmlzLCBz ZWMgMTENCj4gPg0KPiA+ICAgbyAgQSAidHlwZSIgc3RhdGVtZW50IG1heSBiZSByZXBsYWNlZCB3 aXRoIGFub3RoZXIgInR5cGUiIHN0YXRlbWVudA0KPiA+ICAgICAgIHRoYXQgZG9lcyBub3QgY2hh bmdlIHRoZSBzeW50YXggb3Igc2VtYW50aWNzIG9mIHRoZSB0eXBlLiAgRm9yDQo+ID4gICAgICAg ZXhhbXBsZSwgYW4gaW5saW5lIHR5cGUgZGVmaW5pdGlvbiBtYXkgYmUgcmVwbGFjZWQgd2l0aCBh IHR5cGVkZWYsDQo+ID4gICAgICAgYnV0IGFuIGludDggdHlwZSBjYW5ub3QgYmUgcmVwbGFjZWQg YnkgYW4gaW50MTYsIHNpbmNlIHRoZSBzeW50YXgNCj4gPiAgICAgICB3b3VsZCBjaGFuZ2UuDQo+ ID4NCj4gPg0KPiA+DQo+ID4gSW4gcHJhY3RpY2UgcmVvcmRlcmluZyBtZW1iZXIgdHlwZXMgd291 bGQgYmUgdmVyeSByYXJlLCBidXQgdGhlIFNJRA0KPiA+IG51bWJlcmluZyB3b3VsZCBuZWVkIHRv IHJlbWVtYmVyIHRoZSBtZW1iZXIgdHlwZSBvcmRlciBmb3IgZWFjaCBsZWFmDQo+ID4gb3IgbGVh Zi1saXN0IHRoYXQgcmVzb2x2ZXMgdG8gYSB1bmlvbiB0eXBlLg0KPiA+DQo+ID4gSXQgZG9lc24n dCBoZWxwIHRvIHRhZyBhbnkgb3RoZXIgdHlwZSBiZXNpZGVzIHVuaW9uLg0KPiA+DQo+ID4NCj4g PiBBbmR5DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVA aWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo+DQo+IC0tDQo+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDog RTc0RThDMEMNCg0KLS0NCkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6 IEU3NEU4QzBDDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQoN Cg== --_000_BN6PR06MB2308607F33BCA0215107F345FE0D0BN6PR06MB2308namp_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQW55PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+WUFORyBpcyBhIG1vZGVsaW5nIGxhbmd1YWdlIGFuZCBzaGFs bCBub3QgY2FyZSBhYm91dCB3aGF0IGlzIHNlbnQgb24gdGhlIHdpcmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+WUFORyBqdXN0IGRlZmluZXMgdGhlIHNlbWFudGljIChhc3NpZ24gYSB0ZXh0IGFuZCBhIG51 bWJlciBmb3IgZWFjaCBlbnVtZXJhdGlvbiBhbmQgYml0IHBvc2l0aW9uKS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Cb3RoIE5FVENPTkYgYW5kIFJFU1RDT05GIGFy ZSBub24gY29uc3RyYWluZWQgYW5kIHRleHQgYmFzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhp cyBjb250ZXh0LCB0aGUgdXNlIG9mIHRoZSB0ZXh0IHRvIHRyYW5zZmVyIHRoZSB2YWx1ZSBvZiBh biBlbnVtZXJhdGlvbiBvciBhIGZsYWcgd2l0aGluIGEgYml0cyB3YXMgbG9naWNhbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JbiB0aGUgY29udGV4dCBvZiBhIGNvbnN0cmFpbmVkIHByb3RvY29sLCBpdCBz aG91bGQgbm93IGJlIHBvc3NpYmxlIHRvIHVzZSB0aGUgbnVtYmVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IGlzIHZlcnkgcG9zc2libGUgdGhhdCBzb21lIGlu ZGl2aWR1YWxzIGZvY3VzZWQgTkVUQ09ORiBvciBSRVNUQ09ORiBkaWRuJ3QgY2FyZSBhYm91dCB0 aG9zZSBudW1iZXJzLCBidXQgSSdsbCBiZSBzdXJwcmlzZWQgaWYgWUFORyBkZXNpZ24gdGVhbSBo YXZlIGludHJvZHVjZWQNCiB0aGVzZSBudW1iZXJzIGp1c3QgZm9yIGZ1bi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1p Y2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjUsIDIwMTYgMTowOSBQTTxicj4NCjxiPlRv OjwvYj4gTWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTGFkaXNsYXYgTGhvdGthICZsdDtsaG90a2FAbmljLmN6 Jmd0OzsgQ29yZSAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtjb3JlXSBmaXhpbmcgWUFORyB0byBDQk9SPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBKdWwgMjUsIDIwMTYgYXQgOTozMyBBTSwgTWljaGVsIFZlaWxsZXR0ZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SGkgQW5keTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JIHVuZGVyc3RhbmQgdGhhdCB0aGUgZW51bWVyYXRpb24gdmFsdWVzIGFuZCBi aXQgcG9zaXRpb25zIGhhdmUgbm90IGJlZW4gdXNlZCBvdmVyIHRoZSB3aXJlIGZvciBORVRjb25m DQogYW5kIFJFU1Rjb25mLiBIb3dldmVyLCB0aGlzIGRvZXNuJ3QgbWVhbnMgdGhleSBhcmUgPC9z cGFuPmlycmVsZXZhbnQgYW5kIGNhbid0IGJlIHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgYSBuZXcg cHJvdG9jb2wuIFVubGVzcyB5b3UgcG9pbnQgbWUgb24gYSBwYXJhZ3JhcGggaW4gZHJhZnQtaWV0 Zi1uZXRtb2QtcmZjNjAyMGJpcyB3aGljaCBzYXkgdGhhdCB0aGVzZSBudW1iZXJzIGhhdmUgYmVl biBkZWZpbmVkIGZvciBubyByZWFzb25zIGFuZCBjYW4ndA0KIGJlIHVzZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZXJlIGlzIG5vIHRleHQgaW4gWUFORywgTkVUQ09ORiwgb3IgUkVTVENPTkYgdGhhdCBzYXlzIHRo ZXNlIHZhbHVlcyBhcmUgc2VudCBvbiB0aGUgd2lyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5vIGRlZmluZWQgcHVycG9zZSBm b3IgdGhlbSBhdCBhbGwgaW4gWUFORy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXkgd2VyZSBjb21wbGV0ZWx5IGlnbm9yZWQgd2hl biB0aGUgdW5pb24gdHlwZSB3YXMgZGVzaWduZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIHRoaXMgaXMgYSBidWcgb3Igbm90LiZu YnNwOyBUaGUgdGV4dCBJIGNpdGVkIGlzIHZlcnkgdmFndWUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBkb2VzIHNheSBpZiAmcXVvdDtzeW50 YXggYW5kIHNlbWFudGljcyZxdW90OyBpcyBsaW1pdGVkIHRvIGV4dGVybmFsIEFQSSBiZWhhdmlv ciBvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aW5jbHVkZXMgaW50ZXJuYWwgaW1wbGVtZW50YXRpb24gZGV0YWlscy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pY2hlbA0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBBbmR5IEJpZXJtYW4gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YW5keUB5dW1hd29ya3Mu Y29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIEp1bHkgMjUsIDIwMTYgMTI6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hlbCBWZWlsbGV0 dGUgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRp bmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudGluYy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gTGFkaXNsYXYgTGhvdGthICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmxob3Rr YUBuaWMuY3oiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmxob3RrYUBuaWMuY3o8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsgQ29yZSAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5j b3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtjb3JlXSBmaXhpbmcgWUFORyB0byBDQk9SPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA5OjA1IEFNLCBNaWNoZWwg VmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRp bmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgTGFkYSwg SGkgQW5keTxicj4NCjxicj4NClRoZSBpbXBvcnRhbnQgcXVlc3Rpb25zIHdlIG5lZWQgYW5zd2Vy IHRvIHZhbGlkYXRlIHRoZSBjdXJyZW50IHNvbHV0aW9uIGFyZSB0aGUgZm9sbG93aW5nLjxicj4N Cjxicj4NCi0gSW4gYSB1bmlvbiwgaXMgaXQgdmFsaWQgdG8gZGVmaW5lIG11bHRpcGxlIGVudW1l cmF0aW9ucyB3aGljaCByZXVzZSB0aGUgc2FtZSB2YWx1ZShzKSB3aXRoIGEgZGlmZmVyZW50IHNl bWFudGljIG1lYW5pbmc/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlbWVtYmVyIHRoYXQgdGhlIGVudW0gJnF1b3Q7 dmFsdWUmcXVvdDsgYW5kIGJpdCAmcXVvdDtwb3NpdGlvbiZxdW90OyBhcmUgaXJyZWxldmFudC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl eSBhcmUgbm90IGRlZmluZWQgaW4gWUFORyB0byBiZSB1c2VkIG9uIHRoZSB3aXJlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyBDYXJzdGVu J3MgZXhhbXBsZXMgKDIgZGlmZmVyZW50IGVudW1lcmF0aW9uIHR5cGVzKSBpcyB2YWxpZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQgbm90 IGEgcHJvYmxlbSBmb3IgWE1MIGFuZCBKU09OLiZuYnNwOyBUaGV5IGFyZSBvbmx5IGEgcHJvYmxl bTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5i ZWNhdXNlIENCT1IgaXMgYXR0ZW1wdGluZyB0byB1c2Ugc29tZXRoaW5nIGRlZmluZWQgTk9UIHRv IGJlIHNlbnQgb24gdGhlIHdpcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5MYWRhLCBUaGVyZSBhcmUgZXhhbXBsZXMgdGhhdCBjYW4g YmUgY29uc3RydWN0ZWQgdGhhdCBicmVhayw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW5kIG90aGVycyB0aGF0IGRvbid0IGJyZWFrLiBTbyB3 aGF0PyBEb2Vzbid0IGhlbHAgc29sdmUgYW55dGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIEluIGEgdW5pb24sIGlzIGl0IHZh bGlkIHRvIGRlZmluZSBtdWx0aXBsZSBiaXRzIHdoaWNoIHJldXNlIHRoZSBzYW1lIHBvc2l0aW9u KHMpIHdpdGggYSBkaWZmZXJlbnQgc2VtYW50aWMgbWVhbmluZz88YnI+DQo8YnI+DQpJbiB0aGUg Zm9sbG93aW5nIGV4YW1wbGVzLCB2YWx1ZSBvciBwb3NpdGlvbiAwIG1lYW5zIGJvdGggd2hpdGUg YW5kIHJlZCB3aGljaCBJIGJlbGlldmUgaXQncyBpbnZhbGlkLjxicj4NCklmIHRoaXMgaXMgdGhl IGNhc2UsIHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgc29sdXRpb24gdG8gdGFnIHNvbWUgc3BlY2lm aWMgZGF0YXR5cGUgKGJpdHMsJm5ic3A7IGVudW1lcmF0aW9uLCBpZGVudGl0eXJlZiwgaW5zdGFu Y2UtaWRlbnRpZmllcikgd2hlbiB1c2VkIGluIGEgdW5pb24gcmVzb2x2ZSBhbnkgcG90ZW50aWFs IGFtYmlndWl0aWVzLjxicj4NCkNhbiB3ZSBtb3ZlIGFoZWFkIHdpdGggdGhlIGN1cnJlbnQgc29s dXRpb24/PGJyPg0KPGJyPg0KRU5VTUVSQVRJT04gRVhBTVBMRTxicj4NCjxicj4NCnR5cGVkZWYg QSB7PGJyPg0KJm5ic3A7IHR5cGUgdW5pb24gezxicj4NCiZuYnNwOyAmbmJzcDsgdHlwZSBlbnVt ZXJhdGlvbiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW51bSB3aGl0ZSB7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZhbHVlIDA7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgfTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0gYmxhY2sgezxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB2YWx1ZSAxOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08 YnI+DQombmJzcDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7IHR5cGUgZW51bWVyYXRpb24g ezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0gcmVkIHs8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdmFsdWUgMDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZW51bSBncmVlbiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHZhbHVlIDE7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGVudW0gYmx1ZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHZhbHVlIDI7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyAmbmJz cDsgfTxicj4NCiZuYnNwOyB9PGJyPg0KfTxicj4NCjxicj4NCkJJVFMgRVhBTVBMRTxicj4NCjxi cj4NCnR5cGVkZWYgQiB7PGJyPg0KJm5ic3A7IHR5cGUgdW5pb24gezxicj4NCiZuYnNwOyAmbmJz cDsgdHlwZSBiaXRzIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiaXQgd2hpdGUgezxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwb3NpdGlvbiAwOzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiaXQgYmxhY2sgezxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwb3NpdGlvbiAxOzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7IHR5cGUgYml0 cyB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYml0IHJlZCB7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHBvc2l0aW9uIDA7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpdCBncmVlbiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHBvc2l0aW9uIDE7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpdCBibHVlIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgcG9zaXRpb24gMjs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KJm5i c3A7ICZuYnNwOyB9PGJyPg0KJm5ic3A7IH08YnI+DQp9PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+ DQpNaWNoZWw8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IGNvcmUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIExhZGlz bGF2IExob3RrYTxicj4NClNlbnQ6IE1vbmRheSwgSnVseSAyNSwgMjAxNiAxMDo0MSBBTTxicj4N ClRvOiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20i IHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCkNjOiBDb3Jl ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbY29yZV0gZml4aW5nIFlBTkcgdG8g Q0JPUjxicj4NCjxicj4NCjxicj4NCiZndDsgT24gMjUgSnVsIDIwMTYsIGF0IDE2OjIxLCBBbmR5 IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0i X2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1vbiwgSnVsIDI1LCAyMDE2IGF0IDY6MDAgQU0s IExhZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdl dD0iX2JsYW5rIj5saG90a2FAbmljLmN6PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBBbmR5IEJp ZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2Js YW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cml0ZXM6PGJyPg0KJmd0Ozxicj4NCiZn dDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgb25seSB0YWdnaW5nIGFjdHVhbGx5IG5lZWRlZCB3b3VsZCBiZSB0bzxicj4NCiZn dDsgJmd0OyBpZGVudGlmeSB0aGUgb3JkZXJlZCBsaXN0IG9mIG1lbWJlciB0eXBlcyB3aXRoaW4g YSB1bmlvbiB0eXBlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyB0eXBlZGVmIEEgezxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDt0eXBlIHVuaW9uIHs8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgaW50MzIgOyZuYnNwOyAmbmJzcDsv LyAxPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIHN0cmluZzsgLy8gMjxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBCOyZuYnNwOyAmbmJzcDsvLyAz LCA0LCA1PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGlkZW50aXR5cmVm IHsgYmFzZSBiYXI7IH0mbmJzcDsgJm5ic3A7Ly8gNjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDt9PGJyPg0KJmd0OyAmZ3Q7IH08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgdHlwZWRlZiBCIHs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7dHlwZSB1bmlv biB7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIHVpbnQ4Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSB1aW50MTY7PGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDt0eXBlIHVpbnQzMjs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 fTxicj4NCiZndDsgJmd0OyB9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGxlYWYgZm9v IHsgdHlwZSBBOyB9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlBTkcgYWxsb3dzIHRo ZSBtZW1iZXIgdHlwZXMgdG8gYmUgcmVvcmRlcmVkIGlmIGl0IGRvZXMgbm90IGNoYW5nZTxicj4N CiZndDsgJmd0OyB0aGUgdmFsdWUgc2V0IGFjY2VwdGVkIGJ5IHRoZSB0eXBlLiZuYnNwOyBJdCBp cyBub3QgY2xlYXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdHJ1 ZS4gVGhlIG9ubHkgc3RhdGVtZW50IGluIDYwMjBiaXMgdGhhdCBpczxicj4NCiZndDsgcmVsYXRl ZCB0byB0aGlzIGlzc3VlIGlzIHRoZSBidWxsZXQgdGhhdCB5b3UgY2l0ZSBiZWxvdywgYnV0IElN Tzxicj4NCiZndDsgcmVvcmRlcmluZyBtZW1iZXIgdHlwZXMgaW4gYSB1bmlvbiB0eXBlIGRlZmlu aXRpb24gbWF5IGNoYW5nZSB0aGUgdHlwZTxicj4NCiZndDsgc2VtYW50aWNzIGJlY2F1c2UgdGhl IHJlY2VpdmluZyBzaWRlIHJlc29sdmVzIHRoZSB0eXBlIGFjY29yZGluZyB0bzxicj4NCiZndDsg dGhlIG9yZGVyIG9mIG1lbWJlciB0eXBlcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoaXMgZGVwZW5kcyBvbiB0aGUgZm9ybWF0LCBidXQgbm9uLW92ZXJsYXBwaW5n IG1lbWJlciB0eXBlcyBjYW48YnI+DQomZ3Q7IGNoYW5nZSBwb3NpdGlvbiB3aXRob3V0IGNoYW5n aW5nIHN5bnRheCBvciBzZW1hbnRpY3MuPGJyPg0KPGJyPg0KWWVzLCBidXQsIGZvciBpbnN0YW5j ZSwgdGhlICZxdW90O2luZXQ6aG9zdCZxdW90OyB0eXBlIGluIFJGQyA2OTkxIGhhcyBvdmVybGFw cGluZyBtZW1iZXJzOiAmcXVvdDsxLjIuMy40JnF1b3Q7IGlzIHZhbGlkIGFzIGJvdGggJnF1b3Q7 aW5ldDppcC1hZGRyZXNzJnF1b3Q7IGFuZCAmcXVvdDtpbmV0OmRvbWFpbi1uYW1lJnF1b3Q7Ljxi cj4NCjxicj4NCkxhZGE8YnI+DQo8YnI+DQomZ3Q7IFRoZSBleGFjdCBtZW1iZXIgdHlwZSB0aGF0 IG1hdGNoZXMgaXMgbm90IGltcG9ydGFudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgdHlwZWRlZiBmb28xIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlw ZSB1bmlvbiB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlw ZSBpbnQzMiB7IHJhbmdlICZxdW90OzEuLjEwJnF1b3Q7OyB9PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSBpbnQzMiB7IHJhbmdlICZxdW90OzExLi4yMCZx dW90OzsgfTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3R5cGVk ZWYgZm9vMiB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdW5pb24g ezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgaW50MzIg eyByYW5nZSAmcXVvdDsxMS4uMjAmcXVvdDs7IH08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB0eXBlIGludDMyIHsgcmFuZ2UgJnF1b3Q7MS4uMTAmcXVvdDs7IH08 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO308YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IExhZGE8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmR5PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZn dDsgaWYgbmV3IG1lbWJlciB0eXBlcyBjYW4gYmUgYWRkZWQgaW4gbmV3IG1vZHVsZSByZXZpc2lv bnMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElmIG5ldyBtZW1iZXIgdHlwZXMgYXJl IGFsbG93ZWQgaW4gdHlwZWRlZiBCLCB0aGVuIHRoZSByZWxhdGl2ZTxicj4NCiZndDsgJmd0OyBw b3NpdGlvbiBvZiAoNikgY2FuIGNoYW5nZSwgZXZlbiBpZiB0eXBlZGVmIEEgZG9lcyBub3QgY2hh bmdlLjxicj4NCiZndDsgJmd0OyBZQU5HIGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUgaWYgdGhp cyBpcyBhbGxvd2VkIG9yIG5vdC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgYml0cyBh bmQgZW51bWVyYXRpb25zIGNhbiBiZSBleHBhbmRlZCBpbiBuZXcgcmV2aXNpb25zLCB3aGljaDxi cj4NCiZndDsgJmd0OyBjaGFuZ2VzIHRoZSB2YWx1ZSBzZXQsIGJ1dCBleGlzdGluZyB2YWx1ZSBh bmQgcG9zaXRpb24gbnVtYmVycyBhcmU8YnI+DQomZ3Q7ICZndDsgbm90IGFsbG93ZWQgdG8gY2hh bmdlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgcHJvYmxlbWF0aWMgdGV4dCBp cyBpbiA2MDIwYmlzLCBzZWMgMTE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7byZuYnNwOyBBICZxdW90O3R5cGUmcXVvdDsgc3RhdGVtZW50IG1heSBiZSByZXBsYWNl ZCB3aXRoIGFub3RoZXIgJnF1b3Q7dHlwZSZxdW90OyBzdGF0ZW1lbnQ8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0IGRvZXMgbm90IGNoYW5nZSB0aGUgc3ludGF4 IG9yIHNlbWFudGljcyBvZiB0aGUgdHlwZS4mbmJzcDsgRm9yPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhhbXBsZSwgYW4gaW5saW5lIHR5cGUgZGVmaW5pdGlvbiBt YXkgYmUgcmVwbGFjZWQgd2l0aCBhIHR5cGVkZWYsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YnV0IGFuIGludDggdHlwZSBjYW5ub3QgYmUgcmVwbGFjZWQgYnkgYW4g aW50MTYsIHNpbmNlIHRoZSBzeW50YXg8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt3b3VsZCBjaGFuZ2UuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEluIHByYWN0aWNlIHJlb3JkZXJpbmcgbWVtYmVyIHR5 cGVzIHdvdWxkIGJlIHZlcnkgcmFyZSwgYnV0IHRoZSBTSUQ8YnI+DQomZ3Q7ICZndDsgbnVtYmVy aW5nIHdvdWxkIG5lZWQgdG8gcmVtZW1iZXIgdGhlIG1lbWJlciB0eXBlIG9yZGVyIGZvciBlYWNo IGxlYWY8YnI+DQomZ3Q7ICZndDsgb3IgbGVhZi1saXN0IHRoYXQgcmVzb2x2ZXMgdG8gYSB1bmlv biB0eXBlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJdCBkb2Vzbid0IGhlbHAgdG8g dGFnIGFueSBvdGhlciB0eXBlIGJlc2lkZXMgdW5pb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFuZHk8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgY29yZSBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5jb3JlQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+PGJyPg0KJmd0 Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnM8YnI+ DQomZ3Q7IFBHUCBLZXkgSUQ6IEU3NEU4QzBDPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJob2VuemIiPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnM8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+UEdQIEtleSBJRDogRTc0RThDMEM8L3NwYW4+PGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+Y29yZSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpj b3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR06MB2308607F33BCA0215107F345FE0D0BN6PR06MB2308namp_-- From nobody Mon Jul 25 11:51:30 2016 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 3D21212D1F0 for ; Mon, 25 Jul 2016 11:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgbcoFosKirW for ; Mon, 25 Jul 2016 11:51:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F7712B032 for ; Mon, 25 Jul 2016 11:51:25 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:fffe:289a:25dd:7b0d:ad06] (unknown [IPv6:2a01:5e0:29:fffe:289a:25dd:7b0d:ad06]) by mail.nic.cz (Postfix) with ESMTPSA id 0E29D61DCC; Mon, 25 Jul 2016 20:51:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469472684; bh=Z13CkeNAsa98fVZ7BYvGNMuwW6BD5J2RNS0YMNYUNYc=; h=From:Date:To; b=th2nXX0k02b3lT0PaRsmUlk9gqzusy1TNS6DH8d4340u1tBSITnXJXvL3s6ur/LRe BBfUm5nwaGVkjaaHHhCnTnsF7fqG+4d6ggNJnlsxmPSle+cMTJJoTn5zclBIobEpjG Gxyho9IZWnnJyUE0jVfrHeK1uw3CKGCtv/iJCS5Q= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 25 Jul 2016 20:51:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michel Veillette X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 18:51:28 -0000 > On 25 Jul 2016, at 18:05, Michel Veillette = wrote: >=20 > Hi Lada, Hi Andy >=20 > The important questions we need answer to validate the current = solution are the following. >=20 > - In a union, is it valid to define multiple enumerations which reuse = the same value(s) with a different semantic meaning? > - In a union, is it valid to define multiple bits which reuse the same = position(s) with a different semantic meaning? IMO, yes, in both cases. I am not saying that it's a good design though.=20= >=20 > In the following examples, value or position 0 means both white and = red which I believe it's invalid. I don't think so. The member types are checked in the same order as they = appear in the union's definition, and the first type for which a given = value is valid is used. > If this is the case, the currently proposed solution to tag some = specific datatype (bits, enumeration, identityref, instance-identifier) = when used in a union resolve any potential ambiguities. Yes, I think this is a good idea because otherwise resolving the member = types may be difficult. Moreover, sometimes the sending side might want = to override the resolution algorithm - e.g., if a client wants to set a = leaf with "inet:host" type to "1.2.3.4" and interpret it as a domain = name rather than IP address. =20 > Can we move ahead with the current solution? >=20 > ENUMERATION EXAMPLE >=20 > typedef A { > type union { > type enumeration { > enum white { > value 0; > } > enum black { > value 1; > } > } =20 > type enumeration { > enum red { > value 0; > } > enum green { > value 1; > } > enum blue { > value 2; > } > } =20 > } > } Values 0 and 1 are interpreted as "white" and "black", value 2 is = "blue". >=20 > BITS EXAMPLE >=20 > typedef B { > type union { > type bits { > bit white { > position 0; > } > bit black { > position 1; > } > } > type bits { > bit red { > position 0; > } > bit green { > position 1; > } > bit blue { > position 2; > } > } > } > } Ditto. Lada >=20 > Regards, > Michel >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Monday, July 25, 2016 10:41 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] fixing YANG to CBOR >=20 >=20 >> On 25 Jul 2016, at 16:21, Andy Bierman wrote: >>=20 >>=20 >>=20 >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka = wrote: >> Andy Bierman writes: >>=20 >>> Hi, >>>=20 >>> It seems to me that the only tagging actually needed would be to=20 >>> identify the ordered list of member types within a union type. >>>=20 >>>=20 >>> typedef A { >>> type union { >>> type int32 ; // 1 >>> type string; // 2 >>> type B; // 3, 4, 5 >>> type identityref { base bar; } // 6 >>> } >>> } >>>=20 >>>=20 >>> typedef B { >>> type union { >>> type uint8; >>> type uint16; >>> type uint32; >>> } >>> } >>>=20 >>> leaf foo { type A; } >>>=20 >>> YANG allows the member types to be reordered if it does not change=20= >>> the value set accepted by the type. It is not clear >>=20 >> I don't think this is true. The only statement in 6020bis that is=20 >> related to this issue is the bullet that you cite below, but IMO=20 >> reordering member types in a union type definition may change the = type=20 >> semantics because the receiving side resolves the type according to=20= >> the order of member types. >>=20 >>=20 >>=20 >> This depends on the format, but non-overlapping member types can=20 >> change position without changing syntax or semantics. >=20 > Yes, but, for instance, the "inet:host" type in RFC 6991 has = overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and = "inet:domain-name". >=20 > Lada >=20 >> The exact member type that matches is not important. >>=20 >> typedef foo1 { >> type union { >> type int32 { range "1..10"; } >> type int32 { range "11..20"; } >> } >> } >>=20 >> typedef foo2 { >> type union { >> type int32 { range "11..20"; } >> type int32 { range "1..10"; } >> } >> } >>=20 >>=20 >>=20 >> Lada >>=20 >> Andy >>=20 >>=20 >>> if new member types can be added in new module revisions. >>>=20 >>> If new member types are allowed in typedef B, then the relative=20 >>> position of (6) can change, even if typedef A does not change. >>> YANG does not explicitly state if this is allowed or not. >>>=20 >>> bits and enumerations can be expanded in new revisions, which=20 >>> changes the value set, but existing value and position numbers are=20= >>> not allowed to change. >>>=20 >>> The problematic text is in 6020bis, sec 11 >>>=20 >>> o A "type" statement may be replaced with another "type" statement >>> that does not change the syntax or semantics of the type. For >>> example, an inline type definition may be replaced with a = typedef, >>> but an int8 type cannot be replaced by an int16, since the = syntax >>> would change. >>>=20 >>>=20 >>>=20 >>> In practice reordering member types would be very rare, but the SID=20= >>> numbering would need to remember the member type order for each leaf=20= >>> or leaf-list that resolves to a union type. >>>=20 >>> It doesn't help to tag any other type besides union. >>>=20 >>>=20 >>> Andy >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 12:08:17 2016 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 E39F412D9C8 for ; Mon, 25 Jul 2016 12:08:15 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZsR1qIxo_3S for ; Mon, 25 Jul 2016 12:08:14 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 4800E12DA1D for ; Mon, 25 Jul 2016 12:00:41 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id x130so257022428vkc.0 for ; Mon, 25 Jul 2016 12:00:41 -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=8rsnhI1RHyJg7xSRfmithiCBJmHxXJ+Xy+KVD2uHUSo=; b=lYs7Jvs7/UCkO59kCmHkqGopmj8KA2+TiRyTCD/LPfAc8sqn0sURYM3loTy6mhg0My ftJxslKEV3y4r1jl/zhPWIC21aJF17D8H3Kog5gd01+Xwn8pZVvvKgOMypQaOnnIP3dQ +m5MtxHLmt/BuK+3PTyltv1jyqK6F5vqooZt8ozME7ZZ3Xe0vsFx368s65U4AduY4TT5 FQm+x6xXSZwX433qUHO/EgiOekTKXSo7mUmq214a+YM3j84b79V2Plmtu2vyZ1GVgJWf ceJCOvfGkQhsXdPXa9wwwRtH4GVAzVhgFXh7YNZzMsnH9yOI7PN2KkhS7coGU6JidnJg 21bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8rsnhI1RHyJg7xSRfmithiCBJmHxXJ+Xy+KVD2uHUSo=; b=ViOI5GxqdhwHjfMPYoSgHz11NW4NB8r0M8y5MxRelqaX9NovLyiHT8N7vXiie1AevR 4v55PATdBCmnC2V88ld5nA/DdGf4aE2FUpmqcCB2tSC64iSoVWWYT8AVGqzfNaAnFfEQ XuXovRQxFnn/eXIerV1pOA2AHjmA8t+2j+hRXpUTYHIEcYZM/ldTU0V2Kl1gmb15lX6B 8uabF87t8VTqjuF0Xy3mLkQecOBe0J0Glo19UyOnqWrTGS578eV10MKuXWhmI8uuCVLC /enpxvWkR6mFsXxbwWKLQhWtbWBlGt0avSdfk82hh8V88UGBTpdL/HVYRGpjdMrKNRsu FFHQ== X-Gm-Message-State: AEkoousrXzBj+2lXyJaCY4thJSLvkkhE+06mswTqMZt4wQLBBwpTjg9mXXZElt0vBPV35qbV2LZ+d90wE9iHng== X-Received: by 10.176.69.210 with SMTP id u76mr7591133uau.16.1469473240360; Mon, 25 Jul 2016 12:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 25 Jul 2016 12:00:39 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Mon, 25 Jul 2016 12:00:39 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c11c3047fdf2f05387a6696 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 19:08:16 -0000 --94eb2c11c3047fdf2f05387a6696 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka wrote: > > > On 25 Jul 2016, at 18:05, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > > > Hi Lada, Hi Andy > > > > The important questions we need answer to validate the current solution > are the following. > > > > - In a union, is it valid to define multiple enumerations which reuse > the same value(s) with a different semantic meaning? > > - In a union, is it valid to define multiple bits which reuse the same > position(s) with a different semantic meaning? > > IMO, yes, in both cases. I am not saying that it's a good design though. > > > > > In the following examples, value or position 0 means both white and red > which I believe it's invalid. > > I don't think so. The member types are checked in the same order as they > appear in the union's definition, and the first type for which a given > value is valid is used. > > That's the issue here. The member type value spaces are allowed to overlap each other. The "first wins" depends on the value being sent. The same problem exists for JSON for boolean and numeric types. Only XML passes everything as a string. YANG union was designed only to work robustly with XML. > If this is the case, the currently proposed solution to tag some specific > datatype (bits, enumeration, identityref, instance-identifier) when used > in a union resolve any potential ambiguities. > > Yes, I think this is a good idea because otherwise resolving the member > types may be difficult. Moreover, sometimes the sending side might want to > override the resolution algorithm - e.g., if a client wants to set a leaf > with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather > than IP address. > > > Can we move ahead with the current solution? > The current solution is just as good and just as broken as the JSON solution, and we already moved ahead with that in NETMOD WG. (So I guess that means yes?) Andy > > > > ENUMERATION EXAMPLE > > > > typedef A { > > type union { > > type enumeration { > > enum white { > > value 0; > > } > > enum black { > > value 1; > > } > > } > > type enumeration { > > enum red { > > value 0; > > } > > enum green { > > value 1; > > } > > enum blue { > > value 2; > > } > > } > > } > > } > > Values 0 and 1 are interpreted as "white" and "black", value 2 is "blue". > > > > > BITS EXAMPLE > > > > typedef B { > > type union { > > type bits { > > bit white { > > position 0; > > } > > bit black { > > position 1; > > } > > } > > type bits { > > bit red { > > position 0; > > } > > bit green { > > position 1; > > } > > bit blue { > > position 2; > > } > > } > > } > > } > > Ditto. > > Lada > > > > > Regards, > > Michel > > > > -----Original Message----- > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > > Sent: Monday, July 25, 2016 10:41 AM > > To: Andy Bierman > > Cc: Core > > Subject: Re: [core] fixing YANG to CBOR > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman wrote: > >> > >> > >> > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: > >> > >>> Hi, > >>> > >>> It seems to me that the only tagging actually needed would be to > >>> identify the ordered list of member types within a union type. > >>> > >>> > >>> typedef A { > >>> type union { > >>> type int32 ; // 1 > >>> type string; // 2 > >>> type B; // 3, 4, 5 > >>> type identityref { base bar; } // 6 > >>> } > >>> } > >>> > >>> > >>> typedef B { > >>> type union { > >>> type uint8; > >>> type uint16; > >>> type uint32; > >>> } > >>> } > >>> > >>> leaf foo { type A; } > >>> > >>> YANG allows the member types to be reordered if it does not change > >>> the value set accepted by the type. It is not clear > >> > >> I don't think this is true. The only statement in 6020bis that is > >> related to this issue is the bullet that you cite below, but IMO > >> reordering member types in a union type definition may change the type > >> semantics because the receiving side resolves the type according to > >> the order of member types. > >> > >> > >> > >> This depends on the format, but non-overlapping member types can > >> change position without changing syntax or semantics. > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping > members: "1.2.3.4" is valid as both "inet:ip-address" and > "inet:domain-name". > > > > Lada > > > >> The exact member type that matches is not important. > >> > >> typedef foo1 { > >> type union { > >> type int32 { range "1..10"; } > >> type int32 { range "11..20"; } > >> } > >> } > >> > >> typedef foo2 { > >> type union { > >> type int32 { range "11..20"; } > >> type int32 { range "1..10"; } > >> } > >> } > >> > >> > >> > >> Lada > >> > >> Andy > >> > >> > >>> if new member types can be added in new module revisions. > >>> > >>> If new member types are allowed in typedef B, then the relative > >>> position of (6) can change, even if typedef A does not change. > >>> YANG does not explicitly state if this is allowed or not. > >>> > >>> bits and enumerations can be expanded in new revisions, which > >>> changes the value set, but existing value and position numbers are > >>> not allowed to change. > >>> > >>> The problematic text is in 6020bis, sec 11 > >>> > >>> o A "type" statement may be replaced with another "type" statement > >>> that does not change the syntax or semantics of the type. For > >>> example, an inline type definition may be replaced with a typedef, > >>> but an int8 type cannot be replaced by an int16, since the syntax > >>> would change. > >>> > >>> > >>> > >>> In practice reordering member types would be very rare, but the SID > >>> numbering would need to remember the member type order for each leaf > >>> or leaf-list that resolves to a union type. > >>> > >>> It doesn't help to tag any other type besides union. > >>> > >>> > >>> Andy > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> https://www.ietf.org/mailman/listinfo/core > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --94eb2c11c3047fdf2f05387a6696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 25 Jul 2016, at 18:05, Michel Veillette <Michel.Veillette@trilliantinc.com> wro= te:
>
> Hi Lada, Hi Andy
>
> The important questions we need answer to validate the current solutio= n are the following.
>
> - In a union, is it valid to define multiple enumerations which reuse = the same value(s) with a different semantic meaning?
> - In a union, is it valid to define multiple bits which reuse the same= position(s) with a different semantic meaning?

IMO, yes, in both cases. I am not saying that it's a good design though= .

>
> In the following examples, value or position 0 means both white and re= d which I believe it's invalid.

I don't think so. The member types are checked in the same order as the= y appear in the union's definition, and the first type for which a give= n value is valid is used.



That's the issue he= re.
The member type value spaces are allowed to overlap each othe= r.
The "first wins" depends on the value being sent.
The same problem exists for JSON for boolean and numeric types.
Only XML passes everything as a string.=C2=A0 YANG union was designe= d only to work
robustly with XML.


> If this is the case, the currently proposed solution to tag some speci= fic datatype (bits,=C2=A0 enumeration, identityref, instance-identifier) wh= en used in a union resolve any potential ambiguities.

Yes, I think this is a good idea because otherwise resolving the member typ= es may be difficult. Moreover, sometimes the sending side might want to ove= rride the resolution algorithm - e.g., if a client wants to set a leaf with= "inet:host" type to "1.2.3.4" and interpret it as a do= main name rather than IP address.

> Can we move ahead with the current solution?

=
The current solution is just as good and just as broken as the J= SON solution,
and we already moved ahead with that in NETMOD WG. = (So I guess that means yes?)


Andy
=C2=A0
>
> ENUMERATION EXAMPLE
>
> typedef A {
>=C2=A0 type union {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum white {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 enum black {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 enum green {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 enum blue {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>=C2=A0 }
> }

Values 0 and 1 are interpreted as "white" and "black", = value 2 is "blue".

>
> BITS EXAMPLE
>
> typedef B {
>=C2=A0 type union {
>=C2=A0 =C2=A0 type bits {
>=C2=A0 =C2=A0 =C2=A0 bit white {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 bit black {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 type bits {
>=C2=A0 =C2=A0 =C2=A0 bit red {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 bit green {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 bit blue {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 2;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>=C2=A0 }
> }

Ditto.

Lada

>
> Regards,
> Michel
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Ladislav Lhotka
> Sent: Monday, July 25, 2016 10:41 AM
> To: Andy Bierman <andy@yumawo= rks.com>
> Cc: Core <core@ietf.org> > Subject: Re: [core] fixing YANG to CBOR
>
>
>> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
>>
>>
>>
>> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>>> Hi,
>>>
>>> It seems to me that the only tagging actually needed would be = to
>>> identify the ordered list of member types within a union type.=
>>>
>>>
>>> typedef A {
>>>=C2=A0 type union {
>>>=C2=A0 =C2=A0 type int32 ;=C2=A0 =C2=A0// 1
>>>=C2=A0 =C2=A0 type string; // 2
>>>=C2=A0 =C2=A0 type B;=C2=A0 =C2=A0// 3, 4, 5
>>>=C2=A0 =C2=A0 type identityref { base bar; }=C2=A0 =C2=A0// 6 >>>=C2=A0 }
>>> }
>>>
>>>
>>> typedef B {
>>>=C2=A0 type union {
>>>=C2=A0 =C2=A0 type uint8;
>>>=C2=A0 =C2=A0 type uint16;
>>>=C2=A0 =C2=A0 type uint32;
>>>=C2=A0 }
>>> }
>>>
>>> leaf foo { type A; }
>>>
>>> YANG allows the member types to be reordered if it does not ch= ange
>>> the value set accepted by the type.=C2=A0 It is not clear
>>
>> I don't think this is true. The only statement in 6020bis that= is
>> related to this issue is the bullet that you cite below, but IMO >> reordering member types in a union type definition may change the = type
>> semantics because the receiving side resolves the type according t= o
>> the order of member types.
>>
>>
>>
>> This depends on the format, but non-overlapping member types can >> change position without changing syntax or semantics.
>
> Yes, but, for instance, the "inet:host" type in RFC 6991 has= overlapping members: "1.2.3.4" is valid as both "inet:ip-ad= dress" and "inet:domain-name".
>
> Lada
>
>> The exact member type that matches is not important.
>>
>>=C2=A0 =C2=A0typedef foo1 {
>>=C2=A0 =C2=A0 =C2=A0 type union {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "1..10&qu= ot;; }
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "11..20&q= uot;; }
>>=C2=A0 =C2=A0 =C2=A0 }
>>=C2=A0 =C2=A0 }
>>
>>=C2=A0 typedef foo2 {
>>=C2=A0 =C2=A0 =C2=A0 type union {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "11..20&q= uot;; }
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "1..10&qu= ot;; }
>>=C2=A0 =C2=A0 =C2=A0 }
>>=C2=A0 =C2=A0 }
>>
>>
>>
>> Lada
>>
>> Andy
>>
>>
>>> if new member types can be added in new module revisions.
>>>
>>> If new member types are allowed in typedef B, then the relativ= e
>>> position of (6) can change, even if typedef A does not change.=
>>> YANG does not explicitly state if this is allowed or not.
>>>
>>> bits and enumerations can be expanded in new revisions, which<= br> >>> changes the value set, but existing value and position numbers= are
>>> not allowed to change.
>>>
>>> The problematic text is in 6020bis, sec 11
>>>
>>>=C2=A0 o=C2=A0 A "type" statement may be replaced wit= h another "type" statement
>>>=C2=A0 =C2=A0 =C2=A0 that does not change the syntax or semanti= cs of the type.=C2=A0 For
>>>=C2=A0 =C2=A0 =C2=A0 example, an inline type definition may be = replaced with a typedef,
>>>=C2=A0 =C2=A0 =C2=A0 but an int8 type cannot be replaced by an = int16, since the syntax
>>>=C2=A0 =C2=A0 =C2=A0 would change.
>>>
>>>
>>>
>>> In practice reordering member types would be very rare, but th= e SID
>>> numbering would need to remember the member type order for eac= h leaf
>>> or leaf-list that resolves to a union type.
>>>
>>> It doesn't help to tag any other type besides union.
>>>
>>>
>>> Andy
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--94eb2c11c3047fdf2f05387a6696-- From nobody Mon Jul 25 12:12:31 2016 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 5AEAC12D94B for ; Mon, 25 Jul 2016 12:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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] 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 ejaots-vBC9H for ; Mon, 25 Jul 2016 12:12:28 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3965612D595 for ; Mon, 25 Jul 2016 12:12:28 -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=rqvtkfloJxTQkGHOUSJKeka3fOYKUz65LpdKbOPgnVU=; b=C6tURn8BNc66If/XyQmjeyP0SCWqerHX2Wub8cdo4Ge63vp5RdDScqkHETKUpPsrsZtvXfHI9B69PjSIVBEbsB/R7sVgjM5eDns8qcVdFxGV+5xCWMXTup3yYTgOKy0e19uOOVYj0rYd1ENslCyKtNzT+/nOHZD857GTlKnl3L8= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 19:12:25 +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.0544.014; Mon, 25 Jul 2016 19:12:25 +0000 From: Michel Veillette To: Ladislav Lhotka Thread-Topic: [core] fixing YANG to CBOR Thread-Index: AQHR4+cJQt79bN4pMU+XasZI/tqalKApIRsAgAAW5YCAAAVwAIAAEGZQgAA1fwCAAAGbwA== Date: Mon, 25 Jul 2016 19:12:24 +0000 Message-ID: References: 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: [207.96.192.122] x-ms-office365-filtering-correlation-id: 0bb2fe5b-e21e-4aa3-f03e-08d3b4bf9cd3 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:MHnWrrhOmyyK9E0UGA3UHiz6x9yBc0G6psiPSxGYqbNsBf8pW+KyYddMaTbD/ebYjbIxQGHEEt9/05sa885Jmx12J+SQMCO+fMlssVjKao1Kxgti3rB0sFo3499Oxr56so1VkYQGKqRiMx98ofRI/Pe+JUGLh4XnSq0YOMriKnDpquL30r1tqscKrg+3OOJMWvt1ITzyeusmAVxwcUSqkf9tKuuDM67W9luz86Js28oUxs/1ac6ZgikvJm53t6Xm/BAoC14TmMcaHwuroCHI2V/dlMfi86QEJADIGMG5Fdo=; 5:ZWLsUe0gGaat1p8QhA0jIeJW/WYusocZQIcRzGiQncHZVgWGhI/qYoy6B/iHUUehm0obO90oV0l182/qWrnygOq1IcVl2xjmr0cXvDgssT/KwQ+59/7dL58Jjwsxl9X4YbL2vjHyIUqD6dqvDALQkw==; 24:yWt4fqjpgxSpOUgs1xnx3imkXKXFB/DXYZ43MnokwujvD+RckSoiaIK8/6zHYP/kDdv6xEVH5ive2x9VRkYj3JsT/NlUfSgJJ7pCRBUnzUA=; 7:rEQKD+GHdGmr54QJMjJSsGEnBk0k2OcNv44FEUAf0+TUhCe/P+bTrdFhu/Fe63+o/ZHox2u9Kz5CN2Xkhl3ysbqEbEjoglzUQXHWJcmNsp+n2cYeT8QZqogTOfmvyGo6ng+s0lN5r5kDG5SQdEndG42vmMFiwtUokse6nhRSIdyZM1+L5pIO7OIATnoLx4Y85wWATTpuV1CqfAZlZafNYTDi0fxOXO9P1UzlqUMMea6h54ql7+FzMTN0EEW/y9ZS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(189002)(13464003)(199003)(3846002)(102836003)(9686002)(6116002)(68736007)(8676002)(106356001)(76576001)(50986999)(76176999)(8936002)(11100500001)(54356999)(92566002)(2900100001)(33656002)(99286002)(77096005)(15975445007)(93886004)(2950100001)(2906002)(189998001)(586003)(110136002)(4326007)(97736004)(106116001)(101416001)(3660700001)(10400500002)(7696003)(305945005)(7736002)(5003600100003)(7846002)(3280700002)(105586002)(87936001)(19580405001)(19580395003)(66066001)(575784001)(86362001)(81156014)(81166006)(122556002)(5002640100001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.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: 25 Jul 2016 19:12:24.8377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 19:12:30 -0000 Hi Lada In your answer " Yes, I think this is a good idea...", you seem to assume t= hat union member are tagged, not datatype. See below for an example of both approaches. We basically need to select one of these. # UNION MEMBER TAGGING typedef A { type union { type identityref { <=3D=3D=3D=3D=3D=3D TAG member 1 (e..g. tag 40) base "X:Y"; } type enumeration { <=3D=3D=3D=3D=3D=3D TAG member 2 (e..g. tag 41) enum white { value 0; } enum black { value 1; } }=20 type enumeration { <=3D=3D=3D=3D=3D=3D TAG member 3 (e..g. tag 42) enum red { value 0; } enum blue { value 1; } } =20 } } PROS, completely remove any ambiguities. CONS, not backward compatible between module revisions if the order change = or new members are inserted. # DATATYPE TAGGING typedef A { type union { type identityref { <=3D=3D=3D=3D=3D=3D TAG identityref (e..g. tag 4= 0) base "X:Y"; } type enumeration { <=3D=3D=3D=3D=3D=3D TAG enumeration (e..g. tag 4= 1) enum white { value 0; } enum black { value 1; } }=20 type enumeration { <=3D=3D=3D=3D=3D=3D TAG enumeration (e..g. tag 4= 1) enum red { value 0; } enum blue { value 1; } } =20 } } PROS, backward compatible between module versions CONS, ambiguities may still exists for multiple use of enumeration or bits = in the same union. Regards, Michel -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Monday, July 25, 2016 2:52 PM To: Michel Veillette Cc: Andy Bierman ; Core Subject: Re: [core] fixing YANG to CBOR > On 25 Jul 2016, at 18:05, Michel Veillette wrote: >=20 > Hi Lada, Hi Andy >=20 > The important questions we need answer to validate the current solution a= re the following. >=20 > - In a union, is it valid to define multiple enumerations which reuse the= same value(s) with a different semantic meaning? > - In a union, is it valid to define multiple bits which reuse the same po= sition(s) with a different semantic meaning? IMO, yes, in both cases. I am not saying that it's a good design though.=20 >=20 > In the following examples, value or position 0 means both white and red w= hich I believe it's invalid. I don't think so. The member types are checked in the same order as they ap= pear in the union's definition, and the first type for which a given value = is valid is used. > If this is the case, the currently proposed solution to tag some specific= datatype (bits, enumeration, identityref, instance-identifier) when used = in a union resolve any potential ambiguities. Yes, I think this is a good idea because otherwise resolving the member typ= es may be difficult. Moreover, sometimes the sending side might want to ove= rride the resolution algorithm - e.g., if a client wants to set a leaf with= "inet:host" type to "1.2.3.4" and interpret it as a domain name rather tha= n IP address. =20 > Can we move ahead with the current solution? >=20 > ENUMERATION EXAMPLE >=20 > typedef A { > type union { > type enumeration { > enum white { > value 0; > } > enum black { > value 1; > } > } =20 > type enumeration { > enum red { > value 0; > } > enum green { > value 1; > } > enum blue { > value 2; > } > } =20 > } > } Values 0 and 1 are interpreted as "white" and "black", value 2 is "blue". >=20 > BITS EXAMPLE >=20 > typedef B { > type union { > type bits { > bit white { > position 0; > } > bit black { > position 1; > } > } > type bits { > bit red { > position 0; > } > bit green { > position 1; > } > bit blue { > position 2; > } > } > } > } Ditto. Lada >=20 > Regards, > Michel >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Monday, July 25, 2016 10:41 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] fixing YANG to CBOR >=20 >=20 >> On 25 Jul 2016, at 16:21, Andy Bierman wrote: >>=20 >>=20 >>=20 >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> Hi, >>>=20 >>> It seems to me that the only tagging actually needed would be to=20 >>> identify the ordered list of member types within a union type. >>>=20 >>>=20 >>> typedef A { >>> type union { >>> type int32 ; // 1 >>> type string; // 2 >>> type B; // 3, 4, 5 >>> type identityref { base bar; } // 6 >>> } >>> } >>>=20 >>>=20 >>> typedef B { >>> type union { >>> type uint8; >>> type uint16; >>> type uint32; >>> } >>> } >>>=20 >>> leaf foo { type A; } >>>=20 >>> YANG allows the member types to be reordered if it does not change=20 >>> the value set accepted by the type. It is not clear >>=20 >> I don't think this is true. The only statement in 6020bis that is=20 >> related to this issue is the bullet that you cite below, but IMO=20 >> reordering member types in a union type definition may change the=20 >> type semantics because the receiving side resolves the type according=20 >> to the order of member types. >>=20 >>=20 >>=20 >> This depends on the format, but non-overlapping member types can=20 >> change position without changing syntax or semantics. >=20 > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping = members: "1.2.3.4" is valid as both "inet:ip-address" and "inet:domain-name= ". >=20 > Lada >=20 >> The exact member type that matches is not important. >>=20 >> typedef foo1 { >> type union { >> type int32 { range "1..10"; } >> type int32 { range "11..20"; } >> } >> } >>=20 >> typedef foo2 { >> type union { >> type int32 { range "11..20"; } >> type int32 { range "1..10"; } >> } >> } >>=20 >>=20 >>=20 >> Lada >>=20 >> Andy >>=20 >>=20 >>> if new member types can be added in new module revisions. >>>=20 >>> If new member types are allowed in typedef B, then the relative=20 >>> position of (6) can change, even if typedef A does not change. >>> YANG does not explicitly state if this is allowed or not. >>>=20 >>> bits and enumerations can be expanded in new revisions, which=20 >>> changes the value set, but existing value and position numbers are=20 >>> not allowed to change. >>>=20 >>> The problematic text is in 6020bis, sec 11 >>>=20 >>> o A "type" statement may be replaced with another "type" statement >>> that does not change the syntax or semantics of the type. For >>> example, an inline type definition may be replaced with a typedef, >>> but an int8 type cannot be replaced by an int16, since the syntax >>> would change. >>>=20 >>>=20 >>>=20 >>> In practice reordering member types would be very rare, but the SID=20 >>> numbering would need to remember the member type order for each leaf=20 >>> or leaf-list that resolves to a union type. >>>=20 >>> It doesn't help to tag any other type besides union. >>>=20 >>>=20 >>> Andy >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 13:17:40 2016 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 C536412D9D4 for ; Mon, 25 Jul 2016 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUBcXDEG__xd for ; Mon, 25 Jul 2016 13:17:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EAA12D5C9 for ; Mon, 25 Jul 2016 13:17:36 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:fffe:289a:25dd:7b0d:ad06] (unknown [IPv6:2a01:5e0:29:fffe:289a:25dd:7b0d:ad06]) by mail.nic.cz (Postfix) with ESMTPSA id E2B46611BB; Mon, 25 Jul 2016 22:17:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469477855; bh=U4tPnaSj9BqKQpXYG+z765SnuQm8cLlQD/wj/ZPX/Sk=; h=From:Date:To; b=mpx4NRHEJnsFV7V7UqiApxyermDvVU9WTxLncJEQ6QCpvJjGSlUsQz+QVHxaV8gyN gPuV5v6Ws8c6wYBYg5mwHAmg9Ja53O5O/3cNusQV5KVNImH8nCUJI650cDCGO2/CZ6 oxxXx4ow0Em1mu1DrlGKYKzE9LHqBt+c39RnlIH8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 25 Jul 2016 22:17:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 20:17:39 -0000 > On 25 Jul 2016, at 21:00, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka = wrote: >=20 > > On 25 Jul 2016, at 18:05, Michel Veillette = wrote: > > > > Hi Lada, Hi Andy > > > > The important questions we need answer to validate the current = solution are the following. > > > > - In a union, is it valid to define multiple enumerations which = reuse the same value(s) with a different semantic meaning? > > - In a union, is it valid to define multiple bits which reuse the = same position(s) with a different semantic meaning? >=20 > IMO, yes, in both cases. I am not saying that it's a good design = though. >=20 > > > > In the following examples, value or position 0 means both white and = red which I believe it's invalid. >=20 > I don't think so. The member types are checked in the same order as = they appear in the union's definition, and the first type for which a = given value is valid is used. >=20 >=20 >=20 > That's the issue here. > The member type value spaces are allowed to overlap each other. > The "first wins" depends on the value being sent. > The same problem exists for JSON for boolean and numeric types. > Only XML passes everything as a string. YANG union was designed only = to work > robustly with XML. I believe for JSON it is perfectly robust. The general rule should be = this: use whatever information you have to determine whether the = received value is valid for the first member type. If not, try the = second member etc. Lada >=20 >=20 > > If this is the case, the currently proposed solution to tag some = specific datatype (bits, enumeration, identityref, instance-identifier) = when used in a union resolve any potential ambiguities. >=20 > Yes, I think this is a good idea because otherwise resolving the = member types may be difficult. Moreover, sometimes the sending side = might want to override the resolution algorithm - e.g., if a client = wants to set a leaf with "inet:host" type to "1.2.3.4" and interpret it = as a domain name rather than IP address. >=20 > > Can we move ahead with the current solution? >=20 > The current solution is just as good and just as broken as the JSON = solution, > and we already moved ahead with that in NETMOD WG. (So I guess that = means yes?) >=20 >=20 > Andy > =20 > > > > ENUMERATION EXAMPLE > > > > typedef A { > > type union { > > type enumeration { > > enum white { > > value 0; > > } > > enum black { > > value 1; > > } > > } > > type enumeration { > > enum red { > > value 0; > > } > > enum green { > > value 1; > > } > > enum blue { > > value 2; > > } > > } > > } > > } >=20 > Values 0 and 1 are interpreted as "white" and "black", value 2 is = "blue". >=20 > > > > BITS EXAMPLE > > > > typedef B { > > type union { > > type bits { > > bit white { > > position 0; > > } > > bit black { > > position 1; > > } > > } > > type bits { > > bit red { > > position 0; > > } > > bit green { > > position 1; > > } > > bit blue { > > position 2; > > } > > } > > } > > } >=20 > Ditto. >=20 > Lada >=20 > > > > Regards, > > Michel > > > > -----Original Message----- > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav = Lhotka > > Sent: Monday, July 25, 2016 10:41 AM > > To: Andy Bierman > > Cc: Core > > Subject: Re: [core] fixing YANG to CBOR > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman wrote: > >> > >> > >> > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka = wrote: > >> Andy Bierman writes: > >> > >>> Hi, > >>> > >>> It seems to me that the only tagging actually needed would be to > >>> identify the ordered list of member types within a union type. > >>> > >>> > >>> typedef A { > >>> type union { > >>> type int32 ; // 1 > >>> type string; // 2 > >>> type B; // 3, 4, 5 > >>> type identityref { base bar; } // 6 > >>> } > >>> } > >>> > >>> > >>> typedef B { > >>> type union { > >>> type uint8; > >>> type uint16; > >>> type uint32; > >>> } > >>> } > >>> > >>> leaf foo { type A; } > >>> > >>> YANG allows the member types to be reordered if it does not change > >>> the value set accepted by the type. It is not clear > >> > >> I don't think this is true. The only statement in 6020bis that is > >> related to this issue is the bullet that you cite below, but IMO > >> reordering member types in a union type definition may change the = type > >> semantics because the receiving side resolves the type according to > >> the order of member types. > >> > >> > >> > >> This depends on the format, but non-overlapping member types can > >> change position without changing syntax or semantics. > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has = overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and = "inet:domain-name". > > > > Lada > > > >> The exact member type that matches is not important. > >> > >> typedef foo1 { > >> type union { > >> type int32 { range "1..10"; } > >> type int32 { range "11..20"; } > >> } > >> } > >> > >> typedef foo2 { > >> type union { > >> type int32 { range "11..20"; } > >> type int32 { range "1..10"; } > >> } > >> } > >> > >> > >> > >> Lada > >> > >> Andy > >> > >> > >>> if new member types can be added in new module revisions. > >>> > >>> If new member types are allowed in typedef B, then the relative > >>> position of (6) can change, even if typedef A does not change. > >>> YANG does not explicitly state if this is allowed or not. > >>> > >>> bits and enumerations can be expanded in new revisions, which > >>> changes the value set, but existing value and position numbers are > >>> not allowed to change. > >>> > >>> The problematic text is in 6020bis, sec 11 > >>> > >>> o A "type" statement may be replaced with another "type" = statement > >>> that does not change the syntax or semantics of the type. = For > >>> example, an inline type definition may be replaced with a = typedef, > >>> but an int8 type cannot be replaced by an int16, since the = syntax > >>> would change. > >>> > >>> > >>> > >>> In practice reordering member types would be very rare, but the = SID > >>> numbering would need to remember the member type order for each = leaf > >>> or leaf-list that resolves to a union type. > >>> > >>> It doesn't help to tag any other type besides union. > >>> > >>> > >>> Andy > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> https://www.ietf.org/mailman/listinfo/core > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 13:21:34 2016 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 C1D9A12D9F1 for ; Mon, 25 Jul 2016 13:21:33 -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 R_fSL5eV9DMx for ; Mon, 25 Jul 2016 13:21:31 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 1C9EC12D9EE for ; Mon, 25 Jul 2016 13:21:31 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 52so104925396qtq.3 for ; Mon, 25 Jul 2016 13:21:31 -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=VO/DaSDrQzMz9c/ur+AuwY6YXGFIhsHg4dWS3a1LHnY=; b=AdY22By/+kd+UCEMjGCUVVzvpoVNOR8cXqhEw2DRNDZZJwKhjDqJcfemZH2WKcpWQP RtofaMAsCY1LE1odmp7nOoIQLtSuq7zyPh01l2yZonxrHiWVTJKXyYuRolylXnhJVehF tAHh7D1LOv2cxjijrwvKIc980EzwIynOATPMJdO9pSdWGlmnGCkB0YFVjIjzPjyfFfnD WhPR4XoaKQSTmnMAxXiZ6Ju1WOJQKwaZWotNVRfkm1uJG5IjP42JP1AYfOdLMNHYeVAf NCbhd5Pekcc8liIRN7LXc7gsa2uZFG7dIXJaQjTyDCE/A1oGbchiCpBxhSMypJFzXMMP ZLpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VO/DaSDrQzMz9c/ur+AuwY6YXGFIhsHg4dWS3a1LHnY=; b=HM2CLLohgqTExgzSzlvQZHyGImqbd4lhgVJWkCN0cs8Xf7fEgbRndL54cXZDYD1fiz XOsHZwBYmz7cmR5CRLXJtW30CtYOihs1NUmjp/HOCwRknUiS+dLz5dp7CoiyLEdkdSYB /08ewCKXNIYYOIUD6bawyuaQDLGP8gnawWNqJA+b/QEbVh3BPwVYfK1T6IMLfTshHOH2 Wb5arTs30PQepKlIxUgXO/gAQS9VO37O+PKf2vQ7blyC+lT6hZYWV5P9DjTN7pGN2cYH OopNeckS8NRkcJg/ZVQqIYY5kS4x0FBo1gfez8wit+DyyA+4nZ0/odeTYRBMsnbMBa18 uLSg== X-Gm-Message-State: AEkoouuNv0HR9naKFEBf0daHFxej1qwFE2YMFBg6KvX7XHsuW6lML08O65ETjMpIoFRVR9hInpDjTxBPnnjUHQ== X-Received: by 10.159.36.205 with SMTP id 71mr9334311uar.121.1469478090096; Mon, 25 Jul 2016 13:21:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 25 Jul 2016 13:21:29 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Mon, 25 Jul 2016 13:21:29 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113e5dde914a4c05387b87cd Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 20:21:34 -0000 --001a113e5dde914a4c05387b87cd Content-Type: text/plain; charset=UTF-8 On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka wrote: > > > On 25 Jul 2016, at 21:00, Andy Bierman wrote: > > > > > > > > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka wrote: > > > > > On 25 Jul 2016, at 18:05, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > > > > > Hi Lada, Hi Andy > > > > > > The important questions we need answer to validate the current > solution are the following. > > > > > > - In a union, is it valid to define multiple enumerations which reuse > the same value(s) with a different semantic meaning? > > > - In a union, is it valid to define multiple bits which reuse the same > position(s) with a different semantic meaning? > > > > IMO, yes, in both cases. I am not saying that it's a good design though. > > > > > > > > In the following examples, value or position 0 means both white and > red which I believe it's invalid. > > > > I don't think so. The member types are checked in the same order as they > appear in the union's definition, and the first type for which a given > value is valid is used. > > > > > > > > That's the issue here. > > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent. > > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string. YANG union was designed only to > work > > robustly with XML. > > I believe for JSON it is perfectly robust. The general rule should be > this: use whatever information you have to determine whether the received > value is valid for the first member type. If not, try the second member etc. > > believe what youi want: type union { type string; type int32; } JSON produces different results than XML. If client A sets number 42 in JSON, then client B will read back string "42" in XML. If the XML client sets string "42", the JSON client will read back string "42". This is the exact same issue facing CBOR conversion > Lada > > Andy > > > > > > > If this is the case, the currently proposed solution to tag some > specific datatype (bits, enumeration, identityref, instance-identifier) > when used in a union resolve any potential ambiguities. > > > > Yes, I think this is a good idea because otherwise resolving the member > types may be difficult. Moreover, sometimes the sending side might want to > override the resolution algorithm - e.g., if a client wants to set a leaf > with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather > than IP address. > > > > > Can we move ahead with the current solution? > > > > The current solution is just as good and just as broken as the JSON > solution, > > and we already moved ahead with that in NETMOD WG. (So I guess that > means yes?) > > > > > > Andy > > > > > > > > ENUMERATION EXAMPLE > > > > > > typedef A { > > > type union { > > > type enumeration { > > > enum white { > > > value 0; > > > } > > > enum black { > > > value 1; > > > } > > > } > > > type enumeration { > > > enum red { > > > value 0; > > > } > > > enum green { > > > value 1; > > > } > > > enum blue { > > > value 2; > > > } > > > } > > > } > > > } > > > > Values 0 and 1 are interpreted as "white" and "black", value 2 is "blue". > > > > > > > > BITS EXAMPLE > > > > > > typedef B { > > > type union { > > > type bits { > > > bit white { > > > position 0; > > > } > > > bit black { > > > position 1; > > > } > > > } > > > type bits { > > > bit red { > > > position 0; > > > } > > > bit green { > > > position 1; > > > } > > > bit blue { > > > position 2; > > > } > > > } > > > } > > > } > > > > Ditto. > > > > Lada > > > > > > > > Regards, > > > Michel > > > > > > -----Original Message----- > > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > > > Sent: Monday, July 25, 2016 10:41 AM > > > To: Andy Bierman > > > Cc: Core > > > Subject: Re: [core] fixing YANG to CBOR > > > > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman wrote: > > >> > > >> > > >> > > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka > wrote: > > >> Andy Bierman writes: > > >> > > >>> Hi, > > >>> > > >>> It seems to me that the only tagging actually needed would be to > > >>> identify the ordered list of member types within a union type. > > >>> > > >>> > > >>> typedef A { > > >>> type union { > > >>> type int32 ; // 1 > > >>> type string; // 2 > > >>> type B; // 3, 4, 5 > > >>> type identityref { base bar; } // 6 > > >>> } > > >>> } > > >>> > > >>> > > >>> typedef B { > > >>> type union { > > >>> type uint8; > > >>> type uint16; > > >>> type uint32; > > >>> } > > >>> } > > >>> > > >>> leaf foo { type A; } > > >>> > > >>> YANG allows the member types to be reordered if it does not change > > >>> the value set accepted by the type. It is not clear > > >> > > >> I don't think this is true. The only statement in 6020bis that is > > >> related to this issue is the bullet that you cite below, but IMO > > >> reordering member types in a union type definition may change the type > > >> semantics because the receiving side resolves the type according to > > >> the order of member types. > > >> > > >> > > >> > > >> This depends on the format, but non-overlapping member types can > > >> change position without changing syntax or semantics. > > > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has > overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and > "inet:domain-name". > > > > > > Lada > > > > > >> The exact member type that matches is not important. > > >> > > >> typedef foo1 { > > >> type union { > > >> type int32 { range "1..10"; } > > >> type int32 { range "11..20"; } > > >> } > > >> } > > >> > > >> typedef foo2 { > > >> type union { > > >> type int32 { range "11..20"; } > > >> type int32 { range "1..10"; } > > >> } > > >> } > > >> > > >> > > >> > > >> Lada > > >> > > >> Andy > > >> > > >> > > >>> if new member types can be added in new module revisions. > > >>> > > >>> If new member types are allowed in typedef B, then the relative > > >>> position of (6) can change, even if typedef A does not change. > > >>> YANG does not explicitly state if this is allowed or not. > > >>> > > >>> bits and enumerations can be expanded in new revisions, which > > >>> changes the value set, but existing value and position numbers are > > >>> not allowed to change. > > >>> > > >>> The problematic text is in 6020bis, sec 11 > > >>> > > >>> o A "type" statement may be replaced with another "type" statement > > >>> that does not change the syntax or semantics of the type. For > > >>> example, an inline type definition may be replaced with a > typedef, > > >>> but an int8 type cannot be replaced by an int16, since the > syntax > > >>> would change. > > >>> > > >>> > > >>> > > >>> In practice reordering member types would be very rare, but the SID > > >>> numbering would need to remember the member type order for each leaf > > >>> or leaf-list that resolves to a union type. > > >>> > > >>> It doesn't help to tag any other type besides union. > > >>> > > >>> > > >>> Andy > > >>> _______________________________________________ > > >>> core mailing list > > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/core > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a113e5dde914a4c05387b87cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 25 Jul 2016, at 21:00, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 25 Jul 2016, at 18:05, Michel Veillette <Michel.Veillette@trilliantinc.com>= ; wrote:
> >
> > Hi Lada, Hi Andy
> >
> > The important questions we need answer to validate the current so= lution are the following.
> >
> > - In a union, is it valid to define multiple enumerations which r= euse the same value(s) with a different semantic meaning?
> > - In a union, is it valid to define multiple bits which reuse the= same position(s) with a different semantic meaning?
>
> IMO, yes, in both cases. I am not saying that it's a good design t= hough.
>
> >
> > In the following examples, value or position 0 means both white a= nd red which I believe it's invalid.
>
> I don't think so. The member types are checked in the same order a= s they appear in the union's definition, and the first type for which a= given value is valid is used.
>
>
>
> That's the issue here.
> The member type value spaces are allowed to overlap each other.
> The "first wins" depends on the value being sent.
> The same problem exists for JSON for boolean and numeric types.
> Only XML passes everything as a string.=C2=A0 YANG union was designed = only to work
> robustly with XML.

I believe for JSON it is perfectly robust. The general rule should be this:= use whatever information you have to determine whether the received value = is valid for the first member type. If not, try the second member etc.


believe what youi want:

=

=C2=A0 =C2=A0type union {
=C2=A0 =C2=A0= =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0type int32;=
=C2=A0 =C2=A0}

JSON produces different = results than XML.

If client A sets number 42 in JS= ON, then client B will read back string "42" in XML.
If= the XML client sets string "42", the JSON client will read back = string "42".
This is the exact same issue facing CBOR c= onversion


=C2=A0
Lada


Andy
=C2=A0
>
>
> > If this is the case, the currently proposed solution to tag some = specific datatype (bits,=C2=A0 enumeration, identityref, instance-identifie= r) when used in a union resolve any potential ambiguities.
>
> Yes, I think this is a good idea because otherwise resolving the membe= r types may be difficult. Moreover, sometimes the sending side might want t= o override the resolution algorithm - e.g., if a client wants to set a leaf= with "inet:host" type to "1.2.3.4" and interpret it as= a domain name rather than IP address.
>
> > Can we move ahead with the current solution?
>
> The current solution is just as good and just as broken as the JSON so= lution,
> and we already moved ahead with that in NETMOD WG. (So I guess that me= ans yes?)
>
>
> Andy
>
> >
> > ENUMERATION EXAMPLE
> >
> > typedef A {
> >=C2=A0 type union {
> >=C2=A0 =C2=A0 type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 enum white {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 enum black {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 enum red {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 enum green {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 enum blue {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 }
> >=C2=A0 }
> > }
>
> Values 0 and 1 are interpreted as "white" and "black&qu= ot;, value 2 is "blue".
>
> >
> > BITS EXAMPLE
> >
> > typedef B {
> >=C2=A0 type union {
> >=C2=A0 =C2=A0 type bits {
> >=C2=A0 =C2=A0 =C2=A0 bit white {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 bit black {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 type bits {
> >=C2=A0 =C2=A0 =C2=A0 bit red {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 bit green {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 bit blue {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 2;
> >=C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 }
> >=C2=A0 }
> > }
>
> Ditto.
>
> Lada
>
> >
> > Regards,
> > Michel
> >
> > -----Original Message-----
> > From: core [mailto:core-= bounces@ietf.org] On Behalf Of Ladislav Lhotka
> > Sent: Monday, July 25, 2016 10:41 AM
> > To: Andy Bierman <andy@y= umaworks.com>
> > Cc: Core <core@ietf.org&g= t;
> > Subject: Re: [core] fixing YANG to CBOR
> >
> >
> >> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
> >>
> >>
> >>
> >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> Andy Bierman <andy@y= umaworks.com> writes:
> >>
> >>> Hi,
> >>>
> >>> It seems to me that the only tagging actually needed woul= d be to
> >>> identify the ordered list of member types within a union = type.
> >>>
> >>>
> >>> typedef A {
> >>>=C2=A0 type union {
> >>>=C2=A0 =C2=A0 type int32 ;=C2=A0 =C2=A0// 1
> >>>=C2=A0 =C2=A0 type string; // 2
> >>>=C2=A0 =C2=A0 type B;=C2=A0 =C2=A0// 3, 4, 5
> >>>=C2=A0 =C2=A0 type identityref { base bar; }=C2=A0 =C2=A0/= / 6
> >>>=C2=A0 }
> >>> }
> >>>
> >>>
> >>> typedef B {
> >>>=C2=A0 type union {
> >>>=C2=A0 =C2=A0 type uint8;
> >>>=C2=A0 =C2=A0 type uint16;
> >>>=C2=A0 =C2=A0 type uint32;
> >>>=C2=A0 }
> >>> }
> >>>
> >>> leaf foo { type A; }
> >>>
> >>> YANG allows the member types to be reordered if it does n= ot change
> >>> the value set accepted by the type.=C2=A0 It is not clear=
> >>
> >> I don't think this is true. The only statement in 6020bis= that is
> >> related to this issue is the bullet that you cite below, but = IMO
> >> reordering member types in a union type definition may change= the type
> >> semantics because the receiving side resolves the type accord= ing to
> >> the order of member types.
> >>
> >>
> >>
> >> This depends on the format, but non-overlapping member types = can
> >> change position without changing syntax or semantics.
> >
> > Yes, but, for instance, the "inet:host" type in RFC 699= 1 has overlapping members: "1.2.3.4" is valid as both "inet:= ip-address" and "inet:domain-name".
> >
> > Lada
> >
> >> The exact member type that matches is not important.
> >>
> >>=C2=A0 =C2=A0typedef foo1 {
> >>=C2=A0 =C2=A0 =C2=A0 type union {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "1..= 10"; }
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "11.= .20"; }
> >>=C2=A0 =C2=A0 =C2=A0 }
> >>=C2=A0 =C2=A0 }
> >>
> >>=C2=A0 typedef foo2 {
> >>=C2=A0 =C2=A0 =C2=A0 type union {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "11.= .20"; }
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range "1..= 10"; }
> >>=C2=A0 =C2=A0 =C2=A0 }
> >>=C2=A0 =C2=A0 }
> >>
> >>
> >>
> >> Lada
> >>
> >> Andy
> >>
> >>
> >>> if new member types can be added in new module revisions.=
> >>>
> >>> If new member types are allowed in typedef B, then the re= lative
> >>> position of (6) can change, even if typedef A does not ch= ange.
> >>> YANG does not explicitly state if this is allowed or not.=
> >>>
> >>> bits and enumerations can be expanded in new revisions, w= hich
> >>> changes the value set, but existing value and position nu= mbers are
> >>> not allowed to change.
> >>>
> >>> The problematic text is in 6020bis, sec 11
> >>>
> >>>=C2=A0 o=C2=A0 A "type" statement may be replace= d with another "type" statement
> >>>=C2=A0 =C2=A0 =C2=A0 that does not change the syntax or se= mantics of the type.=C2=A0 For
> >>>=C2=A0 =C2=A0 =C2=A0 example, an inline type definition ma= y be replaced with a typedef,
> >>>=C2=A0 =C2=A0 =C2=A0 but an int8 type cannot be replaced b= y an int16, since the syntax
> >>>=C2=A0 =C2=A0 =C2=A0 would change.
> >>>
> >>>
> >>>
> >>> In practice reordering member types would be very rare, b= ut the SID
> >>> numbering would need to remember the member type order fo= r each leaf
> >>> or leaf-list that resolves to a union type.
> >>>
> >>> It doesn't help to tag any other type besides union.<= br> > >>>
> >>>
> >>> Andy
> >>> _______________________________________________
> >>> core mailing list
> >>> core@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/co= re
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core >
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a113e5dde914a4c05387b87cd-- From nobody Mon Jul 25 13:33:49 2016 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 0F5EA12B068 for ; Mon, 25 Jul 2016 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgr7SS6ph-Dg for ; Mon, 25 Jul 2016 13:33:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA1412D9F0 for ; Mon, 25 Jul 2016 13:33:44 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 1ED54611BB; Mon, 25 Jul 2016 22:33:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469478823; bh=BbXpVy8SML2LMkVBfInWEWO+g4VHrOgaTWY5JYaksN0=; h=From:Date:To; b=jAIIC1dXp4TiWYEba2V3UfBd3aQucMQkgb4qrPHb2KZ1lqnUKqxi6iOw0nSFOmNnU vVhyL57b+EWIq+1TMDmSXO9AH2jSHDIWfVRPteGu7pZCwcdV4ZyUfRFH9bVveVPgkX L651rVuJu/xAtU1VarhfQGYccJFuTcCVl49hHOvM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 25 Jul 2016 22:33:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2ED20D78-11A9-4E12-A8B5-7D6F180922F5@nic.cz> References: To: Michel Veillette X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 20:33:47 -0000 > On 25 Jul 2016, at 21:12, Michel Veillette = wrote: >=20 > Hi Lada >=20 > In your answer " Yes, I think this is a good idea...", you seem to = assume that union member are tagged, not datatype. > See below for an example of both approaches. > We basically need to select one of these. >=20 > # UNION MEMBER TAGGING I think I already expressed support to this solution in an earlier = thread. This should solve most real-life cases. It is not completely = general though because there may be unions inside unions. Lada >=20 > typedef A { >=20 > type union { > type identityref { <=3D=3D=3D=3D=3D=3D TAG member 1 (e..g. tag = 40) > base "X:Y"; > } >=20 > type enumeration { <=3D=3D=3D=3D=3D=3D TAG member 2 (e..g. tag = 41) > enum white { > value 0; > } enum black { > value 1; > } > }=20 >=20 > type enumeration { <=3D=3D=3D=3D=3D=3D TAG member 3 (e..g. tag = 42) > enum red { > value 0; > } > enum blue { > value 1; > } > } =20 > } > } >=20 > PROS, completely remove any ambiguities. > CONS, not backward compatible between module revisions if the order = change or new members are inserted. >=20 > # DATATYPE TAGGING >=20 > typedef A { >=20 > type union { > type identityref { <=3D=3D=3D=3D=3D=3D TAG identityref (e..g. = tag 40) > base "X:Y"; > } >=20 > type enumeration { <=3D=3D=3D=3D=3D=3D TAG enumeration (e..g. = tag 41) > enum white { > value 0; > } enum black { > value 1; > } > }=20 >=20 > type enumeration { <=3D=3D=3D=3D=3D=3D TAG enumeration (e..g. = tag 41) > enum red { > value 0; > } > enum blue { > value 1; > } > } =20 > } > } >=20 > PROS, backward compatible between module versions > CONS, ambiguities may still exists for multiple use of enumeration or = bits in the same union. >=20 > Regards, > Michel >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Monday, July 25, 2016 2:52 PM > To: Michel Veillette > Cc: Andy Bierman ; Core > Subject: Re: [core] fixing YANG to CBOR >=20 >=20 >> On 25 Jul 2016, at 18:05, Michel Veillette = wrote: >>=20 >> Hi Lada, Hi Andy >>=20 >> The important questions we need answer to validate the current = solution are the following. >>=20 >> - In a union, is it valid to define multiple enumerations which reuse = the same value(s) with a different semantic meaning? >> - In a union, is it valid to define multiple bits which reuse the = same position(s) with a different semantic meaning? >=20 > IMO, yes, in both cases. I am not saying that it's a good design = though.=20 >=20 >>=20 >> In the following examples, value or position 0 means both white and = red which I believe it's invalid. >=20 > I don't think so. The member types are checked in the same order as = they appear in the union's definition, and the first type for which a = given value is valid is used. >=20 >> If this is the case, the currently proposed solution to tag some = specific datatype (bits, enumeration, identityref, instance-identifier) = when used in a union resolve any potential ambiguities. >=20 > Yes, I think this is a good idea because otherwise resolving the = member types may be difficult. Moreover, sometimes the sending side = might want to override the resolution algorithm - e.g., if a client = wants to set a leaf with "inet:host" type to "1.2.3.4" and interpret it = as a domain name rather than IP address. =20 >=20 >> Can we move ahead with the current solution? >>=20 >> ENUMERATION EXAMPLE >>=20 >> typedef A { >> type union { >> type enumeration { >> enum white { >> value 0; >> } >> enum black { >> value 1; >> } >> } =20 >> type enumeration { >> enum red { >> value 0; >> } >> enum green { >> value 1; >> } >> enum blue { >> value 2; >> } >> } =20 >> } >> } >=20 > Values 0 and 1 are interpreted as "white" and "black", value 2 is = "blue". >=20 >>=20 >> BITS EXAMPLE >>=20 >> typedef B { >> type union { >> type bits { >> bit white { >> position 0; >> } >> bit black { >> position 1; >> } >> } >> type bits { >> bit red { >> position 0; >> } >> bit green { >> position 1; >> } >> bit blue { >> position 2; >> } >> } >> } >> } >=20 > Ditto. >=20 > Lada >=20 >>=20 >> Regards, >> Michel >>=20 >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav = Lhotka >> Sent: Monday, July 25, 2016 10:41 AM >> To: Andy Bierman >> Cc: Core >> Subject: Re: [core] fixing YANG to CBOR >>=20 >>=20 >>> On 25 Jul 2016, at 16:21, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka = wrote: >>> Andy Bierman writes: >>>=20 >>>> Hi, >>>>=20 >>>> It seems to me that the only tagging actually needed would be to=20 >>>> identify the ordered list of member types within a union type. >>>>=20 >>>>=20 >>>> typedef A { >>>> type union { >>>> type int32 ; // 1 >>>> type string; // 2 >>>> type B; // 3, 4, 5 >>>> type identityref { base bar; } // 6 >>>> } >>>> } >>>>=20 >>>>=20 >>>> typedef B { >>>> type union { >>>> type uint8; >>>> type uint16; >>>> type uint32; >>>> } >>>> } >>>>=20 >>>> leaf foo { type A; } >>>>=20 >>>> YANG allows the member types to be reordered if it does not change=20= >>>> the value set accepted by the type. It is not clear >>>=20 >>> I don't think this is true. The only statement in 6020bis that is=20 >>> related to this issue is the bullet that you cite below, but IMO=20 >>> reordering member types in a union type definition may change the=20 >>> type semantics because the receiving side resolves the type = according=20 >>> to the order of member types. >>>=20 >>>=20 >>>=20 >>> This depends on the format, but non-overlapping member types can=20 >>> change position without changing syntax or semantics. >>=20 >> Yes, but, for instance, the "inet:host" type in RFC 6991 has = overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and = "inet:domain-name". >>=20 >> Lada >>=20 >>> The exact member type that matches is not important. >>>=20 >>> typedef foo1 { >>> type union { >>> type int32 { range "1..10"; } >>> type int32 { range "11..20"; } >>> } >>> } >>>=20 >>> typedef foo2 { >>> type union { >>> type int32 { range "11..20"; } >>> type int32 { range "1..10"; } >>> } >>> } >>>=20 >>>=20 >>>=20 >>> Lada >>>=20 >>> Andy >>>=20 >>>=20 >>>> if new member types can be added in new module revisions. >>>>=20 >>>> If new member types are allowed in typedef B, then the relative=20 >>>> position of (6) can change, even if typedef A does not change. >>>> YANG does not explicitly state if this is allowed or not. >>>>=20 >>>> bits and enumerations can be expanded in new revisions, which=20 >>>> changes the value set, but existing value and position numbers are=20= >>>> not allowed to change. >>>>=20 >>>> The problematic text is in 6020bis, sec 11 >>>>=20 >>>> o A "type" statement may be replaced with another "type" statement >>>> that does not change the syntax or semantics of the type. For >>>> example, an inline type definition may be replaced with a = typedef, >>>> but an int8 type cannot be replaced by an int16, since the = syntax >>>> would change. >>>>=20 >>>>=20 >>>>=20 >>>> In practice reordering member types would be very rare, but the SID=20= >>>> numbering would need to remember the member type order for each = leaf=20 >>>> or leaf-list that resolves to a union type. >>>>=20 >>>> It doesn't help to tag any other type besides union. >>>>=20 >>>>=20 >>>> Andy >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 13:53:56 2016 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 8872712D0D1 for ; Mon, 25 Jul 2016 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgxFhXic7q5A for ; Mon, 25 Jul 2016 13:53:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4E512D0A0 for ; Mon, 25 Jul 2016 13:53:52 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:fffe:289a:25dd:7b0d:ad06] (unknown [IPv6:2a01:5e0:29:fffe:289a:25dd:7b0d:ad06]) by mail.nic.cz (Postfix) with ESMTPSA id 3966A61D23; Mon, 25 Jul 2016 22:53:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469480031; bh=0eSCoBW2R88ZKxYGd+i/A+ZJZznoZaDGd9SOv+sHvKU=; h=From:Date:To; b=NPwAy+F2olLMXGoyWnP0cAWUfrEEGSrdtvyf/xxGpkSfAqhwt9ebg0b0//eskm5Dr l6ZQiSDD+0gnsFrIMXXm37mYiR2iVDO2Y6BUuqvc0ZGgLaujfaa6X7a+YaFQ4Q2dOb 9jpMbC7YR7dNLJUE/Lky6EEfJzwQNjGqaATA7PwQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 25 Jul 2016 22:53:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6DEC3424-1E9F-4B2C-9343-74501ED22ADA@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 20:53:55 -0000 > On 25 Jul 2016, at 22:21, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka = wrote: >=20 > > On 25 Jul 2016, at 21:00, Andy Bierman wrote: > > > > > > > > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka = wrote: > > > > > On 25 Jul 2016, at 18:05, Michel Veillette = wrote: > > > > > > Hi Lada, Hi Andy > > > > > > The important questions we need answer to validate the current = solution are the following. > > > > > > - In a union, is it valid to define multiple enumerations which = reuse the same value(s) with a different semantic meaning? > > > - In a union, is it valid to define multiple bits which reuse the = same position(s) with a different semantic meaning? > > > > IMO, yes, in both cases. I am not saying that it's a good design = though. > > > > > > > > In the following examples, value or position 0 means both white = and red which I believe it's invalid. > > > > I don't think so. The member types are checked in the same order as = they appear in the union's definition, and the first type for which a = given value is valid is used. > > > > > > > > That's the issue here. > > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent. > > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string. YANG union was designed = only to work > > robustly with XML. >=20 > I believe for JSON it is perfectly robust. The general rule should be = this: use whatever information you have to determine whether the = received value is valid for the first member type. If not, try the = second member etc. >=20 >=20 > believe what youi want: >=20 >=20 > type union { > type string; > type int32; > } >=20 > JSON produces different results than XML. >=20 > If client A sets number 42 in JSON, then client B will read back = string "42" in XML. > If the XML client sets string "42", the JSON client will read back = string "42". > This is the exact same issue facing CBOR conversion In my view, most implementations will eventually use just one encoding, = and this problem won't exist for them. XML, JSON and CBOR in reality pass different information, it is not like = UTF-8 versus UTF-16. Restricting all alternative media types only to = features supported in XML doesn't make much sense. Lada=20 >=20 >=20 > =20 > Lada >=20 >=20 > Andy > =20 > > > > > > > If this is the case, the currently proposed solution to tag some = specific datatype (bits, enumeration, identityref, instance-identifier) = when used in a union resolve any potential ambiguities. > > > > Yes, I think this is a good idea because otherwise resolving the = member types may be difficult. Moreover, sometimes the sending side = might want to override the resolution algorithm - e.g., if a client = wants to set a leaf with "inet:host" type to "1.2.3.4" and interpret it = as a domain name rather than IP address. > > > > > Can we move ahead with the current solution? > > > > The current solution is just as good and just as broken as the JSON = solution, > > and we already moved ahead with that in NETMOD WG. (So I guess that = means yes?) > > > > > > Andy > > > > > > > > ENUMERATION EXAMPLE > > > > > > typedef A { > > > type union { > > > type enumeration { > > > enum white { > > > value 0; > > > } > > > enum black { > > > value 1; > > > } > > > } > > > type enumeration { > > > enum red { > > > value 0; > > > } > > > enum green { > > > value 1; > > > } > > > enum blue { > > > value 2; > > > } > > > } > > > } > > > } > > > > Values 0 and 1 are interpreted as "white" and "black", value 2 is = "blue". > > > > > > > > BITS EXAMPLE > > > > > > typedef B { > > > type union { > > > type bits { > > > bit white { > > > position 0; > > > } > > > bit black { > > > position 1; > > > } > > > } > > > type bits { > > > bit red { > > > position 0; > > > } > > > bit green { > > > position 1; > > > } > > > bit blue { > > > position 2; > > > } > > > } > > > } > > > } > > > > Ditto. > > > > Lada > > > > > > > > Regards, > > > Michel > > > > > > -----Original Message----- > > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav = Lhotka > > > Sent: Monday, July 25, 2016 10:41 AM > > > To: Andy Bierman > > > Cc: Core > > > Subject: Re: [core] fixing YANG to CBOR > > > > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman = wrote: > > >> > > >> > > >> > > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka = wrote: > > >> Andy Bierman writes: > > >> > > >>> Hi, > > >>> > > >>> It seems to me that the only tagging actually needed would be to > > >>> identify the ordered list of member types within a union type. > > >>> > > >>> > > >>> typedef A { > > >>> type union { > > >>> type int32 ; // 1 > > >>> type string; // 2 > > >>> type B; // 3, 4, 5 > > >>> type identityref { base bar; } // 6 > > >>> } > > >>> } > > >>> > > >>> > > >>> typedef B { > > >>> type union { > > >>> type uint8; > > >>> type uint16; > > >>> type uint32; > > >>> } > > >>> } > > >>> > > >>> leaf foo { type A; } > > >>> > > >>> YANG allows the member types to be reordered if it does not = change > > >>> the value set accepted by the type. It is not clear > > >> > > >> I don't think this is true. The only statement in 6020bis that is > > >> related to this issue is the bullet that you cite below, but IMO > > >> reordering member types in a union type definition may change the = type > > >> semantics because the receiving side resolves the type according = to > > >> the order of member types. > > >> > > >> > > >> > > >> This depends on the format, but non-overlapping member types can > > >> change position without changing syntax or semantics. > > > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has = overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and = "inet:domain-name". > > > > > > Lada > > > > > >> The exact member type that matches is not important. > > >> > > >> typedef foo1 { > > >> type union { > > >> type int32 { range "1..10"; } > > >> type int32 { range "11..20"; } > > >> } > > >> } > > >> > > >> typedef foo2 { > > >> type union { > > >> type int32 { range "11..20"; } > > >> type int32 { range "1..10"; } > > >> } > > >> } > > >> > > >> > > >> > > >> Lada > > >> > > >> Andy > > >> > > >> > > >>> if new member types can be added in new module revisions. > > >>> > > >>> If new member types are allowed in typedef B, then the relative > > >>> position of (6) can change, even if typedef A does not change. > > >>> YANG does not explicitly state if this is allowed or not. > > >>> > > >>> bits and enumerations can be expanded in new revisions, which > > >>> changes the value set, but existing value and position numbers = are > > >>> not allowed to change. > > >>> > > >>> The problematic text is in 6020bis, sec 11 > > >>> > > >>> o A "type" statement may be replaced with another "type" = statement > > >>> that does not change the syntax or semantics of the type. = For > > >>> example, an inline type definition may be replaced with a = typedef, > > >>> but an int8 type cannot be replaced by an int16, since the = syntax > > >>> would change. > > >>> > > >>> > > >>> > > >>> In practice reordering member types would be very rare, but the = SID > > >>> numbering would need to remember the member type order for each = leaf > > >>> or leaf-list that resolves to a union type. > > >>> > > >>> It doesn't help to tag any other type besides union. > > >>> > > >>> > > >>> Andy > > >>> _______________________________________________ > > >>> core mailing list > > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/core > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 25 20:20:12 2016 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 340B912B065 for ; Mon, 25 Jul 2016 20:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 aOPSzmf9hgCH for ; Mon, 25 Jul 2016 20:20:08 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 D44BB12B063 for ; Mon, 25 Jul 2016 20:20:06 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r9so180699733ywg.0 for ; Mon, 25 Jul 2016 20:20:06 -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=ziv/cVkEvdEhOVseqzIDJfL/B1ltoZ8Z0GPL6rIgTto=; b=h92+1gx9xOyES9RvdUCNWLoqC5hxHMevoJCsTHhE7EYMyHGR5lMUokpqNR1d76NmQY 5E1YYKFl+7G0naKOvqMKOpnbNu4DAB+ljjauJTZe5pKHfvQVE0xV8qIWJiUq9xivDRJC NeKzld+h1c9ZnpG9Ceihj/WHKYeRLUQVmwPNehz+gbqirGS5nbFHVa4+kBi/rwI0IQk7 VipBMWZo7+18Te52fSEIzSTGNiX+L8ng9BuLm1LOxNNI6BGsyGk2U9E1lO/UFtpM5/lT eOh3/id5CptP0gDO3fFgoX04m5Y0cLg2yRU2a9daSst3iTs43amlCVjyLpgn8G9UNVrR 2/Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ziv/cVkEvdEhOVseqzIDJfL/B1ltoZ8Z0GPL6rIgTto=; b=NPuZB9fnJIhbnIF+zBSUhJric1Fr8Cd5OA3Cu6cjbT79ou2Xr2aKuWdYLaeSl+BeGb YOLQG5pbh+lEdPvX708oohti7/OAtsz5z/Btt9NP5qhjqq47wbucoRTXA8kzVkcKvPHW cQVUWBHt8ll6qRzXYuDVLjR0hhCCzNPD1jzo/Ch2uUy0ZqKlNxk9mwV/oPl2UKb/ftYe ZM/o5Ao1DpwhXUqx2P6CcpXKUc9GI+aN8kYsVd9lhO0PhxaUIu2QyZENmHZgWgyyjw5T aWZYgNsWrW18n+KvSxFUWl/msgc9p+ZHCNYM/huWtIcAGVMPjy1+LOV2NRc5cHo3nGGd ZIbg== X-Gm-Message-State: AEkoouu7DhG+cRRu+ayT3NsZK6f/71gpOWOQHGBTSUO1jMKMS59hQD6h1uIZtH9UKY1vbfcQZeRTruwrQSWKWg== X-Received: by 10.31.9.67 with SMTP id 64mr9567414vkj.89.1469503205929; Mon, 25 Jul 2016 20:20:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 25 Jul 2016 20:20:04 -0700 (PDT) In-Reply-To: <6DEC3424-1E9F-4B2C-9343-74501ED22ADA@nic.cz> References: <6DEC3424-1E9F-4B2C-9343-74501ED22ADA@nic.cz> From: Andy Bierman Date: Mon, 25 Jul 2016 20:20:04 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11440ef4960af905388160a6 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 03:20:10 -0000 --001a11440ef4960af905388160a6 Content-Type: text/plain; charset=UTF-8 Hi, I think this "union type" corner-case is not bad enough to justify a really complicated design like tracking the order of union type syntax changes. We need to remove order dependencies, not add new ones. I should have realized this is too complicated. So I think the current tagging solution is good enough. Do not change it to count and order the member type-stmts. I will write YANG guidelines in 6087bis to attempt to prevent these corner-cases from occurring in IETF modules. Andy On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lhotka wrote: > > > On 25 Jul 2016, at 22:21, Andy Bierman wrote: > > > > > > > > On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka wrote: > > > > > On 25 Jul 2016, at 21:00, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka > wrote: > > > > > > > On 25 Jul 2016, at 18:05, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > > > > > > > Hi Lada, Hi Andy > > > > > > > > The important questions we need answer to validate the current > solution are the following. > > > > > > > > - In a union, is it valid to define multiple enumerations which > reuse the same value(s) with a different semantic meaning? > > > > - In a union, is it valid to define multiple bits which reuse the > same position(s) with a different semantic meaning? > > > > > > IMO, yes, in both cases. I am not saying that it's a good design > though. > > > > > > > > > > > In the following examples, value or position 0 means both white and > red which I believe it's invalid. > > > > > > I don't think so. The member types are checked in the same order as > they appear in the union's definition, and the first type for which a given > value is valid is used. > > > > > > > > > > > > That's the issue here. > > > The member type value spaces are allowed to overlap each other. > > > The "first wins" depends on the value being sent. > > > The same problem exists for JSON for boolean and numeric types. > > > Only XML passes everything as a string. YANG union was designed only > to work > > > robustly with XML. > > > > I believe for JSON it is perfectly robust. The general rule should be > this: use whatever information you have to determine whether the received > value is valid for the first member type. If not, try the second member etc. > > > > > > believe what youi want: > > > > > > type union { > > type string; > > type int32; > > } > > > > JSON produces different results than XML. > > > > If client A sets number 42 in JSON, then client B will read back string > "42" in XML. > > If the XML client sets string "42", the JSON client will read back > string "42". > > This is the exact same issue facing CBOR conversion > > In my view, most implementations will eventually use just one encoding, > and this problem won't exist for them. > > XML, JSON and CBOR in reality pass different information, it is not like > UTF-8 versus UTF-16. Restricting all alternative media types only to > features supported in XML doesn't make much sense. > > Lada > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > If this is the case, the currently proposed solution to tag some > specific datatype (bits, enumeration, identityref, instance-identifier) > when used in a union resolve any potential ambiguities. > > > > > > Yes, I think this is a good idea because otherwise resolving the > member types may be difficult. Moreover, sometimes the sending side might > want to override the resolution algorithm - e.g., if a client wants to set > a leaf with "inet:host" type to "1.2.3.4" and interpret it as a domain name > rather than IP address. > > > > > > > Can we move ahead with the current solution? > > > > > > The current solution is just as good and just as broken as the JSON > solution, > > > and we already moved ahead with that in NETMOD WG. (So I guess that > means yes?) > > > > > > > > > Andy > > > > > > > > > > > ENUMERATION EXAMPLE > > > > > > > > typedef A { > > > > type union { > > > > type enumeration { > > > > enum white { > > > > value 0; > > > > } > > > > enum black { > > > > value 1; > > > > } > > > > } > > > > type enumeration { > > > > enum red { > > > > value 0; > > > > } > > > > enum green { > > > > value 1; > > > > } > > > > enum blue { > > > > value 2; > > > > } > > > > } > > > > } > > > > } > > > > > > Values 0 and 1 are interpreted as "white" and "black", value 2 is > "blue". > > > > > > > > > > > BITS EXAMPLE > > > > > > > > typedef B { > > > > type union { > > > > type bits { > > > > bit white { > > > > position 0; > > > > } > > > > bit black { > > > > position 1; > > > > } > > > > } > > > > type bits { > > > > bit red { > > > > position 0; > > > > } > > > > bit green { > > > > position 1; > > > > } > > > > bit blue { > > > > position 2; > > > > } > > > > } > > > > } > > > > } > > > > > > Ditto. > > > > > > Lada > > > > > > > > > > > Regards, > > > > Michel > > > > > > > > -----Original Message----- > > > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav > Lhotka > > > > Sent: Monday, July 25, 2016 10:41 AM > > > > To: Andy Bierman > > > > Cc: Core > > > > Subject: Re: [core] fixing YANG to CBOR > > > > > > > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman wrote: > > > >> > > > >> > > > >> > > > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka > wrote: > > > >> Andy Bierman writes: > > > >> > > > >>> Hi, > > > >>> > > > >>> It seems to me that the only tagging actually needed would be to > > > >>> identify the ordered list of member types within a union type. > > > >>> > > > >>> > > > >>> typedef A { > > > >>> type union { > > > >>> type int32 ; // 1 > > > >>> type string; // 2 > > > >>> type B; // 3, 4, 5 > > > >>> type identityref { base bar; } // 6 > > > >>> } > > > >>> } > > > >>> > > > >>> > > > >>> typedef B { > > > >>> type union { > > > >>> type uint8; > > > >>> type uint16; > > > >>> type uint32; > > > >>> } > > > >>> } > > > >>> > > > >>> leaf foo { type A; } > > > >>> > > > >>> YANG allows the member types to be reordered if it does not change > > > >>> the value set accepted by the type. It is not clear > > > >> > > > >> I don't think this is true. The only statement in 6020bis that is > > > >> related to this issue is the bullet that you cite below, but IMO > > > >> reordering member types in a union type definition may change the > type > > > >> semantics because the receiving side resolves the type according to > > > >> the order of member types. > > > >> > > > >> > > > >> > > > >> This depends on the format, but non-overlapping member types can > > > >> change position without changing syntax or semantics. > > > > > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has > overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and > "inet:domain-name". > > > > > > > > Lada > > > > > > > >> The exact member type that matches is not important. > > > >> > > > >> typedef foo1 { > > > >> type union { > > > >> type int32 { range "1..10"; } > > > >> type int32 { range "11..20"; } > > > >> } > > > >> } > > > >> > > > >> typedef foo2 { > > > >> type union { > > > >> type int32 { range "11..20"; } > > > >> type int32 { range "1..10"; } > > > >> } > > > >> } > > > >> > > > >> > > > >> > > > >> Lada > > > >> > > > >> Andy > > > >> > > > >> > > > >>> if new member types can be added in new module revisions. > > > >>> > > > >>> If new member types are allowed in typedef B, then the relative > > > >>> position of (6) can change, even if typedef A does not change. > > > >>> YANG does not explicitly state if this is allowed or not. > > > >>> > > > >>> bits and enumerations can be expanded in new revisions, which > > > >>> changes the value set, but existing value and position numbers are > > > >>> not allowed to change. > > > >>> > > > >>> The problematic text is in 6020bis, sec 11 > > > >>> > > > >>> o A "type" statement may be replaced with another "type" > statement > > > >>> that does not change the syntax or semantics of the type. For > > > >>> example, an inline type definition may be replaced with a > typedef, > > > >>> but an int8 type cannot be replaced by an int16, since the > syntax > > > >>> would change. > > > >>> > > > >>> > > > >>> > > > >>> In practice reordering member types would be very rare, but the SID > > > >>> numbering would need to remember the member type order for each > leaf > > > >>> or leaf-list that resolves to a union type. > > > >>> > > > >>> It doesn't help to tag any other type besides union. > > > >>> > > > >>> > > > >>> Andy > > > >>> _______________________________________________ > > > >>> core mailing list > > > >>> core@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/core > > > >> > > > >> -- > > > >> Ladislav Lhotka, CZ.NIC Labs > > > >> PGP Key ID: E74E8C0C > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > core mailing list > > > > core@ietf.org > > > > https://www.ietf.org/mailman/listinfo/core > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11440ef4960af905388160a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think this "union type"= corner-case is not bad enough to
justify a really complicated de= sign like tracking the order
of union type syntax changes.=C2=A0 = We need to remove order
dependencies, not add new ones.=C2=A0 I s= hould have realized
this is too complicated.

=
So I think the current tagging solution is good enough.
Do n= ot change it to count and order the member type-stmts.

=
I will write YANG guidelines in 6087bis to attempt to prevent these
corner-cases from occurring in IETF modules.


Andy

=
On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lh= otka <lhotka@nic.cz> wrote:
> On 25 Jul 2016, at 22:21, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 25 Jul 2016, at 21:00, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 25 Jul 2016, at 18:05, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote:
> > >
> > > Hi Lada, Hi Andy
> > >
> > > The important questions we need answer to validate the curre= nt solution are the following.
> > >
> > > - In a union, is it valid to define multiple enumerations wh= ich reuse the same value(s) with a different semantic meaning?
> > > - In a union, is it valid to define multiple bits which reus= e the same position(s) with a different semantic meaning?
> >
> > IMO, yes, in both cases. I am not saying that it's a good des= ign though.
> >
> > >
> > > In the following examples, value or position 0 means both wh= ite and red which I believe it's invalid.
> >
> > I don't think so. The member types are checked in the same or= der as they appear in the union's definition, and the first type for wh= ich a given value is valid is used.
> >
> >
> >
> > That's the issue here.
> > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent.
> > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string.=C2=A0 YANG union was desi= gned only to work
> > robustly with XML.
>
> I believe for JSON it is perfectly robust. The general rule should be = this: use whatever information you have to determine whether the received v= alue is valid for the first member type. If not, try the second member etc.=
>
>
> believe what youi want:
>
>
>=C2=A0 =C2=A0 type union {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32;
>=C2=A0 =C2=A0 }
>
> JSON produces different results than XML.
>
> If client A sets number 42 in JSON, then client B will read back strin= g "42" in XML.
> If the XML client sets string "42", the JSON client will rea= d back string "42".
> This is the exact same issue facing CBOR conversion

In my view, most implementations will eventually use just one encoding, and= this problem won't exist for them.

XML, JSON and CBOR in reality pass different information, it is not like UT= F-8 versus UTF-16. Restricting all alternative media types only to features= supported in XML doesn't make much sense.

Lada

>
>
>
> Lada
>
>
> Andy
>
> >
> >
> > > If this is the case, the currently proposed solution to tag = some specific datatype (bits,=C2=A0 enumeration, identityref, instance-iden= tifier) when used in a union resolve any potential ambiguities.
> >
> > Yes, I think this is a good idea because otherwise resolving the = member types may be difficult. Moreover, sometimes the sending side might w= ant to override the resolution algorithm - e.g., if a client wants to set a= leaf with "inet:host" type to "1.2.3.4" and interpret = it as a domain name rather than IP address.
> >
> > > Can we move ahead with the current solution?
> >
> > The current solution is just as good and just as broken as the JS= ON solution,
> > and we already moved ahead with that in NETMOD WG. (So I guess th= at means yes?)
> >
> >
> > Andy
> >
> > >
> > > ENUMERATION EXAMPLE
> > >
> > > typedef A {
> > >=C2=A0 type union {
> > >=C2=A0 =C2=A0 type enumeration {
> > >=C2=A0 =C2=A0 =C2=A0 enum white {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 enum black {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 type enumeration {
> > >=C2=A0 =C2=A0 =C2=A0 enum red {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 0;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 enum green {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 enum blue {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 }
> > >=C2=A0 }
> > > }
> >
> > Values 0 and 1 are interpreted as "white" and "bla= ck", value 2 is "blue".
> >
> > >
> > > BITS EXAMPLE
> > >
> > > typedef B {
> > >=C2=A0 type union {
> > >=C2=A0 =C2=A0 type bits {
> > >=C2=A0 =C2=A0 =C2=A0 bit white {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 bit black {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 type bits {
> > >=C2=A0 =C2=A0 =C2=A0 bit red {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 0;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 bit green {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 1;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 bit blue {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 position 2;
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 }
> > >=C2=A0 }
> > > }
> >
> > Ditto.
> >
> > Lada
> >
> > >
> > > Regards,
> > > Michel
> > >
> > > -----Original Message-----
> > > From: core [mailto:= core-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> > > Sent: Monday, July 25, 2016 10:41 AM
> > > To: Andy Bierman <a= ndy@yumaworks.com>
> > > Cc: Core <core@ietf.org<= /a>>
> > > Subject: Re: [core] fixing YANG to CBOR
> > >
> > >
> > >> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
> > >>
> > >>
> > >>
> > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >> Andy Bierman <a= ndy@yumaworks.com> writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> It seems to me that the only tagging actually needed= would be to
> > >>> identify the ordered list of member types within a u= nion type.
> > >>>
> > >>>
> > >>> typedef A {
> > >>>=C2=A0 type union {
> > >>>=C2=A0 =C2=A0 type int32 ;=C2=A0 =C2=A0// 1
> > >>>=C2=A0 =C2=A0 type string; // 2
> > >>>=C2=A0 =C2=A0 type B;=C2=A0 =C2=A0// 3, 4, 5
> > >>>=C2=A0 =C2=A0 type identityref { base bar; }=C2=A0 = =C2=A0// 6
> > >>>=C2=A0 }
> > >>> }
> > >>>
> > >>>
> > >>> typedef B {
> > >>>=C2=A0 type union {
> > >>>=C2=A0 =C2=A0 type uint8;
> > >>>=C2=A0 =C2=A0 type uint16;
> > >>>=C2=A0 =C2=A0 type uint32;
> > >>>=C2=A0 }
> > >>> }
> > >>>
> > >>> leaf foo { type A; }
> > >>>
> > >>> YANG allows the member types to be reordered if it d= oes not change
> > >>> the value set accepted by the type.=C2=A0 It is not = clear
> > >>
> > >> I don't think this is true. The only statement in 60= 20bis that is
> > >> related to this issue is the bullet that you cite below,= but IMO
> > >> reordering member types in a union type definition may c= hange the type
> > >> semantics because the receiving side resolves the type a= ccording to
> > >> the order of member types.
> > >>
> > >>
> > >>
> > >> This depends on the format, but non-overlapping member t= ypes can
> > >> change position without changing syntax or semantics. > > >
> > > Yes, but, for instance, the "inet:host" type in RF= C 6991 has overlapping members: "1.2.3.4" is valid as both "= inet:ip-address" and "inet:domain-name".
> > >
> > > Lada
> > >
> > >> The exact member type that matches is not important.
> > >>
> > >>=C2=A0 =C2=A0typedef foo1 {
> > >>=C2=A0 =C2=A0 =C2=A0 type union {
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range &quo= t;1..10"; }
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range &quo= t;11..20"; }
> > >>=C2=A0 =C2=A0 =C2=A0 }
> > >>=C2=A0 =C2=A0 }
> > >>
> > >>=C2=A0 typedef foo2 {
> > >>=C2=A0 =C2=A0 =C2=A0 type union {
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range &quo= t;11..20"; }
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32 { range &quo= t;1..10"; }
> > >>=C2=A0 =C2=A0 =C2=A0 }
> > >>=C2=A0 =C2=A0 }
> > >>
> > >>
> > >>
> > >> Lada
> > >>
> > >> Andy
> > >>
> > >>
> > >>> if new member types can be added in new module revis= ions.
> > >>>
> > >>> If new member types are allowed in typedef B, then t= he relative
> > >>> position of (6) can change, even if typedef A does n= ot change.
> > >>> YANG does not explicitly state if this is allowed or= not.
> > >>>
> > >>> bits and enumerations can be expanded in new revisio= ns, which
> > >>> changes the value set, but existing value and positi= on numbers are
> > >>> not allowed to change.
> > >>>
> > >>> The problematic text is in 6020bis, sec 11
> > >>>
> > >>>=C2=A0 o=C2=A0 A "type" statement may be re= placed with another "type" statement
> > >>>=C2=A0 =C2=A0 =C2=A0 that does not change the syntax = or semantics of the type.=C2=A0 For
> > >>>=C2=A0 =C2=A0 =C2=A0 example, an inline type definiti= on may be replaced with a typedef,
> > >>>=C2=A0 =C2=A0 =C2=A0 but an int8 type cannot be repla= ced by an int16, since the syntax
> > >>>=C2=A0 =C2=A0 =C2=A0 would change.
> > >>>
> > >>>
> > >>>
> > >>> In practice reordering member types would be very ra= re, but the SID
> > >>> numbering would need to remember the member type ord= er for each leaf
> > >>> or leaf-list that resolves to a union type.
> > >>>
> > >>> It doesn't help to tag any other type besides un= ion.
> > >>>
> > >>>
> > >>> Andy
> > >>> _______________________________________________
> > >>> core mailing list
> > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listin= fo/core
> > >>
> > >> --
> > >> Ladislav Lhotka, CZ.NIC Labs
> > >> PGP Key ID: E74E8C0C
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https://www.ietf.org/mailman/listinfo/cor= e
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11440ef4960af905388160a6-- From nobody Mon Jul 25 20:31:10 2016 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 241FD12D13F for ; Mon, 25 Jul 2016 20:31: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_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 lrhElfKY13Jk for ; Mon, 25 Jul 2016 20:31:05 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0101.outbound.protection.outlook.com [104.47.40.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB79012B01D for ; Mon, 25 Jul 2016 20:31: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=zjPF0tjmm69UMJ6fd7DtjCDJdXD+iJD1Qz/7u3p7f6M=; b=gUcY2rFoTyneq2nuJG2Veq4eR4lP4ksB98DYHdbm4fQkGxknRt73ttZEg+hzAb0FyBtFZWtKcJqk3nCFatwu2hE0aVKtuYHuLnBvH8bG/3TdSSpyCbRqWojjjdKfikN1OENMeIwNm6KDcq5yjK5LacRUAE6PwBcThXxQeOHgVoM= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 03:31:01 +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.0544.014; Tue, 26 Jul 2016 03:31:01 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] fixing YANG to CBOR Thread-Index: AQHR4+cJQt79bN4pMU+XasZI/tqalKApIRsAgAAW5YCAAAVwAIAAEGZQgAA1fwCAAAKHgIAAFY2AgAABCYCAAAkKAIAAa+kAgAADD6w= Date: Tue, 26 Jul 2016 03:31:01 +0000 Message-ID: <1B22215B-653D-46FA-A8E8-2437DA454AA5@trilliantinc.com> References: <6DEC3424-1E9F-4B2C-9343-74501ED22ADA@nic.cz>, In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: ec2a5331-bc29-42fd-f98b-08d3b505442d x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:dFYXT79yqmGzBI8Db8ymCOY5HyOkZVjcouthgxmhCWlVXpVXyeV4ktZAI3V8HcAnKzZwSAo4ndJ/yJukS5vgSDcOA3b7hAj/MbIAaEUAUTbH3xDq9fOISl9XHT8uYZRrH/fJP+AWIQTnWYforPaF4+W2cAPtnfzLzS+1iq26D30KBEgYVb2ZdE06+Io+KH2zzIpfd9T+LxM2YRjUFWJELkQK5cnfNy7RS2NcH1A/3J/K9WYEa7u18usuD+lfymlGOT6AVtrlN2jIKZYFVJ1yKJolyxlQqc+v9/Rd9rxOgqk=; 5:EY/OXSnbkFcdVQVwZqyaJLqGf+wsqpbfKKujgYzKwPdwl7aqe43Dc5nDbcuknpQyTlmCIa6ddEfmmNoKrZ84bH0PTD9hlGH4TT9zg/G7O5NmhsSTDf+XJ3vTvCjIRdVxGJANHymOybm5w5yb6tzlDA==; 24:ejLX1T0h1SQlHobougrs+CtO7vYQAJqmO5LfFGWEbJLaJ5LkIdqo9fW6xKf8oWumOZwxg0P9FmlYPuHNvK9Dx/qQ2aprH9sMPD1/bFLwejE=; 7:tsBo2FAtUhb4xcpmXGGcrpIu0LIWhX29LCeduowWO1YkGvHGf1y5FSJ5UUPYHYlCw7miSHu8f3lKfZTz1UmisLiFN6sN+MGSuYh0gnwOeXCgoeaQotrM5pqwSFvJ3CKdIvDZQmw1xOflUoUmRIVgG6TKmlqHXXXyXTJHKEmIu+4vZCnDHyJ+nPFVOufPWoWCFCtUoTTo6Z3+xaI5b5btDjit1hiPSVzMpjg5Gle7y9YNlL7cqfgc+6zkYz5KKYEP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(24454002)(189002)(199003)(13464003)(377454003)(105586002)(7906003)(3280700002)(87936001)(101416001)(3660700001)(7736002)(7846002)(10400500002)(122556002)(19617315012)(86362001)(81166006)(81156014)(5002640100001)(19580405001)(19580395003)(575784001)(66066001)(2900100001)(11100500001)(8936002)(76176999)(82746002)(83716003)(92566002)(54356999)(36756003)(77096005)(33656002)(586003)(16236675004)(6116002)(102836003)(3846002)(8676002)(50986999)(106356001)(68736007)(97736004)(110136002)(99286002)(106116001)(189998001)(4326007)(15975445007)(2906002)(2950100001)(93886004)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.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: multipart/alternative; boundary="_000_1B22215B653D46FAA8E82437DA454AA5trilliantinccom_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 03:31:01.0677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 03:31:09 -0000 --_000_1B22215B653D46FAA8E82437DA454AA5trilliantinccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Le 25 juil. 2016 =E0 23:20, Andy Bierman > a =E9crit : Hi, I think this "union type" corner-case is not bad enough to justify a really complicated design like tracking the order of union type syntax changes. We need to remove order dependencies, not add new ones. I should have realized this is too complicated. So I think the current tagging solution is good enough. Do not change it to count and order the member type-stmts. I will write YANG guidelines in 6087bis to attempt to prevent these corner-cases from occurring in IETF modules. Andy On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lhotka > wrote: > On 25 Jul 2016, at 22:21, Andy Bierman > wrote: > > > > On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka > wrote: > > > On 25 Jul 2016, at 21:00, Andy Bierman > wrote: > > > > > > > > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka > wrote: > > > > > On 25 Jul 2016, at 18:05, Michel Veillette > wrote: > > > > > > Hi Lada, Hi Andy > > > > > > The important questions we need answer to validate the current soluti= on are the following. > > > > > > - In a union, is it valid to define multiple enumerations which reuse= the same value(s) with a different semantic meaning? > > > - In a union, is it valid to define multiple bits which reuse the sam= e position(s) with a different semantic meaning? > > > > IMO, yes, in both cases. I am not saying that it's a good design though= . > > > > > > > > In the following examples, value or position 0 means both white and r= ed which I believe it's invalid. > > > > I don't think so. The member types are checked in the same order as the= y appear in the union's definition, and the first type for which a given va= lue is valid is used. > > > > > > > > That's the issue here. > > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent. > > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string. YANG union was designed only t= o work > > robustly with XML. > > I believe for JSON it is perfectly robust. The general rule should be thi= s: use whatever information you have to determine whether the received valu= e is valid for the first member type. If not, try the second member etc. > > > believe what youi want: > > > type union { > type string; > type int32; > } > > JSON produces different results than XML. > > If client A sets number 42 in JSON, then client B will read back string "= 42" in XML. > If the XML client sets string "42", the JSON client will read back string= "42". > This is the exact same issue facing CBOR conversion In my view, most implementations will eventually use just one encoding, and= this problem won't exist for them. XML, JSON and CBOR in reality pass different information, it is not like UT= F-8 versus UTF-16. Restricting all alternative media types only to features= supported in XML doesn't make much sense. Lada > > > > Lada > > > Andy > > > > > > > > If this is the case, the currently proposed solution to tag some spec= ific datatype (bits, enumeration, identityref, instance-identifier) when u= sed in a union resolve any potential ambiguities. > > > > Yes, I think this is a good idea because otherwise resolving the member= types may be difficult. Moreover, sometimes the sending side might want to= override the resolution algorithm - e.g., if a client wants to set a leaf = with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather= than IP address. > > > > > Can we move ahead with the current solution? > > > > The current solution is just as good and just as broken as the JSON sol= ution, > > and we already moved ahead with that in NETMOD WG. (So I guess that mea= ns yes?) > > > > > > Andy > > > > > > > > ENUMERATION EXAMPLE > > > > > > typedef A { > > > type union { > > > type enumeration { > > > enum white { > > > value 0; > > > } > > > enum black { > > > value 1; > > > } > > > } > > > type enumeration { > > > enum red { > > > value 0; > > > } > > > enum green { > > > value 1; > > > } > > > enum blue { > > > value 2; > > > } > > > } > > > } > > > } > > > > Values 0 and 1 are interpreted as "white" and "black", value 2 is "blue= ". > > > > > > > > BITS EXAMPLE > > > > > > typedef B { > > > type union { > > > type bits { > > > bit white { > > > position 0; > > > } > > > bit black { > > > position 1; > > > } > > > } > > > type bits { > > > bit red { > > > position 0; > > > } > > > bit green { > > > position 1; > > > } > > > bit blue { > > > position 2; > > > } > > > } > > > } > > > } > > > > Ditto. > > > > Lada > > > > > > > > Regards, > > > Michel > > > > > > -----Original Message----- > > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > > > Sent: Monday, July 25, 2016 10:41 AM > > > To: Andy Bierman > > > > Cc: Core > > > > Subject: Re: [core] fixing YANG to CBOR > > > > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman > wrote: > > >> > > >> > > >> > > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka > wrote: > > >> Andy Bierman > writes: > > >> > > >>> Hi, > > >>> > > >>> It seems to me that the only tagging actually needed would be to > > >>> identify the ordered list of member types within a union type. > > >>> > > >>> > > >>> typedef A { > > >>> type union { > > >>> type int32 ; // 1 > > >>> type string; // 2 > > >>> type B; // 3, 4, 5 > > >>> type identityref { base bar; } // 6 > > >>> } > > >>> } > > >>> > > >>> > > >>> typedef B { > > >>> type union { > > >>> type uint8; > > >>> type uint16; > > >>> type uint32; > > >>> } > > >>> } > > >>> > > >>> leaf foo { type A; } > > >>> > > >>> YANG allows the member types to be reordered if it does not change > > >>> the value set accepted by the type. It is not clear > > >> > > >> I don't think this is true. The only statement in 6020bis that is > > >> related to this issue is the bullet that you cite below, but IMO > > >> reordering member types in a union type definition may change the ty= pe > > >> semantics because the receiving side resolves the type according to > > >> the order of member types. > > >> > > >> > > >> > > >> This depends on the format, but non-overlapping member types can > > >> change position without changing syntax or semantics. > > > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapp= ing members: "1.2.3.4" is valid as both "inet:ip-address" and "inet:domain-= name". > > > > > > Lada > > > > > >> The exact member type that matches is not important. > > >> > > >> typedef foo1 { > > >> type union { > > >> type int32 { range "1..10"; } > > >> type int32 { range "11..20"; } > > >> } > > >> } > > >> > > >> typedef foo2 { > > >> type union { > > >> type int32 { range "11..20"; } > > >> type int32 { range "1..10"; } > > >> } > > >> } > > >> > > >> > > >> > > >> Lada > > >> > > >> Andy > > >> > > >> > > >>> if new member types can be added in new module revisions. > > >>> > > >>> If new member types are allowed in typedef B, then the relative > > >>> position of (6) can change, even if typedef A does not change. > > >>> YANG does not explicitly state if this is allowed or not. > > >>> > > >>> bits and enumerations can be expanded in new revisions, which > > >>> changes the value set, but existing value and position numbers are > > >>> not allowed to change. > > >>> > > >>> The problematic text is in 6020bis, sec 11 > > >>> > > >>> o A "type" statement may be replaced with another "type" statemen= t > > >>> that does not change the syntax or semantics of the type. For > > >>> example, an inline type definition may be replaced with a type= def, > > >>> but an int8 type cannot be replaced by an int16, since the syn= tax > > >>> would change. > > >>> > > >>> > > >>> > > >>> In practice reordering member types would be very rare, but the SID > > >>> numbering would need to remember the member type order for each lea= f > > >>> or leaf-list that resolves to a union type. > > >>> > > >>> It doesn't help to tag any other type besides union. > > >>> > > >>> > > >>> Andy > > >>> _______________________________________________ > > >>> core mailing list > > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/core > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --_000_1B22215B653D46FAA8E82437DA454AA5trilliantinccom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1

Le 25 juil. 2016 =E0 23:20, Andy Bierman <andy@yumaworks.com> a =E9crit :

Hi,

I think this "union type" corner-case is not bad enough to
justify a really complicated design like tracking the order
of union type syntax changes.  We need to remove order
dependencies, not add new ones.  I should have realized
this is too complicated.

So I think the current tagging solution is good enough.
Do not change it to count and order the member type-stmts.

I will write YANG guidelines in 6087bis to attempt to prevent these
corner-cases from occurring in IETF modules.


Andy


On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lhotka= <lhotka@nic.cz>= ; wrote:

> On 25 Jul 2016, at 22:21, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 25 Jul 2016, at 21:00, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 25 Jul 2016, at 18:05, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote:
> > >
> > > Hi Lada, Hi Andy
> > >
> > > The important questions we need answer to validate the curre= nt solution are the following.
> > >
> > > - In a union, is it valid to define multiple enumerations wh= ich reuse the same value(s) with a different semantic meaning?
> > > - In a union, is it valid to define multiple bits which reus= e the same position(s) with a different semantic meaning?
> >
> > IMO, yes, in both cases. I am not saying that it's a good design = though.
> >
> > >
> > > In the following examples, value or position 0 means both wh= ite and red which I believe it's invalid.
> >
> > I don't think so. The member types are checked in the same order = as they appear in the union's definition, and the first type for which a gi= ven value is valid is used.
> >
> >
> >
> > That's the issue here.
> > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent.
> > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string.  YANG union was desi= gned only to work
> > robustly with XML.
>
> I believe for JSON it is perfectly robust. The general rule should be = this: use whatever information you have to determine whether the received v= alue is valid for the first member type. If not, try the second member etc.=
>
>
> believe what youi want:
>
>
>    type union {
>        type string;
>        type int32;
>    }
>
> JSON produces different results than XML.
>
> If client A sets number 42 in JSON, then client B will read back strin= g "42" in XML.
> If the XML client sets string "42", the JSON client will rea= d back string "42".
> This is the exact same issue facing CBOR conversion

In my view, most implementations will eventually use just one encoding, and= this problem won't exist for them.

XML, JSON and CBOR in reality pass different information, it is not like UT= F-8 versus UTF-16. Restricting all alternative media types only to features= supported in XML doesn't make much sense.

Lada

>
>
>
> Lada
>
>
> Andy
>
> >
> >
> > > If this is the case, the currently proposed solution to tag = some specific datatype (bits,  enumeration, identityref, instance-iden= tifier) when used in a union resolve any potential ambiguities.
> >
> > Yes, I think this is a good idea because otherwise resolving the = member types may be difficult. Moreover, sometimes the sending side might w= ant to override the resolution algorithm - e.g., if a client wants to set a= leaf with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather than IP address.
> >
> > > Can we move ahead with the current solution?
> >
> > The current solution is just as good and just as broken as the JS= ON solution,
> > and we already moved ahead with that in NETMOD WG. (So I guess th= at means yes?)
> >
> >
> > Andy
> >
> > >
> > > ENUMERATION EXAMPLE
> > >
> > > typedef A {
> > >  type union {
> > >    type enumeration {
> > >      enum white {
> > >        value 0;
> > >      }
> > >      enum black {
> > >        value 1;
> > >      }
> > >    }
> > >    type enumeration {
> > >      enum red {
> > >        value 0;
> > >      }
> > >      enum green {
> > >        value 1;
> > >      }
> > >      enum blue {
> > >        value 2;
> > >      }
> > >    }
> > >  }
> > > }
> >
> > Values 0 and 1 are interpreted as "white" and "bla= ck", value 2 is "blue".
> >
> > >
> > > BITS EXAMPLE
> > >
> > > typedef B {
> > >  type union {
> > >    type bits {
> > >      bit white {
> > >        position 0;
> > >      }
> > >      bit black {
> > >        position 1;
> > >      }
> > >    }
> > >    type bits {
> > >      bit red {
> > >        position 0;
> > >      }
> > >      bit green {
> > >        position 1;
> > >      }
> > >      bit blue {
> > >        position 2;
> > >      }
> > >    }
> > >  }
> > > }
> >
> > Ditto.
> >
> > Lada
> >
> > >
> > > Regards,
> > > Michel
> > >
> > > -----Original Message-----
> > > From: core [mailto:= core-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> > > Sent: Monday, July 25, 2016 10:41 AM
> > > To: Andy Bierman <a= ndy@yumaworks.com>
> > > Cc: Core <core@ietf.org<= /a>>
> > > Subject: Re: [core] fixing YANG to CBOR
> > >
> > >
> > >> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
> > >>
> > >>
> > >>
> > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >> Andy Bierman <a= ndy@yumaworks.com> writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> It seems to me that the only tagging actually needed= would be to
> > >>> identify the ordered list of member types within a u= nion type.
> > >>>
> > >>>
> > >>> typedef A {
> > >>>  type union {
> > >>>    type int32 ;   // 1
> > >>>    type string; // 2
> > >>>    type B;   // 3, 4, 5
> > >>>    type identityref { base bar; }  &n= bsp;// 6
> > >>>  }
> > >>> }
> > >>>
> > >>>
> > >>> typedef B {
> > >>>  type union {
> > >>>    type uint8;
> > >>>    type uint16;
> > >>>    type uint32;
> > >>>  }
> > >>> }
> > >>>
> > >>> leaf foo { type A; }
> > >>>
> > >>> YANG allows the member types to be reordered if it d= oes not change
> > >>> the value set accepted by the type.  It is not = clear
> > >>
> > >> I don't think this is true. The only statement in 6020bi= s that is
> > >> related to this issue is the bullet that you cite below,= but IMO
> > >> reordering member types in a union type definition may c= hange the type
> > >> semantics because the receiving side resolves the type a= ccording to
> > >> the order of member types.
> > >>
> > >>
> > >>
> > >> This depends on the format, but non-overlapping member t= ypes can
> > >> change position without changing syntax or semantics. > > >
> > > Yes, but, for instance, the "inet:host" type in RF= C 6991 has overlapping members: "1.2.3.4" is valid as both "= inet:ip-address" and "inet:domain-name".
> > >
> > > Lada
> > >
> > >> The exact member type that matches is not important.
> > >>
> > >>   typedef foo1 {
> > >>      type union {
> > >>         type int32 { range &quo= t;1..10"; }
> > >>         type int32 { range &quo= t;11..20"; }
> > >>      }
> > >>    }
> > >>
> > >>  typedef foo2 {
> > >>      type union {
> > >>         type int32 { range &quo= t;11..20"; }
> > >>         type int32 { range &quo= t;1..10"; }
> > >>      }
> > >>    }
> > >>
> > >>
> > >>
> > >> Lada
> > >>
> > >> Andy
> > >>
> > >>
> > >>> if new member types can be added in new module revis= ions.
> > >>>
> > >>> If new member types are allowed in typedef B, then t= he relative
> > >>> position of (6) can change, even if typedef A does n= ot change.
> > >>> YANG does not explicitly state if this is allowed or= not.
> > >>>
> > >>> bits and enumerations can be expanded in new revisio= ns, which
> > >>> changes the value set, but existing value and positi= on numbers are
> > >>> not allowed to change.
> > >>>
> > >>> The problematic text is in 6020bis, sec 11
> > >>>
> > >>>  o  A "type" statement may be re= placed with another "type" statement
> > >>>      that does not change the syntax = or semantics of the type.  For
> > >>>      example, an inline type definiti= on may be replaced with a typedef,
> > >>>      but an int8 type cannot be repla= ced by an int16, since the syntax
> > >>>      would change.
> > >>>
> > >>>
> > >>>
> > >>> In practice reordering member types would be very ra= re, but the SID
> > >>> numbering would need to remember the member type ord= er for each leaf
> > >>> or leaf-list that resolves to a union type.
> > >>>
> > >>> It doesn't help to tag any other type besides union.=
> > >>>
> > >>>
> > >>> Andy
> > >>> _______________________________________________
> > >>> core mailing list
> > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/core
> > >>
> > >> --
> > >> Ladislav Lhotka, CZ.NIC Labs
> > >> PGP Key ID: E74E8C0C
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https://www.ietf.org/mailman/listinfo/core
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--_000_1B22215B653D46FAA8E82437DA454AA5trilliantinccom_-- From nobody Fri Jul 29 12:32:04 2016 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 CDBAE12D7C9; Mon, 25 Jul 2016 04:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.207 X-Spam-Level: X-Spam-Status: No, score=-8.207 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, RP_MATCHES_RCVD=-1.287] 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 CtDlaLKNn14V; Mon, 25 Jul 2016 04:32:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 9A48312D7C0; Mon, 25 Jul 2016 04:32:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H9AQDQ95VX/xUHmMZeGgEBAQGCdC2BU?= =?us-ascii?q?gaNJas4gXyGHQKBODgUAQEBAQEBAQNaJ4RcAQEBAQMSKD8MBAIBCA0EBAEBCxQ?= =?us-ascii?q?JBzIUCQgCBAENBQgaiA4BmxKXfgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGK4RMh?= =?us-ascii?q?EKDKoIvBZkoAZhZhVSQIR42g3NuiA4BfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2H9AQDQ95VX/xUHmMZeGgEBAQGCdC2BUgaNJas4gXyGHQK?= =?us-ascii?q?BODgUAQEBAQEBAQNaJ4RcAQEBAQMSKD8MBAIBCA0EBAEBCxQJBzIUCQgCBAENB?= =?us-ascii?q?QgaiA4BmxKXfgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGK4RMhEKDKoIvBZkoAZh?= =?us-ascii?q?ZhVSQIR42g3NuiA4BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,419,1464667200"; d="scan'208";a="163382577" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jul 2016 07:32:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 25 Jul 2016 07:32:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Mon, 25 Jul 2016 07:32:35 -0400 From: "Romascanu, Dan (Dan)" To: Tero Kivinen , Ralph Droms Thread-Topic: [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AQHR46nuMI5CehytXkWhPvcB61QhZqAj+K2AgAUPRgA= Date: Mon, 25 Jul 2016 11:32:35 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7524F552@AZ-FFEXMB04.global.avaya.com> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> In-Reply-To: <22417.54627.526844.924720@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 29 Jul 2016 12:32:01 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 11:32:48 -0000 > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Friday, July 22, 2016 11:12 AM > To: Ralph Droms > Cc: Internet Area; its@ietf.org; roll@ietf.org; Suresh Krishnan; iot- > dir@ietf.org; lpwan@ietf.org; core@ietf.org; 6lo; 6tisch > Subject: Re: [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 >=20 > Ralph Droms writes: > > Seems to me this document could easily be a working group document. > > Why have you decided to publish it as AD sponsored document? >=20 > As this will allocate number for the IETF, not for just one WG, the autho= rs > though it would be better to get as wide coverage for it, meaning having > longer last call time, and advertising it in several different working gr= oups > (who might use it in the future), instead of having it for one WG draft i= n > some WG. >=20 > Also it was not clear which WG it should be in. I think 6tisch is the one= who > might need it first, but 6lo is most likely also going to using it etc. > -- > kivinen@iki.fi >=20 The last argument is relatively easy to overcome. As both 6tisch and 6lo be= long in the INT area, this could be a good candidate for a intarea WG docum= ent. I also have a slight preference for this path, as a WG document has ty= pically a better level of scrutiny and review.=20 Regards, Dan From nobody Fri Jul 29 14:09:34 2016 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 7DA2012D824 for ; Fri, 29 Jul 2016 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_NEUTRAL=0.779] autolearn=ham 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 SFehY5UNUn0Y for ; Fri, 29 Jul 2016 14:09:30 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 49D8412D513 for ; Fri, 29 Jul 2016 14:09:30 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id iw10so34257860pac.2 for ; Fri, 29 Jul 2016 14:09:30 -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:references:cc:to; bh=sc7nQlQa7j1BMor0lXcrYbqANKUJbYQOxNaxzs2xxwU=; b=l2EUE4vWcn1Y8nDX9EJ21LXtRZk+Id3nSCfp4XqX4YjjEX1LBiYJziGZnLJW9fArN4 elDc54JlW3Rap3Yo0Qi6RhMGc8ZuBuwVxCB/UKb330BgY8/u+PIVD8SOJobUIPsrGP9W qXIYtRjqutWzlrSuWKBH33c+DxIo9nId2cUR3Y8FVo78OYND0USJLp0fy30yABTtq+MJ n7fAeYyXJteBZMnNKxP5mhpGSvkQAtUEYa6PSUE8b70WUo29WUfbcTHsMdLJ2K6yqnoD YFq3xN6WAxU4AKkzDvJTAI0KVh6LEePfzQz9KHvINTBrjpnizhZQiNoME/jL0ToideON gElw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:cc:to; bh=sc7nQlQa7j1BMor0lXcrYbqANKUJbYQOxNaxzs2xxwU=; b=hNTVBxN/HhVgPsWvaeIuEpxSC7ntkgmSwBX7dz9pvQ9uhzZ8c1vrtN3Lu9hMQODhsV oaW9TS0O65xvF2iygetSdfaw0jcXZceIRsU3vf5oSTNn4lfmHHT4A9e8ECUpsukBFJxj xS+ecIWZgY6JCf8jHHVxfF3tWxik7pRSiFkVff+sLXzS02guR2krzXCmygaBkpAnFBMB jdPWHA4braNUKrKNwgx5d58vS6jgNvPppupODbIkfvkBo1PqpENfjhApH+26YO+Oupcs 2T1vHUCpXRkj4y7FdsHuyRBcY3uJmOl3FYfi2qSKC7A2AaFWVzODzFIZUy0BnArUPI8q 0Wyg== X-Gm-Message-State: AEkoouujXK4QGXEUvHdA16CJuv1qE6UK4aJ+gM7+d/shvoUeM7eiLpa/y2oSryedmIFKD4Ef X-Received: by 10.66.72.40 with SMTP id a8mr73054216pav.15.1469826567058; Fri, 29 Jul 2016 14:09:27 -0700 (PDT) Received: from [10.0.0.20] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id bw10sm7447431pac.27.2016.07.29.14.09.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jul 2016 14:09:26 -0700 (PDT) From: Michael Koster Content-Type: multipart/alternative; boundary="Apple-Mail=_333D9F30-582C-490D-B642-029039F5F392" Message-Id: <7B6BAADC-2964-4792-BDC2-30737DDE1B5C@smartthings.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Fri, 29 Jul 2016 14:09:24 -0700 References: <20160729205020.27053.15016.idtracker@ietfa.amsl.com> To: T2TRG@irtf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: [core] Fwd: New Version Notification for draft-koster-t2trg-hsml-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jul 2016 21:09:32 -0000 --Apple-Mail=_333D9F30-582C-490D-B642-029039F5F392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have submitted an internet draft for T2TRG describing the HSML media = type for hypermedia based machine interaction. HSML combines and extends data models from SenML and CoRE Link-Format, = and defines an abstract transfer layer + interaction model. This is a standalone version and ongoing update of the "Hypermedia = Collection" work that was removed from the CoRE Interfaces document. Best regards, Michael https://datatracker.ietf.org/doc/draft-koster-t2trg-hsml/ = https://tools.ietf.org/html/draft-koster-t2trg-hsml-00 = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-koster-t2trg-hsml-00.txt > Date: July 29, 2016 at 1:50:20 PM PDT > To: "Michael Koster" >=20 >=20 > A new version of I-D, draft-koster-t2trg-hsml-00.txt > has been successfully submitted by Michael Koster and posted to the > IETF repository. >=20 > Name: draft-koster-t2trg-hsml > Revision: 00 > Title: Media Types for Hypertext Sensor Markup > Document date: 2016-07-29 > Group: Individual Submission > Pages: 48 > URL: = https://www.ietf.org/internet-drafts/draft-koster-t2trg-hsml-00.txt > Status: = https://datatracker.ietf.org/doc/draft-koster-t2trg-hsml/ > Htmlized: https://tools.ietf.org/html/draft-koster-t2trg-hsml-00 >=20 >=20 > Abstract: > The scale and scope of the worldwide web has been in part driven by > the availability of HTML as a common serialization, data model, and > interaction model for structured resources on the web. By contrast, > the general use of appropriate hypermedia techniques for machine > interfaces has been limited by the lack of a common markup format = for > serialization and exchange of structured machine resources and > sensor/actuator data which includes or embeds standardized = hypermedia > controls. The IRTF Thing to Thing Research Group [T2TRG] has a > charter to investigate the use of REST design style [REST]for = machine > interactions. The W3C Web of Things Interest Group [W3C-WoT] are > investigating abstract hypermedia controls and interaction models = for > machines. Machine optimized content formats exist for web links > [RFC5988] [RFC6690] and for data items [I-D.ietf-core-senml]. >=20 > Structured data which contains both links and items is known as the > collection pattern. This draft describes media types for > representation of machine resources structured as collections. A > simple, reusable data model is described with a representation > format, using a well known set of keywords to expose hypermedia > controls, which inform clients how to perform state transfer > operations on resources. The underlying assumptions regarding > transfer layer processing are specified in this document. The HSML > media type described in this document is compatible with SenML and > CoRE Link-format by reusing the keyword identifiers and element > structures from these content formats. Representations of HSML > document content may be obtained in CoRE Link-Format and SenML > content formats. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_333D9F30-582C-490D-B642-029039F5F392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I have submitted an internet draft for T2TRG describing the = HSML media type for hypermedia based machine interaction.

HSML = combines and extends data models from SenML and CoRE Link-Format, and = defines an abstract transfer layer + interaction model.

This is a standalone = version and ongoing update of the "Hypermedia Collection" work that was = removed from the CoRE Interfaces document.

Best regards,

Michael

https://datatracker.ietf.org/doc/draft-koster-t2trg-hsml/

https://tools.ietf.org/html/draft-koster-t2trg-hsml-00


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-koster-t2trg-hsml-00.txt
Date: = July 29, 2016 at 1:50:20 PM = PDT
To: = "Michael Koster" <michael.koster@smartthings.com>


A = new version of I-D, draft-koster-t2trg-hsml-00.txt
has = been successfully submitted by Michael Koster and posted to the
IETF repository.

Name: = draft-koster-t2trg-hsml
Revision: 00
Title:= = Media Types for Hypertext Sensor Markup
Document = date: = 2016-07-29
Group: Individual Submission
Pages:= = 48
URL: =            https://www.ietf.org/internet-drafts/draft-koster-t2trg-hsml-00= .txt
Status: =         https://datatracker.ietf.org/doc/draft-koster-t2trg-hsml/Htmlized:       https://tools.ietf.org/html/draft-koster-t2trg-hsml-00


Abstract:
=   The scale and scope of the worldwide web has been in part = driven by
  the availability of HTML as a = common serialization, data model, and
=   interaction model for structured resources on the web. =  By contrast,
  the general use of = appropriate hypermedia techniques for machine
=   interfaces has been limited by the lack of a common markup = format for
  serialization and exchange of = structured machine resources and
=   sensor/actuator data which includes or embeds standardized = hypermedia
  controls.  The IRTF Thing to = Thing Research Group [T2TRG] has a
  charter to = investigate the use of REST design style [REST]for machine
=   interactions.  The W3C Web of Things Interest Group = [W3C-WoT] are
  investigating abstract = hypermedia controls and interaction models for
=   machines.  Machine optimized content formats exist for = web links
  [RFC5988] [RFC6690] and for data = items [I-D.ietf-core-senml].

=   Structured data which contains both links and items is known = as the
  collection pattern.  This draft = describes media types for
  representation of = machine resources structured as collections.  A
=   simple, reusable data model is described with a = representation
  format, using a well known set = of keywords to expose hypermedia
  controls, = which inform clients how to perform state transfer
=   operations on resources.  The underlying assumptions = regarding
  transfer layer processing are = specified in this document.  The HSML
=   media type described in this document is compatible with = SenML and
  CoRE Link-format by reusing the = keyword identifiers and element
  structures = from these content formats.  Representations of HSML
=   document content may be obtained in CoRE Link-Format and = SenML
  content formats.




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

The IETF Secretariat


= --Apple-Mail=_333D9F30-582C-490D-B642-029039F5F392--