From nobody Wed Sep 1 04:52:44 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510E33A08E6 for ; Wed, 1 Sep 2021 04:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDK_3eBUF1sO for ; Wed, 1 Sep 2021 04:52:37 -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 EDEED3A08D7 for ; Wed, 1 Sep 2021 04:52:36 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) for core@ietf.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1mLOnA-001fSB-Lf; Wed, 01 Sep 2021 13:52:32 +0200 Received: from [5.61.188.191] (helo=[192.168.101.6]) by inpost2.zedat.fu-berlin.de (Exim 4.94) for core@ietf.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from ) id 1mLOnA-001X9Z-Eo; Wed, 01 Sep 2021 13:52:32 +0200 To: "core@ietf.org" From: Martine Sophie Lenders Message-ID: <23deb329-d20f-21ff-8178-7df494763167@fu-berlin.de> Date: Wed, 1 Sep 2021 13:52:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Original-Sender: m.lenders@fu-berlin.de X-Originating-IP: 5.61.188.191 Archived-At: Subject: [core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 11:52:43 -0000 Dear CoRE-WG, we would like to present our proposal for DNS over CoAP (DoC): https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/ DoC allows for the sending of DNS messages over CoAP, using GET, POST, and FETCH methods. Similar to DoH in the wider Internet, DoC aims for providing encrypted DNS message exchange but for constrained IoT devices, utilizing DTLS or OSCORE, Comments on our proposal are very welcome! Specifically, we would like to discuss the following items: 1. How should caching hints in DNS (TTL) relate to CoAP (Max-Age) and vice versa? How should relative times be handled in general when using caching [1]? Christian Amsüss previously kicked this discussion off on the CoRE mailing list [2]. 2. Should we only specify the usage of FETCH and abandon GET and POST in DoC [3]? (a) GET introduces the disadvantage that all requested data (such as a DNS query) needs to be carried within the URI, so block-wise transfer is not possible. Additional overhead occurs since the data needs to be converted into a URI format. (b) POST, on the other hand, does not allow for en-route caching of successful responses. In contrast to HTTP, however, CoAP provides the FETCH method, which allows for both adding data to the body of a request and caching of successful responses. (c) There is one concern regarding FETCH. Various CoAP implementations do not support FETCH [4] (maybe because FETCH was added later to CoAP). This could hinder deployment of DoC or could lead DoC implementations that are not spec-compliant, because implementers just use GET or POST when FETCH is not available. Looking forward to your feedback! Thanks, Martine on behalf of the co-authors of draft-lenders-dns-over-coap [1]https://github.com/anr-bmbf-pivot/draft-dns-over-coap/issues/5 [2]https://mailarchive.ietf.org/arch/msg/core/CzRQTARwPgIwJN0s_kmlLRCNMKY [3]https://github.com/anr-bmbf-pivot/draft-dns-over-coap/pull/8 [4]https://coap.technology/impls.html From nobody Wed Sep 1 06:20:32 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13063A1162 for ; Wed, 1 Sep 2021 06:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9kynGBmvdh9 for ; Wed, 1 Sep 2021 06:20:05 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007133A115E for ; Wed, 1 Sep 2021 06:20:04 -0700 (PDT) Received: from smtpclient.apple (dynamic-218-v.informatik.uni-bremen.de [134.102.218.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4H04RK4xPcz2xYT; Wed, 1 Sep 2021 15:19:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <23deb329-d20f-21ff-8178-7df494763167@fu-berlin.de> Date: Wed, 1 Sep 2021 15:19:57 +0200 Cc: "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <23deb329-d20f-21ff-8178-7df494763167@fu-berlin.de> To: Martine Sophie Lenders X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 13:20:30 -0000 Hi Martine, I=E2=80=99ll look at more details later, but have an immediate opinion = on this one: > On 1. Sep 2021, at 13:52, Martine Sophie Lenders = wrote: >=20 > (c) There is one concern regarding FETCH. Various CoAP = implementations > do not support FETCH [4] (maybe because FETCH was added later to = CoAP). > This could hinder deployment of DoC or could lead DoC implementations > that are not spec-compliant, because implementers just use GET or POST > when FETCH is not available. CoAP implementations that do not support FETCH need to be fixed. If applications were to wait until everyone has implemented FETCH, there = never would be an application that uses FETCH, so there would be no need = to implement it. Since implementing FETCH is near trivial if you already have implemented = POST, maybe getting a list of CoAP implementations that still don=E2=80=99= t do FETCH and generating fixes for them would be a good parallel = activity to standardising DoC. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 1 06:38:07 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7984D3A11EA for ; Wed, 1 Sep 2021 06:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt3lizQ4iiJE for ; Wed, 1 Sep 2021 06:38:00 -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 6C15E3A11E5 for ; Wed, 1 Sep 2021 06:38:00 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1mLQRA-002eWr-TY; Wed, 01 Sep 2021 15:37:56 +0200 Received: from [5.61.188.191] (helo=[192.168.101.10]) by inpost2.zedat.fu-berlin.de (Exim 4.94) with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from ) id 1mLQRA-001khm-M9; Wed, 01 Sep 2021 15:37:56 +0200 To: Carsten Bormann Cc: "core@ietf.org" References: <23deb329-d20f-21ff-8178-7df494763167@fu-berlin.de> From: Martine Sophie Lenders Message-ID: Date: Wed, 1 Sep 2021 15:37:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Original-Sender: m.lenders@fu-berlin.de X-Originating-IP: 5.61.188.191 Archived-At: Subject: Re: [core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 13:38:06 -0000 Hi Carsten, Am 01.09.21 um 15:19 schrieb Carsten Bormann: > [...] > >> On 1. Sep 2021, at 13:52, Martine Sophie Lenders wrote: >> >> (c) There is one concern regarding FETCH. Various CoAP implementations >> do not support FETCH [4] (maybe because FETCH was added later to CoAP). >> This could hinder deployment of DoC or could lead DoC implementations >> that are not spec-compliant, because implementers just use GET or POST >> when FETCH is not available. > CoAP implementations that do not support FETCH need to be fixed. > If applications were to wait until everyone has implemented FETCH, there never would be an application that uses FETCH, so there would be no need to implement it. > > Since implementing FETCH is near trivial if you already have implemented POST, maybe getting a list of CoAP implementations that still don’t do FETCH and generating fixes for them would be a good parallel activity to standardising DoC. I came prepared [1] (but did not want to include this table initially to not overwhelm everyone with the info dump ;-))! Our preliminary judgement call was that there are for the most part 2 types of CoAP implementations that are in that state: (1) who have a stale development status anyways (last change >1 year ago) or (2) where it is not needed fort the use-case anyways (e.g. wakaama). Of the one remaining, I agree with your proposal to generate fixes for FETCH support down the line. Best Regards, Martine > Grüße, Carsten [1] https://gist.github.com/miri64/48d83316afd1d5e600ed2ec0bbab3624 From nobody Fri Sep 3 12:23:50 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC823A2A50; Fri, 3 Sep 2021 12:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.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 E-fvEB7vfvDw; Fri, 3 Sep 2021 12:23:43 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70059.outbound.protection.outlook.com [40.107.7.59]) (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 4E0DD3A2A4C; Fri, 3 Sep 2021 12:23:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BXk2e6dF3E2HqnFy0JQeOcxgv6t/lmBSVG1BB0WTbyLI4DN/8Myy16pcxbC4TEsxd6Q+0aghWQER3hhg1lPH1z5M0xP0tf81YlTpN2EJiDP9O6VCvrUrOspdycr+V/0NbGJQmxPo3owK8iJHCQ+lT3SNu+jBgwP7gUNpwd2V4HyL7zvmeUrqmcui0Kr66o7njFzLnJ2NrAhStSG0ZuPCqQpY2qNP4Kns+LKJgXyJHZyBXbxCtxLfPG6sxcqvLaGJe8n7xCfQp31jIBX6gkCXngy2mbDkWenQkuzb/Tvy095i2hc5vO+Eb55Juo4g2/3JitqDace3s7IlTrNYNx69Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I1lo7m4V4lZ4+Z1zY98LJTMAioD21XNUq3w5SQDhidU=; b=gH5agNsd7osZrBpQmsMf/UthNVitACT/PAp7VaJ8vjVOmddvcZc2OaTHYsmkLPF2KQEmQw8YiRED6ddGRSX0H/NAqjzkQJk2lr23Ihv4Yxo1xmoA4KTRkPCrvFKwLOntqi39MRiaCUNHQMk4Q15nQd+zFKLoXKNyV2tRgcB28bcpLZl21mBaYWD55t/1KYPjhjZSwFn/JYbFMTVepg+/kaOaBzk3cEKp13DuqhYhPWIJyJCLf9Qka5aM6OEHnfleybOwP7LKjQUBCTxeHZMuLUm9/5HitnTFAO/FHG287K2EDvRWDwiOdnY3pb0ksfJlE94EgAY3wXvxJIqstDvPsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I1lo7m4V4lZ4+Z1zY98LJTMAioD21XNUq3w5SQDhidU=; b=QCp2iLtSo12bez8gNBZkH6MkpXH1RSCII9vXOx5AYPv9Tabk1cylJR9J3dmMO8C0dGK3ogvhoodTztBblZbvYP9t4q/T15BKsKfdWFN/ImlHEXWPCGoM1Qr7ofk27fgYnqdUj9sfwEXD35fXFZN15UffZpntaDNQAgP7uDHKGIU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uniovi.es; Received: from DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) by DBAPR08MB5704.eurprd08.prod.outlook.com (2603:10a6:10:1a1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Fri, 3 Sep 2021 19:23:38 +0000 Received: from DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395]) by DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395%8]) with mapi id 15.20.4478.022; Fri, 3 Sep 2021 19:23:38 +0000 Cc: garciadan@uniovi.es, EMU WG , "ace@ietf.org" , Rafa Marin-Lopez , core@ietf.org To: =?UTF-8?Q?Christian_Ams=c3=bcss?= References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> From: Dan Garcia Carrillo Message-ID: Date: Fri, 3 Sep 2021 21:23:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: LO2P265CA0022.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::34) To DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from DansMacBookPro.local (212.102.48.73) by LO2P265CA0022.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Fri, 3 Sep 2021 19:23:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8eff5d37-32bc-4c2a-6a2e-08d96f10548b X-MS-TrafficTypeDiagnostic: DBAPR08MB5704: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fYrj/mgApcZZyRrabeML3tJY3Tx1gYzmOxN3Rzh++NrGSDaUF3DP7ytAChrLk4vqQTKrYvYRPCPU5GtyxLx2xhylfp2ZqBTot9y85oMz8uYKJWqPx2WZCX8LBVV5qRRVuvEFv7jTlkd3Dk6DtCTOyy3Q7XbD2owqj5RBuQM8QWmhlQD7mjVuFzvsmFp1diXElTH2T9jrit2xnplUJMgbh/XPYMMbalnwW0VR8Ita/R1Px3xSwC6pSMM80xbEZkap1seSZU9DsJmEBtCO7O0Jr6TP6XWoGkM0DpDsCLBjtJDwWGCurYdiqbonI7s2OVfRNPc6yA/+KnQFLBjJsOaak8k6WY4wEoNv4KA3rIFpS6mm0VNW2w8NDL+AJYbrj4DNgCJoEmH7Fn9Hx3ihssmZV0K9Xbm0g9FyoeWDz06yQayFO0vKUAJ0J/UwL7OiPCwAtpdFx/UZYsYbhLFJa2hTYnPkxNR3YmdK9wDfSy40Xp2/hZnOGCbVOwdpfOkVKmkoxWC1GUq4mZ95DpW6FkQwE9xzB2rtynMy6LfKE8GJZ8cID7XfSyjdw+7bnIp5jrCnA0EF2n2y++024Ial1ov2Pa3N5IJV5Ds2L4SDEe7EIudvzIu4v+bATr0ugs3SqNRVtyP9KKAJTelM/tbaUaFzlE0XUokghnSqo8ntVSbH0RRmOKiYibRiQ+orkCABR9+sMeIubaTsMeRLGiqqzxYWVzXKK4lq4HeCfF0oFvbAW4LBV+VzKCy6vk9cIkr+q7gYqrIkPvonqsQLidnvkssnayJ2EOoowjTi+nkllopzSc8hqCrFtp9X2Ld6/kTZ9rJgcdtgkH0wxZKNK+y4yhstpQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB6202.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(2906002)(316002)(186003)(31696002)(36756003)(38350700002)(66476007)(66946007)(6486002)(86362001)(30864003)(66556008)(6506007)(53546011)(8676002)(26005)(966005)(66574015)(6512007)(5660300002)(52116002)(2616005)(83380400001)(54906003)(8936002)(6666004)(4326008)(31686004)(38100700002)(956004)(508600001)(6916009)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0VPY2tSU0hLVEIzSzlKbG5YWG9nNVFQbTJ1L3IxNURrSTdQajlYZzMyUUhx?= =?utf-8?B?U0U4NWlHelpUcWkwV3J5S3Y0ZkhNck91Z0N6S1NsYmFqRnFzZEU4ekoxYzd5?= =?utf-8?B?WHVwWEVUSTFOcVFpMTlHd0tHM1IxZGJhVzB5d0VST0hMQTNJL3V1RGdIdjRP?= =?utf-8?B?YzhSMXhHekhIbEdFRTk4TXZWUGFZV1FHVGZZSklCSldoNUJ2VHNtajdTOFlq?= =?utf-8?B?bGlDTHRhT1FRanlsTmkrYzJ0dUZjM0pCZmlaSkFVUStVaWdRKzcyTE5MMDA0?= =?utf-8?B?RWxhWFJidUsxWTlvU0JCV2k0WlNDYmNXUFFEUVlBckV3eVJPQTdBZHF0a1Q4?= =?utf-8?B?QTh3WHRyMlpacE14SXY4WXcrUENNTGRLaWN4UHVVaXFLYnR2bFFMMXA4TkZ5?= =?utf-8?B?UXZHVkcyRFd4S25MR3dRR1psVGVKNmc3dHdDUlFNZkIvdDcvNEJRdEdCeDZv?= =?utf-8?B?TEJaYnVUTFBJZkIzUkJkeTQrNHlnbEJMTEJQejNTWG1ybERnQ0xKWlZUQTVG?= =?utf-8?B?N1dOWXFva1NVTWcrZ282NmtkWFJEdXhFUEtQdGlkM0loaW1NVHl1dEJsWnM2?= =?utf-8?B?a2I0cDU4MGw5amFIK0tLNVlrRFpaZXJDSHNnZ2h6RWtJV2RPa00vc204Y1Z1?= =?utf-8?B?UXBrWkluRFVMZXZucXYxeTlOZVh0WDBSQ2xlWkpWcE44TDVwTGcxMDhsVkt1?= =?utf-8?B?eDhWOXZpbHFLcTBsYWdUeSs3VkQrT2tWMDhubEM4dER4MmdqY2hpOGdvL0I4?= =?utf-8?B?bklBVjJRR1MvdThORnR2UXpsNHljbUtpaldHcG04Z0pQdno3aFhVcGFlVHRE?= =?utf-8?B?WjdjUUcrZHVFaEg5MXNYa3Mzdm5RdHJhWnlRaWZ1Z0RrTHBMOXFjQ0N5MkhU?= =?utf-8?B?MnZCTlpxam55SnhBNWU0QzFzNUEwWDJDSVFEOVlSemNiV2pPem50LzExaHd0?= =?utf-8?B?YWh1VG5IMDB5MjVqRVM0UjQyV0wrVjRXdytud1FKWkJjR0ZjZXA3T2J2N2lk?= =?utf-8?B?RTNrdDJZcjhUaFZxeWlxZkhIUHkvcDU1djFySWZoWjl2MzZkd09HR2ZtRkZ6?= =?utf-8?B?T2VxQmljSVk1S0xPekFmTW96TU1oUXJFaWdrbldldUZURGtMMnVtOVFWVnly?= =?utf-8?B?ZzFScGNDU1Z6bVpaWHlFVTZocFZTSzN5WU9tT3hHeEMyaERBcmNwYTg0bXpp?= =?utf-8?B?dlFiU3lYZ2UyQS94Nm04NW9ib1FKN2s0M3NNd1ZhSkNnVW1qM3VqWWRhalU2?= =?utf-8?B?R0ZEdjVyUzU0c2lmYXl3UFMwdzlrM2hjSGxpZjViS3NSYnhtMHMvTGlYbmVi?= =?utf-8?B?NU42TGxNODVTaGRwODRNZXRtNjk3Q003R01OWFZ5NWVSYXBSZldjVGxYK3pi?= =?utf-8?B?M2kvQko2amlrWDc4eHhvWDU5RFVuZ1p2aVA5MzNHdzVqcUx2ZjFyUVhHM0Fp?= =?utf-8?B?N2pwc3MwRU85RUhacWtOcUhqM2xQb1dKL2tULzNuYjJFRjlKVEM5K0g3ckdW?= =?utf-8?B?aW9FWG8yMURwNVlWeHFMbkpQNmpiMC9aeURrSS8xazJLUmFEOU1rdWtZMjJU?= =?utf-8?B?MUxnd2hjZ0FucWxzQURTMlNCUjdNN3ZiaW81N1o4MFc1cWxQL0NrVUkxaDNp?= =?utf-8?B?Wmt3ZE9TeW43NmxGLysvL3RQR2l2bEY1QWR5OUUxK2hVUEgyMnhmRVpsb0ZB?= =?utf-8?B?VmNZSkhFNlRwV1BpbkxOWnJIei9ja1BqeFpMQ3VoZGtzRk5rVXRHajk1NTF5?= =?utf-8?Q?KFkb/ZHsoFFkHY8NuKbv9W3Ti54ijGKbSHX3M9R?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-Network-Message-Id: 8eff5d37-32bc-4c2a-6a2e-08d96f10548b X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2021 19:23:37.9881 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PEAfkvBpWxkTskohVjP0WAGDkNdgfvvid+xRc+LDxliPeaMsY954Vhbd8wpPUg7QLdZjP5RXZ4OtAqT8VGafyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5704 X-MS-Exchange-CrossPremises-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 212.102.48.73 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DBAPR08MB5704.eurprd08.prod.outlook.com Archived-At: Subject: Re: [core] [Ace] CoAP-EAP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 19:23:49 -0000 Dear Christian, Thank you for your detailed review. You are raising indeed very interesting points. Just came back from vacation and we will respond as soon as possible. Best Regards. On 16/8/21 16:40, Christian Amsüss wrote: > Hello CoAP-EAP authors and involved groups, > (CC'ing core@ as this is a review on CoAP usage), > > > I've read the -03 draft and accumulated a few comments; largely in > sequence of occurrence. > > Over all, the protocol has improved a lot since I've last had my eyes on > it. Several comments below are about how prescriptive the message types > are. I believe that this should be resolved towards generality, or else > the usability of this protocol with generic CoAP components will be > limited (or, worse, still implemented and then surprisingly > incompatible). > > > * Figure 1: For readers new to the topic of EAP, I think that it might > be useful to extend this to cover also the EAP server or AAA > infrastructure, if that can be covered without too much complication. > > Suggestion (without illusions of correctness): > > IoT device Controller > +------------+ +------------+ > | EAP peer/ | | EAP auth./ |+-----+[ AAA infra. ] > | CoAP server|+------+| CoAP client|+-----+[ EAP server?] > +------------+ CoAP +------------+ EAP? > > \_____ Scope of this document _____/ > > Figure 1: CoAP-EAP Architecture > > * `/.well-known/a`: [note: May be irrelevant, see next two items] > > If the designated experts don't go along with a > very-short option (I'd kind of doubt you'd get anything shorter than > `/.well-known/eap`) and if that puts you up against practical limits, > using a short-hand option might be viable. > > So far there's no document for it and I've only pitched the idea > briefly at an interim[1] (slides at [2]), but if push comes to shove > and you need the compactness, let me know and that work can be > expedited. > > [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core > [2]: https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 > > * Discovering the Controller is described rather generically, but with > CoAP discovery as an example. > > As long as CoAP discovery (as per RFC6690/7252) is used, that already > produces a URI, which can contain any path the server picked. It has > thus no need for a well-known path. > > Are there other discovery options envisioned that'd only result in a > network address? Only for these, a well-known path would make sense. > (And then it's up to the envisioned client complexity if one is > warranted). > > For comparison, RD[3] explores some of the options. A path may be > discovered using CoAP discovery as `?rt=core.rd*` right away from > multicast. Or an address may be discovered using an IPv6 RA option, > with CoAP discovery acting on that address. Only for cases of very > simple endpoints, it also defines a `/.well-known/rd` name that can be > used without CoAP discovery (and thus link parsing) happening > beforehand. The same rationales may apply for EAP (the devices using > the resource are mostly servers, otherwise, and send a very simple > request to start things), but again that's only if the address was > discovered through something that's not CoAP discovery already. > > [3]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte > > * For message 1, why does this need to go to a fixed resource? There has > been previous communication in message 0 in which the resource could > have been transported. > > Granted, it's not as easy as in messages 2-to-3 etc where the > Location-* options are around, but the original message 0 POST could > just as well contain the path in the payload. > > There are options as to how to do that precisely (just the URI > reference in text form, or a RFC6690 link, or a CBOR list of path > segments, or a CRI reference[4] -- if the latter were in WGLC already > I'd recommend it wholeheartedly), but either of them would stay more > true to the style of the other messages in that the earlier message > informs the path choice of the next ones. > > An upside of this would be that it allows better behavior in presence > of proxies (see later), even though it may be practical to not spec > that out in full here. (But the path would be open for further specs, > and they'd just need some setting down of paving stones). > > [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ > > * (Bycatch of suggesting URIs): It may be worth mentioning that the > NON's source address can easily be spoofed. Thus, any device on the > network can trigger what the authenticator may think of as a > device-triggered reauthentication, and the device may think of as an > authenticator-triggered reauthentication (provided it works that way, > see below when reauthentication is mentioned again). > > Even sending full URIs in message 0 would be no worse than the current > source spoofing. > > Sending URI paths in message 0 would make this minimally better > because the attacker would need to guess (or observe from the network) > the CoAP server's path. > > * In 3.1 General flow, the message types are described in high detail. > CoAP can generally be used with different transports (some of which > don't even do NON/CON). Also, while I think it's reasonable to expect > that a CoAP implementation can deal with requests coming in as either > CON or NON, I'd expect that some don't offer all possible choices to > applications. (A very constrained device may only send NON requests, > or an implementation may decide autonomously whether to send > piggy-backed or not). > > Can you clarify as to what of this is meant to be normative and what > exemplary? > > My recommendation is to state that what is prescribed is the flow of > requests and responses (which is what CoAP provides to the next > layer), while notes on reliable transmission are recommendations for > CoAP-over-UDP/DTLS. A similar statement, which I like a lot, is > already in 3.2 on error handling. > > (I can serve examples of how subtle incompatibilities can develop but > go unnoticed, but I'd only go through that if this is all really > intended to be prescriptive). > > * The reuse of the empty token only works if the peers actually respond > with piggy-backed responses, so that's where enforcing the above rules > would give some benefit -- but at the cost of losing existing CoAP > implementations that make no guarantees as to how the response will be > sent as long as it's reliable. > > * Proxying: As it is right now, this protocol just barely works across > proxies, and only if they support CoAP-EAP explicitly. (And while it > may sound odd to even consider that, bear in mind that they are used > in a very similar way in RFC9031). > > While it's a bit open whether all CoAP-based protocols should > reasonably be expected to work across proxies or not, a remark (maybe > before 3.1?) that "If CoAP proxies are used between EAP peer and EAP > authenticator, they must be configured with knowledge of this > specification, or the operations will fail after step 0." > > * 3.2.2: The use of RST is rather unusual here, for the same reasons as > the prescriptive message types. > > A response of 5.03 (Service Unavailable) has roughly the same size, > is available independent of transport, and on most libraries *way* > easier to use, if they support sending an RST to a well-formed message > at all. > > (Furthermore, the sender of the 5.03 can encode an estimate of the > remaining unavailable time in the Max-Age option; not sure if that is > of any help here). > > * 3.3.1: "received with the ACK", "sends piggybacked response" are, > again, overly specific. "received in the last response" and "sends a > response" could work as replacements even if message types are > presecriptive. > > * 3.3.1: "after the maximum retransmission attempts, the CoAP client > will remove the state from its side". > > So the device that's being kicked from the network can delay its own > eviction for about a minute as long as it doesn't answer? > > * 3.3.2: Is reauthentication always triggered by the EAP peer, or can it > also be triggered by the authenticator? If the latter, will the > authenticator use /.well-known/a again, or POST something to the > resource from where it'd DELETE in 3.3.1? > > * cryptosuites: What's the upgrade model of that hardcoded list? As it > is now, it looks pretty static, so updates would be through updates of > this document. The obvious alternative is an IANA registry with > ranges, policies and the usual pros and cons. > > Then again, this is not the first nor last time AEAD algorithms with > their parametrization and hash functions are assigned aggregate > numbers (I-D.ietf-lake-edhoc comes to mind which has asymmetric algs > in the mix too; probably others as well); can we deduplicate this with > anything? (Possibly by bringing this up with COSE or OSCORE people). > > * OSCORE derivation: Is it cryptographically necessary to derive *both* > a master secret and a master salt through KDF? (Sounds like a > needless step to me, as both only go into KDF once more when the > actual OSCORE parameters are derived). I *guess* there's a good reason > why the MSK is not used as the OSCORE IKM right away and the CSO as > OSCORE master salt, but it'd help to have at list a comment here on > why that's needed. > > (It may be useful to compare this step to the HKDF steps in OSCORE; > their info element is always a 5-element array with a 4th "type" > element of "Key" or "IV"; other extractions might just hook in there > with different type values, maybe, and save everyone an extra handling > step). > > * OSCORE ID derivation: > > * Randomly assigned full-length ideas look like an odd choice. They > are excessively long (nonce length - 6 is 7 for the MTI > AES-CCM-16-64-128 and shorter for other current ones, but I doubt > that keeping the IV *short* is necessarily a design criterion for > future algorithms). > > What commonly happens here (eg. in the ACE-OSCORE profile, or in > EDHOC) is that each party picks a recipient ID out of its pool of > currently unused IDs. This makes for shorter keys, and allows the > client to be sure that no two peers use the same context. > > Any chance something like that can still make it in? > > * If the parties happen to be assigned the same sender ID, bad things > happen (identical key derivation, nonce reuse, nuclear meltdown). > > If the current pattern of KDF'ing IDs stands, this needs to be > prevented explicitly. > > * The derivations of "OSCORE RECIPIENT ID" and "OSCORE SENDER ID" are > confusing as they each need to happen on both sides, and the terms > will match on one and need to be opposite on the other. > > (I couldn't even easily find which is intended to be which). > > My suggestion is to derive "OSCORE EAP PEER SENDER ID" and "OSCORE > AUTHENTICATOR SENDER ID" instead. (Or preferably shorter strings). > > * Exmaples: Do you envision particular EAP protocols to be used in the > given examples? > > Best regards > Christian From nobody Mon Sep 6 02:01:05 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98703A081C; Mon, 6 Sep 2021 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 DNbbBjZSa-9h; Mon, 6 Sep 2021 02:00:58 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8723A3A27BB; Mon, 6 Sep 2021 02:00:58 -0700 (PDT) Received: from [192.168.217.118] (p548dcf6e.dip0.t-ipconnect.de [84.141.207.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4H32S55SWGz2xQd; Mon, 6 Sep 2021 11:00:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <8DC48816-852A-47D9-B533-37D9FB69E97A@ericsson.com> Date: Mon, 6 Sep 2021 11:00:53 +0200 Cc: "draft-ietf-core-senml-data-ct.all@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 652611653.25512-965265c644234126ad709bfa231480ef Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DC48816-852A-47D9-B533-37D9FB69E97A@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] AD review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 09:01:03 -0000 Hi Francesca, thank you for this in-depth review. > On 2021-08-23, at 22:07, Francesca Palombini = wrote: >=20 > Thank you for the work on this document. Please take care of these = minor comments at the same time as the Last Call comments. >=20 > Francesca >=20 > 1. ----- >=20 > FP: First of all, I wanted to confirm with the WG that the status = "proposed standard" is the appropriate one here. Just making sure this = was considered by the working group and the authors, as I note that the = standard track is not needed for the IANA registrations, which require = only expert review. This subject comes up so often that it is hard to remember whether we = discussed it specifically for data-ct. The document has started out as specifying standards track and it = doesn=E2=80=99t look that ever changed, so I can=E2=80=99t find a = specific event where we would have discussed this. I also couldn=E2=80=99t find records of a discussion in the minutes of = CoRE meetings of the last 2=C2=BD years or so (side note: I actually = wrote a tool to mine the minutes as they are not arranged in a way that = would aid that mining). Generally, you are right that simply registering a couple of SenML = labels does create the entries in the registry. However, here the = intention was to also standardize the information that goes in a field = under those labels. To make this document referenceable without causing = the equivalent of a downref in an SDO that wants to depend on this = field, it is best advanced as a standards-track document. (I have said before that different treatment of the std vs. info = distinction in different areas of the IETF is a leading cause for = confusion, but this is probably not the document to fix this for.) > 2. ----- >=20 > used to send various kinds of data. In the example given in > Figure 1, a temperature value, an indication whether a lock is open, > and a data value (with SenML field "vd") read from an NFC reader is > sent in a single SenML pack. >=20 >=20 > FP: Might be worth stating in the sentence above that the example uses = JSON and base64 encoding. Added: +The example is given in SenML JSON representation, so the "vd" (data +value) field is encoded as a base64url string (without +padding), as per {{Section 5 of -senml}}. Now in https://github.com/core-wg/senml-data-ct/commit/a3b0510 (with a = few additional reference fixes). > 3. ----- >=20 >=20 > Media-Type-Name: A combination of a type-name and a subtype-name > registered in [IANA.media-types] as per [RFC6838], conventionally > identified by the two names separated by a slash. >=20 > FP: RFC 6838 is an informative reference, I wonder if it wouldn't make = more sense to bring it up to normative, given that type-name and = subtype-name (and media types in general) need to be understood in this = specification. If all copies of RFC 6838 get deleted, the data-ct spec still makes = sense. The ABNF from 6838 is copied over, not referenced. This is why this isn=E2=80=99t labeled as a normative reference, but = there is no strong reason not to do that. > 4. ----- >=20 > Content-Type: A Media-Type-Name, optionally associated with > parameters (separated from the media type name and from each other > by a semicolon). In HTTP and many other protocols, used in a >=20 > FP: Please add a reference to the RFC defining media types parameters. That would be RFC 2045 (as far as the syntax is concerned =E2=80=94 = semantics is in RFC 2046). Added a reference to RFC 2045 (amazingly, these RFCs don=E2=80=99t have = a =E2=80=9Creferences=E2=80=9D section, so I don=E2=80=99t know whether = RFC 2046 is a normative reference for 2045, but for all intents and = purposes, it is): -: A Media-Type-Name, optionally associated with parameters (separated = from +: A Media-Type-Name, optionally associated with parameters + ({{Section 5 of -mime1}}, separated from RFC 6838 gives the syntax for parameter names as parameter-name =3D restricted-name However, we opted to whole-sale copy the RFC 7231 syntax, which is a bit = more permissive. Now in https://github.com/core-wg/senml-data-ct/commit/20da9a8 > 5. ---- >=20 > "Content-Encoding"; we *never* use this term (except when we are > in error). >=20 > FP: It is not clear to me the goal of what stated in parenthesis. Unfortunately, there are lots of RFCs that get this wrong (including our = own Section 12.3 in RFC 7252=E2=80=A6). The parenthesis may be a bit terse to make this explicit. Bron had some nice replacement text in his artart review, which turned = into https://github.com/core-wg/senml-data-ct/commit/90a3deb > 6. ----- >=20 > FP: There is a subtle difference between Content-Format and = Content-Format-Spec, the latter being the "string representation" of the = former. By reading the two definitions, it does feel like the same thing = is specified twice, it might be worth moving the following to = Content-Format-Spec: >=20 > , identified by (1) a numeric identifier defined by the > "CoAP Content-Formats" subregistry of [IANA.core-parameters] as > per [RFC7252] or (2) a Content-Format-String. I couldn=E2=80=99t quite make this work, as this then looks like = Content-Format always is represented as a pair =E2=80=94 having the = description as the alternative is best left in that definition. > Also, Content-Format-Spec right now mentions "Content-Format number". = If you don't do the change above, it might be worth adding the following = clarification: >=20 > OLD: > Content-Format: the combination of a Content-Type and a Content- > Coding, identified by (1) a numeric identifier defined by the > "CoAP Content-Formats" subregistry of [IANA.core-parameters] as > per [RFC7252] or (2) a Content-Format-String. > NEW: > Content-Format: the combination of a Content-Type and a Content- > Coding, identified by (1) a numeric identifier defined by the > "CoAP Content-Formats" subregistry of [IANA.core-parameters] as > per [RFC7252] (referred to as Content-Format number) or (2) a > Content-Format-String. >=20 > (Content-Format number is used also in section 3) Added in https://github.com/core-wg/senml-data-ct/commit/6923d8c > 7. ----- >=20 > FP: I would have appreciated an example of use or the "bct" field in = Section 4. Added in https://github.com/core-wg/senml-data-ct/commit/e8181d6 [Ari: Can you cross-check this new example?] > 8. ----- >=20 > FP: I think an example using a Content-Format-String including a = parameter could have been useful. Added in https://github.com/core-wg/senml-data-ct/commit/78622c8 > 9. ----- >=20 > FP: In Section 8, several columns for the registration of SenML labels = are missing: CBOR label, exi ID. As they should be: RFC8428 12.2: [=E2=80=A6] the CBOR labels SHOULD be left empty as CBOR will use the string encoding for any new labels. The EI column contains the EXI schemaId value of the first schema that includes this label, or it is empty if this label was not intended for use with EXI. (Of course, we can discuss whether data-ct is =E2=80=9Cintended for use = with EXI=E2=80=9D.) All the changes above, plus some related house-keeping, are in https://github.com/core-wg/senml-data-ct/pull/5 =E2=80=94 summary in = https://github.com/core-wg/senml-data-ct/pull/5/files Gr=C3=BC=C3=9Fe, Carsten= From nobody Mon Sep 6 03:18:27 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A30AF3A2A05; Mon, 6 Sep 2021 03:18:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: core@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163092350360.5169.1299765677300317336@ietfa.amsl.com> Reply-To: Christer Holmberg Date: Mon, 06 Sep 2021 03:18:23 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 10:18:24 -0000 Reviewer: Christer Holmberg Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-senml-data-ct-04 Reviewer: Christer Holmberg Review Date: 2021-09-06 IETF LC End Date: 2021-09-06 IESG Telechat date: Not scheduled for a telechat Summary: I have reviewed the document. I have one technical comment, but the rest is mostly editorial. Related to that, I do think the document could use some editorial clean-up, e.g., when it comes to consistent terminology. I think it is also good not to assume that the reader knows CoAP, and to make sure the appropriate references/explanations are present when CoAP is referred to. Major issues: N/A Minor issues: Q1 (TECHNICAL): What happens if the receiver does not support the "ct" value? Is it a server-error? If so, what response code is used? I think that should be specified. Nits/editorial comments: Q2 (EDITORIAL): The text should use consistent terminology. See below for a few examples: The Abstract says: "The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data." First the text talks about types of values, and then suddenly the Content-Format of the data. Content-Format is the name of the new field - that is not what you are indicating. You are using the new field to indicate something. Also, "Content-Format" is also used by CoAP, so please check that it is clear what is referred to whenever mentioned. The text in Section 1 says: "To facilitate automatic interpretation it is useful to be able to indicate an Internet media type and content-coding right in the SenML Record." ...and, the test in Section 7 says: "The indication of a media type in the data does not exempt a consuming application from properly checking its inputs." Now the text suddenly talks about "an Internet media type and content-coding", when it earlier (in the Abstract) talked about value of type. Q3 (EDITORIAL): The text says: "The CoAP Content-Format (Section 12.3 of [RFC7252]) provides just this information" I think it would be good with a little introduction on how CoAP is related to all this. Also "provides just this information" probably needs some re-wording. Q4 (EDITORIAL): Section 6 contains the ABNF for the new fields. Is there a reason you don't define them in the same way as the basic field is defined in RFC 8428 (there is no ABNF)? Q5 (EDITORIAL): The text in Section 7 says: "The indication of a media type in the data does not exempt a consuming application from properly checking its inputs." I assume that by "its inputs" you refer to "received SenML data". Shouldn't properly checking inputs be a generic CoAP security consideration? From nobody Mon Sep 6 07:06:20 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09E53A0CF5; Mon, 6 Sep 2021 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgkYS_vpf9Lm; Mon, 6 Sep 2021 07:06:03 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00062.outbound.protection.outlook.com [40.107.0.62]) (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 071313A0CCB; Mon, 6 Sep 2021 07:06:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NANtJyM0GBnXblkabZ3a/FQTGNdxzHN3fHF1DlflaM0c8bRL3t6NLQyePUCipB1LvL5nm43V7vNuWUfP3oIa2A+pnvGtcnSwUJp0dk/f+NVj+y+5BBorjRNtZ1N7MqfiklpITk/9gLsSSIe70dU4fIrtWjzxk3MG3ETcFSziee+PfTtnTsRvMc0u1T0c6b4AwxN6N2G/aaBdUELldRbI2yauusoN6cATcG+sbgKMwY+nH1rl1rxuyzuUsgxpZuyLXTbw8j1DOH2hNmxb0USVQiPRULgl7i03Zrs0D36+5wgeq0qtx7oSW3G7jHiltYkqCKE7KuHY3cVSQ5CKNqt1Uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RtRph2O6nQO3/X0C3teWeKq6AiyUzFRXIUyWXGfRoDY=; b=fjq20b1PpH3ziOD7ZwYl80v83BJPOVABgHJQb+qohzHsVziSRKUXwOw4bAc+vqmYqTjIAkZInvy8yK9rRkusvE1C/oVTCBHRUwDEp/1w2SabU7JzjrVlhCztqZ/XubExyB5MaezLh2/2pTcMuo6Wr00jKweIwUmKaI6ArB1sDsFsMz6VCvOn6/aPkT8f09byG1SabqkZKmLB104glQTVtGjq9ZT0mzx7ZFgKpR5/+hPniLcx8IgkxcDmIYpQWIG4MBx4KtHLE2ydFEqX01EMvRVusUufakPBLlNXwY5x9FmlW2XoqQaDSFtSbIDXazKBEpCfFdcplmODToF1JIo3vA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RtRph2O6nQO3/X0C3teWeKq6AiyUzFRXIUyWXGfRoDY=; b=alnUVnHibedK+XORA8vqdlUiB4r83GaSUgvaLIvR9/6750bEkSQzstyeENDyicCv0BHSPpFW4gO2KrMUt+YpsfzlGb/xzv0ixat21VS5Zs+OoYeE1t/GAV2dcwv0S8x+1JoUWhZAuckouASdJCYrlUlTxQEHWBLyGIi01FuCi54= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0702MB3626.eurprd07.prod.outlook.com (2603:10a6:7:7f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.10; Mon, 6 Sep 2021 14:06:00 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875%5]) with mapi id 15.20.4500.012; Mon, 6 Sep 2021 14:06:00 +0000 From: Francesca Palombini To: Carsten Bormann CC: "draft-ietf-core-senml-data-ct.all@ietf.org" , "core@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-senml-data-ct-04 Thread-Index: AQHXmFpxg9dovoeIP066E1NsHR9gTquWyq+AgAB2xYA= Date: Mon, 6 Sep 2021 14:05:59 +0000 Message-ID: <92FA58A1-1448-4CE4-85F0-256086797A0D@ericsson.com> References: <8DC48816-852A-47D9-B533-37D9FB69E97A@ericsson.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dffc9508-b74e-4836-ade0-08d9713f7470 x-ms-traffictypediagnostic: HE1PR0702MB3626: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zC9kBcsUYfG0XmA3GRHyr2ziTvcowJEq8gCoPAptEZpNTfkdG/VckpGOreS8dghrySkQ800kbm69AFgdAyL0b/7ok0xX2IRuT8OXxWgVOMLt5dwvD/j1ILzDxRfcQ4U6uOWzVuOc7tVHE8ML6t3B8VIsdOxBS/73ryrRL6CCT5PqyYzJeQ7nFXRi+1tT9f5RJ2urq+AhxYScXyPGwtDH5BPTEFGC5R/gGgTLSnxGYjTw0uuRNdAOKqddjBwHg3xMaJB39kuTKKnCRhyKu0Rbvqj7pweevzldmlPKVTDRTMUJ9mOlCxI1skIq7RL0Bep2QnDhhOtTIzYEMn5XkDJxF+QBKJe0gMwk1hfQcCnDj//ge1qGKXOCXJVQlugRNRFItHjwRsa+8/GOWoJMmU+1bZ8ds53uvCkLIaQOf6ZjWp/z7DBKGMpwB767egyL+o73sb/FbfFLbIiEB9wwjFniZxdU45bxf/HEpALeUYvWKJ8Vnu+qUvE2uVjXp7QSlvldX5kQtH+censlpfubDzCfHuqjhndXH2ehWQt1V2WbMIo3HjOw/TpId5TwP+u5ebIO4XL/DBLOdp4Qzdm5o64IhfDZ3biUEccNIgy4jFs1V7sXArXb9ftCIiVMVbzBTzjmRv4fXhWW+7/WDewlMpmDKQ1clpAZQhNVxCauzo9Hjn/fH6oPQLi1vGJyDTcj993GrMO/NexF1Jlrt3stP3L6n0zi7jydc8Acf1QBNioAQ8q781s5LSF1OiwAVzHyRhpkRl0iRvOjDAU5XjEj04aE5UyBtLdBsdUbQ2Wmk822uaaFqcWi5jciM8EK6sMeybGcRZ6tOpX/zGq2SquRfV1tx4PfzZChHiaUboIeUxK2jCE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(6506007)(5660300002)(83380400001)(53546011)(8676002)(966005)(86362001)(122000001)(478600001)(2906002)(6512007)(64756008)(8936002)(186003)(36756003)(6486002)(33656002)(38070700005)(66446008)(76116006)(66556008)(66476007)(2616005)(66946007)(4326008)(6916009)(54906003)(71200400001)(44832011)(38100700002)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?anZnQ0VmV0F6VW9Da0xBaU8vMzVwV0d1QWRNSkRXc3I3TXVGZGtJaCtENzJR?= =?utf-8?B?VjNPMXExQ0xaM3BUU0ZRRmRsaTAxMVFlRnRVZmZTeE9ua0lLVWVaYi94N1VB?= =?utf-8?B?eGNqckdJR01UUGh3N0t6d0hicWwyWHd0aHF3SnJHM2sycDFrdzhqdTM2YlFQ?= =?utf-8?B?bXVtNVJhSjcrNzJhUVk4ZlAzcjBBRDA4MW1HYVU0dzZaRjZTdEsyckl1bkRV?= =?utf-8?B?dFozVS9CTGxMRGlvdUZZM3N0bUdVcUpTdTdLV2U4WjVzekFjYUdyVWdmd0U0?= =?utf-8?B?Z2p1cERNRnlCM01XU25Yc21rSm9KMFZnZjBRbExZMzQ2a1hCMEYrbXhxSG1j?= =?utf-8?B?ZXVPbndMeUEyWGszMHNGeG44WFg5cGxJOENDdEpmSFlMd0MzWUltaGxZb09n?= =?utf-8?B?YUtxK29hUEQ0TDVxRzBYOEl3RWhXK3JoRHc3YStRa0hnQTdZbnM2M1UxOC9U?= =?utf-8?B?YWtOM0drUmpIVmFFRWp0ejdzRVIxUXpTUFk1YnF3S2YzUy91cmtLYjk0bzg2?= =?utf-8?B?QVM0Tkc2Z1ozb2hoRlNoQS85Q29lTmxQVVJWN2JLQjFrQjk1WjRqc1BGZXN1?= =?utf-8?B?dEV1Ky9rUEZmcmNlR25yZFdSa3Vyd0RaRWhuZTJLY2tsb1BpenJ0dDh1eEhv?= =?utf-8?B?U05MRjVZQ0tNNHI5cTV0Y3VoVjV3eS9sRmZza0o1NnhxNDIyMEZCcEczTllT?= =?utf-8?B?UC9KODNxRkJTTzJrMnhsV3JQWVF0MGkvQmZkNGdocDlwaGlXWWkvQWNzMWNv?= =?utf-8?B?UlQwd1d3c1lRNnhSZm9ObTViY0xqOU16MisrTGhvSlkreEt2UFp5YmxtMG51?= =?utf-8?B?OXFMRkNOR0hydUR0NGxGSWNxRnpkbExzSkxXWlZrQXlYeHFrVG5ERFl1b2U2?= =?utf-8?B?MXhUSVNqRXhpUHduNUlrbmVjak9tVnZmWlRqY2ZYSmVhSFdqZWMzd2xITW9l?= =?utf-8?B?WFk1cnF6QTdzQktOMUJ1YzYyRXBveXpWRjVNSEh6Nm5oNXV5a3NpSWhUbDR3?= =?utf-8?B?SDBiTm9RV1c2aUpJU0t2SE5EYjlvSVhjUUVvYnBrU3p3VC8wQTNKdldxYytG?= =?utf-8?B?akVhZ0NXOEF6L2RLc3hjOTZFNzdBV3A5YklyT2dLTmlKakovWTI5c0RIMmwx?= =?utf-8?B?QXNUVGJxNng2UktENTlNUzM1QmhuQjlpWkZpbmRUK2JhZ0kzdStNVSs0aGZR?= =?utf-8?B?WVgyNlg1enVRamdNNG5sM0Z5bmxXcWM5Z01yUEJyc1c3S1Y2K3Blb1J2T3RM?= =?utf-8?B?NXJvdnBncU1lRmpyL0JQdW5rNk5XYlVhOFRYL0xhczFYZXdIZloweURhdFlw?= =?utf-8?B?bEZ6K1dBQTNzemg3clNwSVJtNE0zVHQwOTBMU0tsdTRteFhOVzU1ZzlEZmI4?= =?utf-8?B?dERDMFQrb3VPVHQ3S3dCUGF6RnEzNU1mNXNoYzlUN0pISFcyQ2VQY0dKYUU2?= =?utf-8?B?TStZRGgvSTdGdTZGMVQvUE1KTUNNb3ViUCtJNXhQbGVGYUJXUHY3VDNLNVRJ?= =?utf-8?B?aGVHZk1ubnVsZ2x4bzIvOEJGUXVEYUNuVFh5ck80QzJHVUttdkxQZzhvM0VE?= =?utf-8?B?VnlURmN1bnQvSjB2M0UrUzc0UUNLVC9zZWlNc1BiWnJyNmRkdmNjcWJOdER1?= =?utf-8?B?M0JHa0Y2ZzA2MkU0Tm5yZXZDTkt5YnZ6Z0tDeDFLTEJPNkxNZDJDems1bnFT?= =?utf-8?B?N0Z0S2s5NUVJODIxK1NPTWpjWXpuQXFOVXJBakJZWGQ2QktXQUlCZ205V2Vw?= =?utf-8?B?RXJ4MEJpUHJaYU14R1ZaalYvbXI1b3g3WmIzQzduSzBrMVBMUDZBYkZ4SUtL?= =?utf-8?B?UzREMVRiYklIRks5SlJSVlhIdm5oZDFWS1hwdUZjVmNDdWR1NXRXMXhDM1pl?= =?utf-8?B?MDJQV1JmT3ZybGlqU2FyZjlnNlhqdGZyZHJveDh0LzE0aVE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8485A16A2469DC4B9EEE89411C8AC81F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dffc9508-b74e-4836-ade0-08d9713f7470 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2021 14:05:59.8146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y2B4bSUovHcZk1qCbOfbvPpo50pZX0+cVlx7JrVzDnRK3ly8f4XiB+t2/yqLdWoOmC3WAtkQH9g7Z7ILD+yvQP1XzS7JU8ag0HmfkfMEwodcnoUsQlN36AwO9l7oZ9aj X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3626 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 14:06:16 -0000 VGhhbmtzIENhcnN0ZW4sIGl0IGxvb2tzIGdvb2QuIEkgYW0gaGFwcHkgd2l0aCB5b3VyIHJlYXNv bmluZyBmb3Igc3RhbmRhcmQgdHJhY2ssIGFzIHdlbGwgYXMgd2l0aCB5b3VyIGNsYXJpZmljYXRp b25zIGJlbG93LiBMZXQncyB3YWl0IGZvciB0aGUgTEMgcmV2aWV3cyB0byBjb21lIGluLCBhbmQg dGhlbiBJIHdpbGwgd2FpdCBmb3IgdGhlIG5ldyB2ZXJzaW9uLg0KDQpGcmFuY2VzY2EgDQoNCu+7 v09uIDA2LzA5LzIwMjEsIDExOjAxLCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiB3 cm90ZToNCg0KDQogICAgSGkgRnJhbmNlc2NhLA0KDQogICAgdGhhbmsgeW91IGZvciB0aGlzIGlu LWRlcHRoIHJldmlldy4NCg0KICAgID4gT24gMjAyMS0wOC0yMywgYXQgMjI6MDcsIEZyYW5jZXNj YSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIG9uIHRo aXMgZG9jdW1lbnQuIFBsZWFzZSB0YWtlIGNhcmUgb2YgdGhlc2UgbWlub3IgY29tbWVudHMgYXQg dGhlIHNhbWUgdGltZSBhcyB0aGUgTGFzdCBDYWxsIGNvbW1lbnRzLg0KICAgID4gDQogICAgPiBG cmFuY2VzY2ENCiAgICA+IA0KICAgID4gMS4gLS0tLS0NCiAgICA+IA0KICAgID4gRlA6IEZpcnN0 IG9mIGFsbCwgSSB3YW50ZWQgdG8gY29uZmlybSB3aXRoIHRoZSBXRyB0aGF0IHRoZSBzdGF0dXMg InByb3Bvc2VkIHN0YW5kYXJkIiBpcyB0aGUgYXBwcm9wcmlhdGUgb25lIGhlcmUuIEp1c3QgbWFr aW5nIHN1cmUgdGhpcyB3YXMgY29uc2lkZXJlZCBieSB0aGUgd29ya2luZyBncm91cCBhbmQgdGhl IGF1dGhvcnMsIGFzIEkgbm90ZSB0aGF0IHRoZSBzdGFuZGFyZCB0cmFjayBpcyBub3QgbmVlZGVk IGZvciB0aGUgSUFOQSByZWdpc3RyYXRpb25zLCB3aGljaCByZXF1aXJlIG9ubHkgZXhwZXJ0IHJl dmlldy4NCg0KICAgIFRoaXMgc3ViamVjdCBjb21lcyB1cCBzbyBvZnRlbiB0aGF0IGl0IGlzIGhh cmQgdG8gcmVtZW1iZXIgd2hldGhlciB3ZSBkaXNjdXNzZWQgaXQgc3BlY2lmaWNhbGx5IGZvciBk YXRhLWN0Lg0KICAgIFRoZSBkb2N1bWVudCBoYXMgc3RhcnRlZCBvdXQgYXMgc3BlY2lmeWluZyBz dGFuZGFyZHMgdHJhY2sgYW5kIGl0IGRvZXNu4oCZdCBsb29rIHRoYXQgZXZlciBjaGFuZ2VkLCBz byBJIGNhbuKAmXQgZmluZCBhIHNwZWNpZmljIGV2ZW50IHdoZXJlIHdlIHdvdWxkIGhhdmUgZGlz Y3Vzc2VkIHRoaXMuDQogICAgSSBhbHNvIGNvdWxkbuKAmXQgZmluZCByZWNvcmRzIG9mIGEgZGlz Y3Vzc2lvbiBpbiB0aGUgbWludXRlcyBvZiBDb1JFIG1lZXRpbmdzIG9mIHRoZSBsYXN0IDLCvSB5 ZWFycyBvciBzbyAoc2lkZSBub3RlOiBJIGFjdHVhbGx5IHdyb3RlIGEgdG9vbCB0byBtaW5lIHRo ZSBtaW51dGVzIGFzIHRoZXkgYXJlIG5vdCBhcnJhbmdlZCBpbiBhIHdheSB0aGF0IHdvdWxkIGFp ZCB0aGF0IG1pbmluZykuDQoNCiAgICBHZW5lcmFsbHksIHlvdSBhcmUgcmlnaHQgdGhhdCBzaW1w bHkgcmVnaXN0ZXJpbmcgYSBjb3VwbGUgb2YgU2VuTUwgbGFiZWxzIGRvZXMgY3JlYXRlIHRoZSBl bnRyaWVzIGluIHRoZSByZWdpc3RyeS4gIEhvd2V2ZXIsIGhlcmUgdGhlIGludGVudGlvbiB3YXMg dG8gYWxzbyBzdGFuZGFyZGl6ZSB0aGUgaW5mb3JtYXRpb24gdGhhdCBnb2VzIGluIGEgZmllbGQg dW5kZXIgdGhvc2UgbGFiZWxzLiAgVG8gbWFrZSB0aGlzIGRvY3VtZW50IHJlZmVyZW5jZWFibGUg d2l0aG91dCBjYXVzaW5nIHRoZSBlcXVpdmFsZW50IG9mIGEgZG93bnJlZiBpbiBhbiBTRE8gdGhh dCB3YW50cyB0byBkZXBlbmQgb24gdGhpcyBmaWVsZCwgaXQgaXMgYmVzdCBhZHZhbmNlZCBhcyBh IHN0YW5kYXJkcy10cmFjayBkb2N1bWVudC4NCg0KICAgIChJIGhhdmUgc2FpZCBiZWZvcmUgdGhh dCBkaWZmZXJlbnQgdHJlYXRtZW50IG9mIHRoZSBzdGQgdnMuIGluZm8gZGlzdGluY3Rpb24gaW4g ZGlmZmVyZW50IGFyZWFzIG9mIHRoZSBJRVRGIGlzIGEgbGVhZGluZyBjYXVzZSBmb3IgY29uZnVz aW9uLCBidXQgdGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIGRvY3VtZW50IHRvIGZpeCB0aGlzIGZv ci4pDQoNCiAgICA+IDIuIC0tLS0tDQogICAgPiANCiAgICA+ICB1c2VkIHRvIHNlbmQgdmFyaW91 cyBraW5kcyBvZiBkYXRhLiAgSW4gdGhlIGV4YW1wbGUgZ2l2ZW4gaW4NCiAgICA+ICBGaWd1cmUg MSwgYSB0ZW1wZXJhdHVyZSB2YWx1ZSwgYW4gaW5kaWNhdGlvbiB3aGV0aGVyIGEgbG9jayBpcyBv cGVuLA0KICAgID4gIGFuZCBhIGRhdGEgdmFsdWUgKHdpdGggU2VuTUwgZmllbGQgInZkIikgcmVh ZCBmcm9tIGFuIE5GQyByZWFkZXIgaXMNCiAgICA+ICBzZW50IGluIGEgc2luZ2xlIFNlbk1MIHBh Y2suDQogICAgPiANCiAgICA+IA0KICAgID4gRlA6IE1pZ2h0IGJlIHdvcnRoIHN0YXRpbmcgaW4g dGhlIHNlbnRlbmNlIGFib3ZlIHRoYXQgdGhlIGV4YW1wbGUgdXNlcyBKU09OIGFuZCBiYXNlNjQg ZW5jb2RpbmcuDQoNCiAgICBBZGRlZDoNCiAgICArVGhlIGV4YW1wbGUgaXMgZ2l2ZW4gaW4gU2Vu TUwgSlNPTiByZXByZXNlbnRhdGlvbiwgc28gdGhlICJ2ZCIgKGRhdGENCiAgICArdmFsdWUpIGZp ZWxkIGlzIGVuY29kZWQgYXMgYSBiYXNlNjR1cmwgc3RyaW5nICh3aXRob3V0DQogICAgK3BhZGRp bmcpLCBhcyBwZXIge3tTZWN0aW9uIDUgb2YgLXNlbm1sfX0uDQoNCiAgICBOb3cgaW4gaHR0cHM6 Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1hZDg0OTllNy1mMjFmYTEwNS1hZDg0ZDk3 Yy04NjA3M2IzNmVhMjgtMzA0NDI1YjdhOTAyYWY5ZiZxPTEmZT0yZDEyMzU3My00YzhjLTRkMTgt OTk5Zi1mOTNmMzcxNjY3MDgmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJG c2VubWwtZGF0YS1jdCUyRmNvbW1pdCUyRmEzYjA1MTAgKHdpdGggYSBmZXcgYWRkaXRpb25hbCBy ZWZlcmVuY2UgZml4ZXMpLg0KDQogICAgPiAzLiAtLS0tLQ0KICAgID4gDQogICAgPiANCiAgICA+ ICBNZWRpYS1UeXBlLU5hbWU6ICBBIGNvbWJpbmF0aW9uIG9mIGEgdHlwZS1uYW1lIGFuZCBhIHN1 YnR5cGUtbmFtZQ0KICAgID4gICAgIHJlZ2lzdGVyZWQgaW4gW0lBTkEubWVkaWEtdHlwZXNdIGFz IHBlciBbUkZDNjgzOF0sIGNvbnZlbnRpb25hbGx5DQogICAgPiAgICAgaWRlbnRpZmllZCBieSB0 aGUgdHdvIG5hbWVzIHNlcGFyYXRlZCBieSBhIHNsYXNoLg0KICAgID4gDQogICAgPiBGUDogUkZD IDY4MzggaXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlLCBJIHdvbmRlciBpZiBpdCB3b3VsZG4n dCBtYWtlIG1vcmUgc2Vuc2UgdG8gYnJpbmcgaXQgdXAgdG8gbm9ybWF0aXZlLCBnaXZlbiB0aGF0 IHR5cGUtbmFtZSBhbmQgc3VidHlwZS1uYW1lIChhbmQgbWVkaWEgdHlwZXMgaW4gZ2VuZXJhbCkg bmVlZCB0byBiZSB1bmRlcnN0b29kIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KICAgIElmIGFs bCBjb3BpZXMgb2YgUkZDIDY4MzggZ2V0IGRlbGV0ZWQsIHRoZSBkYXRhLWN0IHNwZWMgc3RpbGwg bWFrZXMgc2Vuc2UuDQogICAgVGhlIEFCTkYgZnJvbSA2ODM4IGlzIGNvcGllZCBvdmVyLCBub3Qg cmVmZXJlbmNlZC4NCiAgICBUaGlzIGlzIHdoeSB0aGlzIGlzbuKAmXQgbGFiZWxlZCBhcyBhIG5v cm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCB0aGVyZSBpcyBubyBzdHJvbmcgcmVhc29uIG5vdCB0byBk byB0aGF0Lg0KDQogICAgPiA0LiAtLS0tLQ0KICAgID4gDQogICAgPiAgQ29udGVudC1UeXBlOiAg QSBNZWRpYS1UeXBlLU5hbWUsIG9wdGlvbmFsbHkgYXNzb2NpYXRlZCB3aXRoDQogICAgPiAgICAg cGFyYW1ldGVycyAoc2VwYXJhdGVkIGZyb20gdGhlIG1lZGlhIHR5cGUgbmFtZSBhbmQgZnJvbSBl YWNoIG90aGVyDQogICAgPiAgICAgYnkgYSBzZW1pY29sb24pLiAgSW4gSFRUUCBhbmQgbWFueSBv dGhlciBwcm90b2NvbHMsIHVzZWQgaW4gYQ0KICAgID4gDQogICAgPiBGUDogUGxlYXNlIGFkZCBh IHJlZmVyZW5jZSB0byB0aGUgUkZDIGRlZmluaW5nIG1lZGlhIHR5cGVzIHBhcmFtZXRlcnMuDQoN CiAgICBUaGF0IHdvdWxkIGJlIFJGQyAyMDQ1IChhcyBmYXIgYXMgdGhlIHN5bnRheCBpcyBjb25j ZXJuZWQg4oCUIHNlbWFudGljcyBpcyBpbiBSRkMgMjA0NikuDQoNCiAgICBBZGRlZCBhIHJlZmVy ZW5jZSB0byBSRkMgMjA0NSAoYW1hemluZ2x5LCB0aGVzZSBSRkNzIGRvbuKAmXQgaGF2ZSBhIOKA nHJlZmVyZW5jZXPigJ0gc2VjdGlvbiwgc28gSSBkb27igJl0IGtub3cgd2hldGhlciBSRkMgMjA0 NiBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yIDIwNDUsIGJ1dCBmb3IgYWxsIGludGVudHMg YW5kIHB1cnBvc2VzLCBpdCBpcyk6DQoNCiAgICAtOiBBIE1lZGlhLVR5cGUtTmFtZSwgb3B0aW9u YWxseSBhc3NvY2lhdGVkIHdpdGggcGFyYW1ldGVycyAoc2VwYXJhdGVkIGZyb20NCiAgICArOiBB IE1lZGlhLVR5cGUtTmFtZSwgb3B0aW9uYWxseSBhc3NvY2lhdGVkIHdpdGggcGFyYW1ldGVycw0K ICAgICsgICh7e1NlY3Rpb24gNSBvZiAtbWltZTF9fSwgc2VwYXJhdGVkIGZyb20NCg0KDQogICAg UkZDIDY4MzggZ2l2ZXMgdGhlIHN5bnRheCBmb3IgcGFyYW1ldGVyIG5hbWVzIGFzDQoNCiAgICAg ICAgICBwYXJhbWV0ZXItbmFtZSA9IHJlc3RyaWN0ZWQtbmFtZQ0KDQogICAgSG93ZXZlciwgd2Ug b3B0ZWQgdG8gd2hvbGUtc2FsZSBjb3B5IHRoZSBSRkMgNzIzMSBzeW50YXgsIHdoaWNoIGlzIGEg Yml0IG1vcmUgcGVybWlzc2l2ZS4NCg0KICAgIE5vdyBpbiBodHRwczovL3Byb3RlY3QyLmZpcmVl eWUuY29tL3YxL3VybD9rPWYxOWNmNGZmLWFlMDdjYzFkLWYxOWNiNDY0LTg2MDczYjM2ZWEyOC1j YTgwZDBjZDVkYzYxMjA4JnE9MSZlPTJkMTIzNTczLTRjOGMtNGQxOC05OTlmLWY5M2YzNzE2Njcw OCZ1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNvcmUtd2clMkZzZW5tbC1kYXRhLWN0JTJG Y29tbWl0JTJGMjBkYTlhOA0KDQogICAgPiA1LiAtLS0tDQogICAgPiANCiAgICA+ICAgICAiQ29u dGVudC1FbmNvZGluZyI7IHdlICpuZXZlciogdXNlIHRoaXMgdGVybSAoZXhjZXB0IHdoZW4gd2Ug YXJlDQogICAgPiAgICAgaW4gZXJyb3IpLg0KICAgID4gDQogICAgPiBGUDogSXQgaXMgbm90IGNs ZWFyIHRvIG1lIHRoZSBnb2FsIG9mIHdoYXQgc3RhdGVkIGluIHBhcmVudGhlc2lzLg0KDQogICAg VW5mb3J0dW5hdGVseSwgdGhlcmUgYXJlIGxvdHMgb2YgUkZDcyB0aGF0IGdldCB0aGlzIHdyb25n IChpbmNsdWRpbmcgb3VyIG93biBTZWN0aW9uIDEyLjMgaW4gUkZDIDcyNTLigKYpLg0KICAgIFRo ZSBwYXJlbnRoZXNpcyBtYXkgYmUgYSBiaXQgdGVyc2UgdG8gbWFrZSB0aGlzIGV4cGxpY2l0Lg0K DQogICAgQnJvbiBoYWQgc29tZSBuaWNlIHJlcGxhY2VtZW50IHRleHQgaW4gaGlzIGFydGFydCBy ZXZpZXcsIHdoaWNoIHR1cm5lZCBpbnRvDQogICAgaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNv bS92MS91cmw/az0xOGM1NzM5My00NzVlNGI3MS0xOGM1MzMwOC04NjA3M2IzNmVhMjgtYjZiZGM0 YjhmNjBmZjE5ZSZxPTEmZT0yZDEyMzU3My00YzhjLTRkMTgtOTk5Zi1mOTNmMzcxNjY3MDgmdT1o dHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGc2VubWwtZGF0YS1jdCUyRmNvbW1p dCUyRjkwYTNkZWINCg0KICAgID4gNi4gLS0tLS0NCiAgICA+IA0KICAgID4gRlA6IFRoZXJlIGlz IGEgc3VidGxlIGRpZmZlcmVuY2UgYmV0d2VlbiBDb250ZW50LUZvcm1hdCBhbmQgQ29udGVudC1G b3JtYXQtU3BlYywgdGhlIGxhdHRlciBiZWluZyB0aGUgInN0cmluZyByZXByZXNlbnRhdGlvbiIg b2YgdGhlIGZvcm1lci4gQnkgcmVhZGluZyB0aGUgdHdvIGRlZmluaXRpb25zLCBpdCBkb2VzIGZl ZWwgbGlrZSB0aGUgc2FtZSB0aGluZyBpcyBzcGVjaWZpZWQgdHdpY2UsIGl0IG1pZ2h0IGJlIHdv cnRoIG1vdmluZyB0aGUgZm9sbG93aW5nIHRvIENvbnRlbnQtRm9ybWF0LVNwZWM6DQogICAgPiAN CiAgICA+ICAgICAgLCBpZGVudGlmaWVkIGJ5ICgxKSBhIG51bWVyaWMgaWRlbnRpZmllciBkZWZp bmVkIGJ5IHRoZQ0KICAgID4gICAgICJDb0FQIENvbnRlbnQtRm9ybWF0cyIgc3VicmVnaXN0cnkg b2YgW0lBTkEuY29yZS1wYXJhbWV0ZXJzXSBhcw0KICAgID4gICAgIHBlciBbUkZDNzI1Ml0gb3Ig KDIpIGEgQ29udGVudC1Gb3JtYXQtU3RyaW5nLg0KDQogICAgSSBjb3VsZG7igJl0IHF1aXRlIG1h a2UgdGhpcyB3b3JrLCBhcyB0aGlzIHRoZW4gbG9va3MgbGlrZSBDb250ZW50LUZvcm1hdCBhbHdh eXMgaXMgIHJlcHJlc2VudGVkIGFzIGEgcGFpciDigJQgaGF2aW5nIHRoZSBkZXNjcmlwdGlvbiBh cyB0aGUgYWx0ZXJuYXRpdmUgaXMgYmVzdCBsZWZ0IGluIHRoYXQgZGVmaW5pdGlvbi4NCg0KICAg ID4gQWxzbywgQ29udGVudC1Gb3JtYXQtU3BlYyByaWdodCBub3cgbWVudGlvbnMgIkNvbnRlbnQt Rm9ybWF0IG51bWJlciIuIElmIHlvdSBkb24ndCBkbyB0aGUgY2hhbmdlIGFib3ZlLCBpdCBtaWdo dCBiZSB3b3J0aCBhZGRpbmcgdGhlIGZvbGxvd2luZyBjbGFyaWZpY2F0aW9uOg0KICAgID4gDQog ICAgPiBPTEQ6DQogICAgPiAgQ29udGVudC1Gb3JtYXQ6ICB0aGUgY29tYmluYXRpb24gb2YgYSBD b250ZW50LVR5cGUgYW5kIGEgQ29udGVudC0NCiAgICA+ICAgICBDb2RpbmcsIGlkZW50aWZpZWQg YnkgKDEpIGEgbnVtZXJpYyBpZGVudGlmaWVyIGRlZmluZWQgYnkgdGhlDQogICAgPiAgICAgIkNv QVAgQ29udGVudC1Gb3JtYXRzIiBzdWJyZWdpc3RyeSBvZiBbSUFOQS5jb3JlLXBhcmFtZXRlcnNd IGFzDQogICAgPiAgICAgcGVyIFtSRkM3MjUyXSBvciAoMikgYSBDb250ZW50LUZvcm1hdC1TdHJp bmcuDQogICAgPiBORVc6DQogICAgPiAgQ29udGVudC1Gb3JtYXQ6ICB0aGUgY29tYmluYXRpb24g b2YgYSBDb250ZW50LVR5cGUgYW5kIGEgQ29udGVudC0NCiAgICA+ICAgICBDb2RpbmcsIGlkZW50 aWZpZWQgYnkgKDEpIGEgbnVtZXJpYyBpZGVudGlmaWVyIGRlZmluZWQgYnkgdGhlDQogICAgPiAg ICAgIkNvQVAgQ29udGVudC1Gb3JtYXRzIiBzdWJyZWdpc3RyeSBvZiBbSUFOQS5jb3JlLXBhcmFt ZXRlcnNdIGFzDQogICAgPiAgICAgcGVyIFtSRkM3MjUyXSAocmVmZXJyZWQgdG8gYXMgQ29udGVu dC1Gb3JtYXQgbnVtYmVyKSBvciAoMikgYQ0KICAgID4gICAgIENvbnRlbnQtRm9ybWF0LVN0cmlu Zy4NCiAgICA+IA0KICAgID4gKENvbnRlbnQtRm9ybWF0IG51bWJlciBpcyB1c2VkIGFsc28gaW4g c2VjdGlvbiAzKQ0KDQogICAgQWRkZWQgaW4gaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92 MS91cmw/az0zODFiYzI2NS02NzgwZmE4Ny0zODFiODJmZS04NjA3M2IzNmVhMjgtMTM3YWM3OTVk YWQ2MzdhNiZxPTEmZT0yZDEyMzU3My00YzhjLTRkMTgtOTk5Zi1mOTNmMzcxNjY3MDgmdT1odHRw cyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGc2VubWwtZGF0YS1jdCUyRmNvbW1pdCUy RjY5MjNkOGMNCg0KICAgID4gNy4gLS0tLS0NCiAgICA+IA0KICAgID4gRlA6IEkgd291bGQgaGF2 ZSBhcHByZWNpYXRlZCBhbiBleGFtcGxlIG9mIHVzZSBvciB0aGUgImJjdCIgZmllbGQgaW4gU2Vj dGlvbiA0Lg0KDQogICAgQWRkZWQgaW4gaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91 cmw/az1kMDQ4NzJjZS04ZmQzNGEyYy1kMDQ4MzI1NS04NjA3M2IzNmVhMjgtYmIzZmIyZGM5Mzcx ODJjNSZxPTEmZT0yZDEyMzU3My00YzhjLTRkMTgtOTk5Zi1mOTNmMzcxNjY3MDgmdT1odHRwcyUz QSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGc2VubWwtZGF0YS1jdCUyRmNvbW1pdCUyRmU4 MTgxZDYNCg0KICAgIFtBcmk6IENhbiB5b3UgY3Jvc3MtY2hlY2sgdGhpcyBuZXcgZXhhbXBsZT9d DQoNCiAgICA+IDguIC0tLS0tDQogICAgPiANCiAgICA+IEZQOiBJIHRoaW5rIGFuIGV4YW1wbGUg dXNpbmcgYSBDb250ZW50LUZvcm1hdC1TdHJpbmcgaW5jbHVkaW5nIGEgcGFyYW1ldGVyIGNvdWxk IGhhdmUgYmVlbiB1c2VmdWwuDQoNCiAgICBBZGRlZCBpbiBodHRwczovL3Byb3RlY3QyLmZpcmVl eWUuY29tL3YxL3VybD9rPThiNDE4MjA3LWQ0ZGFiYWU1LThiNDFjMjljLTg2MDczYjM2ZWEyOC0y YWE2NjEyMmM1NmFmNjVhJnE9MSZlPTJkMTIzNTczLTRjOGMtNGQxOC05OTlmLWY5M2YzNzE2Njcw OCZ1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNvcmUtd2clMkZzZW5tbC1kYXRhLWN0JTJG Y29tbWl0JTJGNzg2MjJjOA0KDQogICAgPiA5LiAtLS0tLQ0KICAgID4gDQogICAgPiBGUDogSW4g U2VjdGlvbiA4LCBzZXZlcmFsIGNvbHVtbnMgZm9yIHRoZSByZWdpc3RyYXRpb24gb2YgU2VuTUwg bGFiZWxzIGFyZSBtaXNzaW5nOiBDQk9SIGxhYmVsLCBleGkgSUQuDQoNCiAgICBBcyB0aGV5IHNo b3VsZCBiZToNCg0KICAgIFJGQzg0MjggMTIuMjogIFvigKZdIHRoZQ0KICAgICAgQ0JPUiBsYWJl bHMgU0hPVUxEIGJlIGxlZnQgZW1wdHkgYXMgQ0JPUiB3aWxsIHVzZSB0aGUgc3RyaW5nIGVuY29k aW5nDQogICAgICBmb3IgYW55IG5ldyBsYWJlbHMuIFRoZSBFSSBjb2x1bW4gY29udGFpbnMgdGhl IEVYSSBzY2hlbWFJZCB2YWx1ZSBvZg0KICAgICAgdGhlIGZpcnN0IHNjaGVtYSB0aGF0IGluY2x1 ZGVzIHRoaXMgbGFiZWwsIG9yIGl0IGlzIGVtcHR5IGlmIHRoaXMNCiAgICAgIGxhYmVsIHdhcyBu b3QgaW50ZW5kZWQgZm9yIHVzZSB3aXRoIEVYSS4NCg0KICAgIChPZiBjb3Vyc2UsIHdlIGNhbiBk aXNjdXNzIHdoZXRoZXIgZGF0YS1jdCBpcyDigJxpbnRlbmRlZCBmb3IgdXNlIHdpdGggRVhJ4oCd LikNCg0KICAgIEFsbCB0aGUgY2hhbmdlcyBhYm92ZSwgcGx1cyBzb21lIHJlbGF0ZWQgaG91c2Ut a2VlcGluZywgYXJlIGluDQogICAgaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/ az05ZWM3ZTAzMi1jMTVjZDhkMC05ZWM3YTBhOS04NjA3M2IzNmVhMjgtZWNiYzRkMmRkZmY2MzZi OCZxPTEmZT0yZDEyMzU3My00YzhjLTRkMTgtOTk5Zi1mOTNmMzcxNjY3MDgmdT1odHRwcyUzQSUy RiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGc2VubWwtZGF0YS1jdCUyRnB1bGwlMkY1IOKAlCBz dW1tYXJ5IGluIGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9M2QwNmY0ZmEt NjI5ZGNjMTgtM2QwNmI0NjEtODYwNzNiMzZlYTI4LTNhZWQ1ZTBmNTQ1NjE3MmImcT0xJmU9MmQx MjM1NzMtNGM4Yy00ZDE4LTk5OWYtZjkzZjM3MTY2NzA4JnU9aHR0cHMlM0ElMkYlMkZnaXRodWIu Y29tJTJGY29yZS13ZyUyRnNlbm1sLWRhdGEtY3QlMkZwdWxsJTJGNSUyRmZpbGVzDQoNCiAgICBH csO8w59lLCBDYXJzdGVuDQoNCg== From nobody Wed Sep 8 09:32:08 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 936013A2E2C; Wed, 8 Sep 2021 09:32:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: core-chairs@ietf.org, core@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163111872465.7628.4721954292353432305@ietfa.amsl.com> Date: Wed, 08 Sep 2021 09:32:05 -0700 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 112 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 16:32:06 -0000 A new meeting session request has just been submitted by Marco Tiloca, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair conflict: ace cbor t2trg cose lake artarea asdf Technology overlap: teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw iotops Key participant conflict: irtfopen rats suit dnssd netconf netmod emu dots anima People who must be present: Jaime Jimenez Francesca Palombini Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Wed Sep 8 10:19:57 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E753A2FAA for ; Wed, 8 Sep 2021 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90b2ybI6snEb for ; Wed, 8 Sep 2021 10:19:49 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00075.outbound.protection.outlook.com [40.107.0.75]) (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 B4CA43A132B for ; Wed, 8 Sep 2021 10:19:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZIjWOgVIOkZBEh5hMpgge0ynNN9i77/7K4j99xhc62l7+ZPjpen5ZbqFZzRnnVYwJ0bId/N/XGvlOfmoTmuFdll7eMlWumLDlWT+v+xZmXqulo0YaCEnM7OOkLAAStcnSMEmDlu8mc/6VADFbKvaCbiesIoqgAovLjAGYfvKdA7dr+bFbBzrgETLvCVb6R9ZWFet3jB4W9QtaZbtb1TJVELtKIZs0oXTXhNUG+x1Ngn/OEwwVLSMBsq8Eucb3pgPJaaPM4iDc4MAv1YE5Rl2EJVkpV785Bjq3AIAZBmNgVJ205Qs3viRROP45bBZg1AsLbsWgDKjFj902T3lOPb8Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+wO5ReAvLe2gXud3nGTNIYrDPLplMnrXN9ZiP32PNCY=; b=BezUqbEJV2U5EKWnSybO8me5W19RlDFzaU2fT793bkrD49Feyb3ciNHdiWh9UjpEF5xe7kclGoPnsW2W6Og2Vgbs27PU01Ov2NFhEznSwkZqq4IqUYFhkv46s3Xp73SvIP6Vx/eXQFR0QMbha+2KJL29ttnTDPPFbxODHj75T1nHn25vivqRUpR3sAkhq4LIYFybuFpKDYQatYdroPToz8V+8byfUenj8pOfO16RaDt4/DO004C8txMnE+25kD565Qc2s7P8XQcV1q32ZvaMaCZ3uHi/8lCpybtsRvvsg+FPdr8Uh1HKpfWK1sv+09AK5SBGGKC9yL3yD9GkWSv+xA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+wO5ReAvLe2gXud3nGTNIYrDPLplMnrXN9ZiP32PNCY=; b=dA5/8CXU3TBBBK6fsmyJmZPb8eSp+fvCiowH1dSGfcu3DwCBVzTlM93fbXdLNcjrYrXP6TncU5BvXWzzPrxt25sscJoWMbDC7aZ2sj7xCwUB6GKOHIGC0Ym3tcFKCGumlFalTGxrds2y8iewPdZ4A2qjhgZjmEsxJv/Jp544Iuk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0102.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.22; Wed, 8 Sep 2021 17:19:41 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172%6]) with mapi id 15.20.4478.026; Wed, 8 Sep 2021 17:19:40 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <04cf2ef3-7d53-2b8a-51ce-eef1e57731d3@ri.se> Date: Wed, 8 Sep 2021 19:19:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fOMz2SkPVuSRn6ij5Sr3cwMh6twfsLnsc" X-ClientProxiedBy: HE1PR0101CA0010.eurprd01.prod.exchangelabs.com (2603:10a6:3:77::20) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.2] (185.219.140.230) by HE1PR0101CA0010.eurprd01.prod.exchangelabs.com (2603:10a6:3:77::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Wed, 8 Sep 2021 17:19:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6634ba39-81d9-4369-7877-08d972ecd79f X-MS-TrafficTypeDiagnostic: DB6P18901MB0102: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5ok+UL3TTt+w/0YZXBWg/3NRHx4HXw2sChYDuPkxHGSExyuUru1qDMGBaoVKbeQ/5X8zX4t64bl0VaJkJF/RwdaeRCMo+97IWQKi5VCnIMt4tIvXT6j/dFWmmnqD3XPYLUbxDgu1sLvhU9P5s6e9mMZrrQrpIMcnQ++iCQExOQPDr4DIeffPjx9xlCLBt+YpXCf2quSuP/WE1eCMejbOlRcMwIGfBN7fZplJ+jRntGmNeV9pjNqJA/uRcxTPrcTKuyAifnmyZU1HODcEBBSsc761RMnSMSltIJkYabssxQVxCfCjwY/pXU145wuk0jAlcsVwkq0KUGiGQz9zyQnzHVA4yN3nFMncIO+Cr+O7sguuWu8wMNA8FM8EhoN3hKv87WDGss/8YQMWL7TwT7J5/tq8xfUfU2dgZCG8SXsxrttSCFmw7i+WVyr1jzSI/DBp3WV+gfxTwqgy1Uq5O8QcjWtdNbVHl8B6ZNgqIL8SEKfRXk5lyO+04KfaXimzwmG/Kd2DJZg1a0Pp/6G6E7Q85NaqFV2F/pju83XC8mhNnRJiVfsjEFpPRmSPFci99AN5lxX0QyvMK8vC2SF/aZSKheWssXSD2B+Hc/4z0+Q8C3OBxNa8dBL4ss5srYKkaddiBUCq4a7q9gFERGn77EaAp7EV7grSRg9wS3dmyWK+14AbLh431Xr33tuG6jUrtgj/Sn8I9fXPPZlqMlMA7H3V6h2opmbZ7J4NhOZvpT0vVgt1QDB/OjO3y19P5q6ShLO5theR5Zo/eFqKYF61b7AAhQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(136003)(39860400002)(396003)(38100700002)(86362001)(31696002)(956004)(36756003)(8936002)(8676002)(2906002)(31686004)(44832011)(21480400003)(6486002)(2616005)(83380400001)(66574015)(16576012)(5660300002)(316002)(235185007)(66946007)(66476007)(66556008)(186003)(33964004)(966005)(6916009)(26005)(478600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VDRzdmNiMy9Fd2VMQ0poeXE2elJpaXBXOHdoMXdPbGZ4dlFSd3poUTZRR1Qx?= =?utf-8?B?VUlPb0xxb0gzQnhoU24rcThqYUh0WEVhMTh5Rjl6bm1oOC9jOGQ1VkFwK1g4?= =?utf-8?B?SWI5RkRzSzAxaUpDWE9HNmN5ajVmQ1pGNldweXM2NTZmRjlZdDhudGJYd1hF?= =?utf-8?B?N0t6cllFY0JyRlNhd1paS1poUEplNS9Sd1E5OEpmRUcvWnhsU0prS0QrZjRN?= =?utf-8?B?eGVGSnoxT3FyN2t3cm5XUEwzcGc5eVcwY3h4bkRsOFJWTXNQVG9BdnY0enNk?= =?utf-8?B?TGFYa2F4Y05QNk96US9NS092c0JiVWwwczczVkErNWYrRmRTdDRyL2RzQkl2?= =?utf-8?B?Z2c3YUxzdDh1b2RTZFBFR0UxRGZGNWUyTUM0S1JTajJXYlhwYVhvcElwV3dJ?= =?utf-8?B?UXJpbEpvRjFTYkF0bDBYZmdkQmhpQ0tWSHRMWXBvVjVheFd6Z0lUcHJsTVVv?= =?utf-8?B?bldhTnBPQmlua1NrMitpVEtVcjVtR0JLOC96QTl0cDk5bDFveFBxUHBWOXoz?= =?utf-8?B?eWZGZjV2anl0WFVHNng5WVF3QkFBSkczTFJGMnZYbGlYaFM4YXZuNk15cThR?= =?utf-8?B?WDErd2d2QkpyUHJFSzRFSmFyakk5S3hRYXMzQUYya3lpSDh0cnRKYUhPOUlM?= =?utf-8?B?MFZkYUNnblhRajk2ZldidURTUHBsNXFxd1pFVUg0bTVUakxiY0VTWS83L0RQ?= =?utf-8?B?UnRhYjRRc0h2SlZUUUg3N0UzWDU2VWxOcWlCNTN2ME53WVVOblJSYnFyRCtk?= =?utf-8?B?Y1B4OTlRKzhXbGVSa1RGeWEraUVzcWRzSnB1NE11U0ZOVm1Lc0ZSclE3NEl4?= =?utf-8?B?R21MWkV3QmE0WnB1YVd2enFNMk1uY3VBZlFuSmlrWnVMYUdPOFlPc29wOFRy?= =?utf-8?B?VkJUem9GRDVwaWNTcDdEdWhaV29VOGg1NVZLQkRKb1pWNlpyR2J2TENIZkRT?= =?utf-8?B?RFZnM1NSVDdYTmZSQU1vY3ZJTjZ2OTREMVljdk1PNWU3N0VDdEJSSVNvSXg2?= =?utf-8?B?VS83cTV3UXpJcFlQMFpoRTJaV3dIOHA4ejhsY0kxdW0zd0N4aWtCejFldVho?= =?utf-8?B?NTBVbzZuY1d4OWNOZHNNdW1ucCt4SG9GeE92ZTN3T2VsU0h5QjhVTjI3RlVF?= =?utf-8?B?YzFSMC9tSUFjNUpQeDR4RFVLWjYwMFRtUWpvOWkvZDF5R3l0TzdvNFlFTzFv?= =?utf-8?B?UEM2ekQ0RVU1ckQxY3QvbmovQ3I0MkdUUFRmbkpvQXFjQTd2QnVkeHZwSzFY?= =?utf-8?B?TnZLZHA5VUVUMkZpWkxYYWJkR1hpU2M4cTdqZ3FwNGZ0R2xzYWp0aWdxbmRH?= =?utf-8?B?T29NNTRkS1FNQ2p1SnJVbVdOeG42K3ZuRm5ONjFRQ3NQYUV1NVBLTks3Mit0?= =?utf-8?B?TXlWK3BaZ0dOWlVURTBqaXFOR1crZlJzOTJJanQ1S3RKaEI5WFhnTjF4dUJk?= =?utf-8?B?RzdiUU94Z2pPYlBsN01hRU0zRGcxTFFENUgyNmRhcG8zY09TbWVkbCtoMFRZ?= =?utf-8?B?NXJJdHRQK08rcDdKZGJ0S0hJeUxydDkyVjEveEtjcTdvYUlqUDRTWjdqb3B1?= =?utf-8?B?Y1VsaFVFalVzaytwQkluSVVOSGtla21QQjAyYll3NjZvcnVkM0h2blpmMFlv?= =?utf-8?B?K1d1WStHTFlPcnFkZDArdTBtaTkzNXllM05xQ3lSakJjYnViRW5WZm9rbGhL?= =?utf-8?B?RmlDSjYxQU1NQXlOWWFxVU1USlkrajFrNTJvalhJRDhCOUVCa0hnbG1SVFB3?= =?utf-8?Q?oaD+Eo+jSPBoQPEdVZhOvL72bDaU76E1VguPqCx?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 6634ba39-81d9-4369-7877-08d972ecd79f X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2021 17:19:40.7077 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fox/VWicxx8mtWrnxkLhSOqjWP1DFH9ss0ZU6D3gojpo9Q4967f6aMyWELfhYkt1McVS0owoU4viACbYbTnTfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0102 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-09-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 17:19:56 -0000 --fOMz2SkPVuSRn6ij5Sr3cwMh6twfsLnsc Content-Type: multipart/mixed; boundary="BddjWcmfLc8PdHztJ2L42aXr1uPtl2h5P"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <04cf2ef3-7d53-2b8a-51ce-eef1e57731d3@ri.se> Subject: CoRE WG Virtual Interim 2021-09-15 --BddjWcmfLc8PdHztJ2L42aXr1uPtl2h5P Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 September 15th at 14:00 UTC. The agenda is available at [1]. As per the Datatracker, the meeting will be on Meetecho [2]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-10/session/cor= e [2]=20 https://meetings.conf.meetecho.com/interim/?short=3D086b9da2-6dc7-4de8-89= 69-ef42503ad5cc --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --BddjWcmfLc8PdHztJ2L42aXr1uPtl2h5P-- --fOMz2SkPVuSRn6ij5Sr3cwMh6twfsLnsc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmE48KoFAwAAAAAACgkQ7iZktA5Y2kOl swgArD2Fadzip8SMo8mUo3DcmkiT00e1hVaSTNRiBaAOHirBS08xmp/RqDl7HoGsj71wjqns2kqJ WsM8q4pA2QmagyG+c/BVQLrVh9eRKPqOLCm6Fh9sUFm/A9LWKaFnlyT1uJyXoCr7Y/stYmYlQ6Lm ypN91Ppry82yxM/Dz5iYnJvWBV+7DIw3WwDVyltOjF/uccXYntYuBavjRVv2zYi2gvqeb3Cu9ooO QGQUbZCZZhaJdWw1xLbxsSnzCr3TWXMK8DsQym6W4NomiesG/bcLu1FLiEtW/MDYKB94oRlgGP34 W3I7831sgHgqzZD/y5hZLaj17NskNKfJx18sQliH6w== =qj5C -----END PGP SIGNATURE----- --fOMz2SkPVuSRn6ij5Sr3cwMh6twfsLnsc-- From nobody Wed Sep 8 10:34:43 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D973A3025 for ; Wed, 8 Sep 2021 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28tXCiLoARGR for ; Wed, 8 Sep 2021 10:34:35 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60075.outbound.protection.outlook.com [40.107.6.75]) (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 D06F73A1480 for ; Wed, 8 Sep 2021 10:34:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=glwlkMOeg6uREILfPEw5XSkHCX2g63Jr0qtvDxhho9d0HrRuk9yCsDDQbfZds6LsYfJ/m5ogn3LoTrT4yeRK1bHdTAC0N+KtV1gFCAvyK1Qm/jCQ6KO/vqE4/q8+pJltATkfAuKBWIlSFQK/1pxfH5PqMHJ8tbDl686Oe3QTvM4M/lX4LZ8pfnrzluH8exnR/GjicjJ8pTK1i7v8VINKzhoaxEqfwJGE8RLwO9JyC3INK5+RniwPO7dhXU8e3xCWUFgLuwhCshrakh0GyP297Y6i+arUMFUFefrQCt05QZH7TekSWud+ElL4LChS/MMp4TDJ7cuwpq66Cf/DxNdRqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hrl7i2qOZYXh/YLO6MpHEqcmjGqmcKvBJCXLkbN5IuQ=; b=Pp+L9ygPZLyrhmMluJQ+rVOrce5IMkpR3iL8bL4oVwiRBU6ZKJRi+Q82ocsWIinCo6U6OIEaV7l2ZFK+A50A19gv3nQAp+Ng9IztRRb7Khv7+5NfjJB+Yz8u0Jsp9QXmMJdtOBfySkbzgMLNINY7tiW99XbJBlRzMfa0Yvvmd7tUG3WfCUkaleEddIIndnI/fSNeFCFOH72/xqxi/mLfm1XsJRvaAqAdljiu4MA9oy3yW3NyFNfBChWX+rjMK+e/wD56GZ/+83nh6TEcKu1K9MUcHZdPSN4nmzS3hOHqgvlB/Ohw1NMZMD/snE6/OgfYd5QPYcK0Gn3PjrpZuL6kzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hrl7i2qOZYXh/YLO6MpHEqcmjGqmcKvBJCXLkbN5IuQ=; b=H0nEvphBbP5T6brtHuWUVHKMmvm5rfzBQUPpk842q66/KudyWDyDGBjeG1tj6+Mz3rbGP/e6udRG1h4h+PHQZkJUh2mJ5lDdScveUCKhWflpgwvX45wADR2Wwyku/VbM1O3Zw6jwJW+UfQ9N/P+sdoCvwa8FSDf5sOHmkNPH2xw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0503.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:31::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Wed, 8 Sep 2021 17:34:28 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172%6]) with mapi id 15.20.4478.026; Wed, 8 Sep 2021 17:34:28 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Wed, 8 Sep 2021 19:34:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="91LWUYVh10XIOkBpb2pvHLO3x3i0YWf1h" X-ClientProxiedBy: HE1PR05CA0148.eurprd05.prod.outlook.com (2603:10a6:7:28::35) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.2] (185.219.140.230) by HE1PR05CA0148.eurprd05.prod.outlook.com (2603:10a6:7:28::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Wed, 8 Sep 2021 17:34:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 94146354-6e16-4cf2-a96f-08d972eee8cb X-MS-TrafficTypeDiagnostic: DB6P189MB0503: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UNPZ9wwEm11exvCUYUgwC8i8u1D0JcSMjuVDOayDzVh6//cloMjPtNQsQc40tcSFqfauINf/qMURk9pCaYLFTLXjYmdAK1ZGtbjYWFWtsxQax0ZVnqJnVvOsEx4zqIknzoEamgJHRK4pvggwO391j+m/qwBhW4BHvbCvL52fLkOna2v4S1/aOBWL4do0pRhpcaKiuVamAzOHuBQtSglJUbW2lVw3L4y9zcT11ca2zfVeQSU4WvPOx89ThrST3n2gV9tCLYbJh77n4VJevpWgHWhgto9VAYs7+C5B1TRBoymksrvz1r4M3ZHahImEzIFFsCe0YOW4fuVOBF1LZC8H3miQiKUT8XkXixz7Z/YZ7o8AHbPWzPu9eG7oDVP7/HDzHzA6O7t6zplBkn2o3zJjsx+/pFaGEdwZrCHYccigX8aH0YE4Buij59TZZaABGs0okH98ijLWfIiEAvve3ST5I3U16G3nHL9CoksCzvhVVlKc8ssbMMu4ntjhVlycv//o0QTEVdCTj0To1mE50h7aBUg1D5VZXnFnyCvCLmp/BSbCkGqd6xe6Knhc7ezQ3rbAxV/RVU432a4YT4lB6s5Wgpt4l00X6lasBeqD1Wx6haSxkbBh+SIMN/mKpnjTe8oVF/VkYaPIPDUXSxlRlKEFaVtk7GEo7qBlUOLL0UcxGhowtfjaj1DE1rnRGPYnJKGJmcYhIq374F+yPJ2Vl9OuBrsUuV9jdAirS5T+rjd1aQpNyu8kJ7GW5Z2ouqC0SPsFlM/bu5XexWekVE/kJ4L5VxGd6P+M0D9JaHaPj++fPwq+F621KBH0IEauyCI/AnSr/bH+NUyXThyiVDkwhFY+Ag== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(39860400002)(136003)(366004)(316002)(66476007)(31686004)(8936002)(8676002)(2906002)(6916009)(66556008)(33964004)(30864003)(2616005)(66946007)(956004)(186003)(83380400001)(36756003)(5660300002)(31696002)(966005)(44832011)(21480400003)(66574015)(6486002)(26005)(478600001)(16576012)(38100700002)(235185007)(86362001)(35304002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MDEvYjNVRFZ6cXZRcURadW1VbXo4blVyWDZOd1owd2VwTTYybTBLOWIveWtR?= =?utf-8?B?cUFPNVI0ZnVWRzErSVJwd3FqTWkxZXZEeGZ3Qmg3Snd5emxRalhUZEpwQ0x4?= =?utf-8?B?Wm1UelRiYWJXWUNPRFBFejFiazV3L2ZUWkRoRjFkaW9jTVpvakNwVUZkbTJa?= =?utf-8?B?MmtGQUl0d0FpaE5MQUtxUkRCL0k1aVJVdDZ2d2lXWXo0T25jaFJYdjZkcWlJ?= =?utf-8?B?ZXNPQWE4cUZEOWtzYWJwNksyL0pLSlkzc0NZU2VidGhXVmxKQlhDMjdyc0tC?= =?utf-8?B?TkxySHdTKyt5ejVZN3ZsRG9YZmxUSVIyVUZWL2MyTjdTVnJxYTc0aWNRclZO?= =?utf-8?B?STZ2b1FWK1dEaFBuQURTQ0kyUW9JQkhMaU9pTHN3cHk0VkpHenVOZ1dqejky?= =?utf-8?B?VXVDQ1B0UEhwTzVUaGt4YWVhL1FaNFhUTTErWUhVYUE1MCtocVQwcW0zdVQ0?= =?utf-8?B?V2oxNld3aEsxV3hOZkRKVUdTVVI3bHpsNTRZSWFKN1pweklscFlVdzN5UWYv?= =?utf-8?B?cmtKTlVOTzZtWndINVVVUjlvcTRpSFArWVVtMnZuVVBjOXZmN3hROHNoTSty?= =?utf-8?B?bXlDK3oxR3hlZElKS20wU2cvUW5QeUQramkyS1ZZbVZRcmJVZ3dmRkM2MlQ0?= =?utf-8?B?aDlXOGFaVmxMVTAwLzMwR3l1aXBIaUxHYTlVZDdROEwvbEtRSEFLRWJlRVNo?= =?utf-8?B?VjV1ZFpLbENkV0lhSHZPTW1FVHJZR0hPNXhCR21aQ2RJS3pqM2YvRkRhb2Ew?= =?utf-8?B?bTlPZmJESnZnVkhvUHZqOVhWQzRFQTUwMU1USE01UGtKM0xKZ0lGS1NxeXM3?= =?utf-8?B?RHdwS3ZweFM4aWkvMVpmZjYwNjBuWStscVlvdG8zRlUvQVovNVRGc1oxMjJn?= =?utf-8?B?RzF2NlBIT0FrZzJrK2hVZXg1ZS9XZ3JNak56dVNRUDVZVW15eHVaY3BWZVBN?= =?utf-8?B?bVM2TzZseTU3MUV5aVAwK0V2ZnpsQUY4RUI3T2pxOWx3Z1VEVUp2bmtSU2Z6?= =?utf-8?B?MXRhQkdtdGlwNWUxRVp2QXlxdzlqaEtzRmgyTnIwTWlRN1VmemU5OGdIT0dY?= =?utf-8?B?MzlrMVNhMlRTKzhsOWl5SXlVNFVBSkMvZWs1VUhPc0FPK211aEoxNXE0aDFx?= =?utf-8?B?RzEydy9lVzZsTUZ2MittOVJCMUNKMFNxV1hud3prZVB0aE9GWWVIVmMyeXd1?= =?utf-8?B?UUlHdXdvQVB5TzVGWDdZRHFSZlJlQnUyQTFKUzJrMUZwRlRPUElFWjh4SWhR?= =?utf-8?B?dGpQK09vTVp5NlVvbHNvbnoxQkNnbytiU0cvZmlPTGxIVXFnUlZMMzFFekEx?= =?utf-8?B?SmVtVzZjTUdKblRqUFRGdnIyT1M5dlB1WWJkMVJuY1BrR3RYeWErUURLUnpD?= =?utf-8?B?WVBWa2R0ZHlXK1ZPMTR4OUNzU0tqbE9hcTR6ZHZyMG5Rb2dabVc2eTBqVDRj?= =?utf-8?B?WVBEd2NCZ2NWV2krV2VONHBzWEE5ajBneDlscFVjYmlpeEZ1YnlhY2I2RXov?= =?utf-8?B?VVdHZms1UFJneW1SZ0RjWVptbWZNbFBON0lycHJQU0pRcGIwM2cwK2IzNmJ5?= =?utf-8?B?akRWYklZYVRVZzVGMzIycENvWDZHWDVJa1A2VGk2UWhqdTFKR083MWtVTEt1?= =?utf-8?B?TGJ2OFhMV3MzMHNWcmtPazNkU0Fyb3BnMXdDN0NqSzlHM2RCSzlNOFU1ZmFN?= =?utf-8?B?OU1hcG5zRVh5UllKM2lUYkdLMnRiVE5hc0ZSbmU4OHFpTUVLTlkwVlF0ZGxR?= =?utf-8?Q?uxFF6DAvQ/AZ4uwZ1Wu1qm5AiAlKpnNXkiO+ILO?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 94146354-6e16-4cf2-a96f-08d972eee8cb X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2021 17:34:28.4105 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: gQrPD7sS2DRA0rVRHGoijCyaaZclOTHrj6uGdkh0rKq4lyCoOy2ytE6aG6xGIh2JxrEe0eBPFPVIbfm3vuaM5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0503 Archived-At: Subject: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 17:34:41 -0000 --91LWUYVh10XIOkBpb2pvHLO3x3i0YWf1h Content-Type: multipart/mixed; boundary="6BE7XqiLAh1mD1RlIgBH9VZKdroPD8i7T"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: CoRE rechartering: proposed text --6BE7XqiLAh1mD1RlIgBH9VZKdroPD8i7T Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, During the CoRE session at IETF 111 [1][2], it was proposed to update=20 our charter, for better reflecting the current status of our work. This=20 is also helpful for the IESG review processing and for newcomers to more = easily understand the WG scope and direction. As promised, the Chairs have prepared an initial proposed text for the=20 WG to consider. Please, find the proposed text at the end of this mail=20 as well as in the CodiMD at [3]. With that as starting point, this mail starts a discussion on the new=20 charter text. Please, provide your comments and proposed changes here on = the mailing list or in the CodiMD at [3] (editing requires to be logged i= n). Best, Marco and Jaime [1] https://datatracker.ietf.org/doc/minutes-111-core/ [2]=20 https://datatracker.ietf.org/meeting/111/materials/slides-111-core-chairs= -slides-00.pdf [3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The CoRE Working Group (WG) provides a framework for resource-oriented=20 applications intended to run on constrained IP networks. A constrained=20 IP network has limited packet sizes, may exhibit a high degree of packet = loss, and may have a substantial number of devices that may be powered=20 off at any point in time but periodically "wake up" for brief periods of = time. These networks and the nodes within them are characterized by=20 severe limits on throughput, available power, and particularly on the=20 complexity that can be supported with limited code size and limited RAM=20 per node [RFC 7228]. More generally, we speak of constrained node=20 networks whenever at least some of the nodes and networks involved=20 exhibit these characteristics. Low-Power Wireless Personal Area Networks = (LoWPANs) are an example of this type of network. Constrained networks=20 can occur as part of home and building automation, energy management,=20 and the Internet of Things. The CoRE WG will define a framework for a limited class of applications: = those that deal with the manipulation of simple resources on constrained = networks. This includes applications to monitor simple sensors (e.g.,=20 temperature sensors, light sensors, and power meters), to control=20 actuators (e.g., light switches, heating controllers, and door locks),=20 and to manage devices. The general architecture targeted by the CoRE WG framework consists of=20 nodes on the constrained network, called Devices, that are responsible=20 for one or more Resources that may represent sensors, actuators,=20 combinations of values, and/or other information. Devices send messages=20 to change and query resources on other Devices. A Device can send=20 notifications about changed resource values to Devices that have=20 expressed their interest to receive notification about changes. A Device = can also publish or be queried about its resources. Typically, a single=20 physical host on the network would have just one Device but a host might = represent multiple logical Devices. The specific terminology to be used=20 here is to be decided by the working group. As part of the framework for building these applications, the CoRE WG=20 has defined the Constrained Application Protocol (CoAP) for the=20 manipulation of Resources on a Device. CoAP is designed for use between=20 Devices on the same constrained network, between Devices and general=20 nodes on the Internet, and between Devices on different constrained=20 networks both joined by an internet. CoAP is also being used via other=20 mechanisms, such as SMS on mobile communication networks. CoAP targets=20 the type of operating environments defined in the ROLL and 6Lo WGs,=20 which have additional constraints compared to normal IP networks.=20 Nevertheless, the CoAP protocol also operates over traditional IP network= s. There also may be intermediary nodes acting as proxies that possibly=20 also interconnect between other Internet protocols and the Devices using = the CoAP protocol. It is worth noting that a proxy does not have to=20 occur at the boundary between the constrained network and the more=20 general network, but can be deployed at various locations in the=20 less-constrained network. The CoRE WG will continue to evolve the=20 support of proxies for CoAP to increase their practical applicability. CoAP supports various forms of "caching". Beyond the benefits of caching = already well known from REST, caching can be used to increase energy=20 savings of low-power nodes by allowing them to be normally-off [RFC=20 7228]. For example, a temperature sensor might wake up every five=20 minutes and send the current temperature to a proxy that has expressed=20 interest in notifications. When the proxy receives a request over CoAP=20 or HTTP for that temperature resource, it can respond with the last=20 notified value, instead of trying to query the Device which may not be=20 reachable at this time. The CoRE WG will continue to evolve this model=20 to increase its practical applicability. The CoRE WG will perform maintenance as well as possible updating and=20 complementing on its first four standards-track specifications as require= d: - RFC 6690 - RFC 7252 - RFC 7641 - RFC 7959 The CoRE WG will continue to evolve the support for CoAP group=20 communication originally developed in the Experimental RFC 7390. The=20 CoRE WG will not develop a solution for reliable multicast delivery of=20 CoAP messages, which will remain Non-Confirmable when sent over multicast= =2E RFC 7252 defines a basic HTTP mapping for CoAP, which was further=20 elaborated in RFC 8075. This mapping will be evolved and supported by=20 further documents as required. CoAP was initially designed to work over UDP and DTLS. Later on, mapping = were defined between CoAP and IP-based transports, especially TCP and=20 WebSockets including a secure version over TLS (RFC 8323). The CoRE WG=20 will continue defining transport mappings for alternative transports as=20 required, both IP-based and non IP-based (e.g., SMS and Bluetooth),=20 working with the Security Area on potentially addressing the security=20 gap. This includes defining appropriate URI schemes. Continued=20 compatibility with CoAP over SMS as defined in OMA Lightweight=20 Machine-to-Machine (LwM2M) will be considered. Furthermore, the CoRE WG=20 will work on solutions to facilitate the signaling of transports=20 available to a Device. The CoRE WG will continue and complete its work on the CoRE Resource=20 Directory (draft-ietf-core-resource-directory), as already partially=20 adopted by OMA LwM2M, and will perform maintenance as well as possible=20 updating, complementing and specification of relevant uses as required.=20 A primary related consideration is the interoperability with DNS-SD and=20 the work of the dnssd WG. The use of CoAP to transport DNS queries and=20 responses will also be investigated. Furthermore, the CoRE WG will also=20 continue and complete its work on enabling broker-based=20 publish-subscribe-style communication over CoAP=20 (draft-ietf-core-coap-pubsub). The CoRE WG will work on related data formats, such as alternative=20 representations of RFC 6690 link format and RFC 7390 group communication = information. Also, the CoRE WG will complete its work on Constrained=20 Resource Identifiers for serializing URI components in CBOR=20 (draft-ietf-core-href). Furthermore, the CoRE WG will develop CoRAL=20 (draft-ietf-core-coral), a constrained RESTful application language=20 suitable also for constrained node networks, which comprises an=20 information model and an interaction model, and is intended for driving=20 automated software agents that navigate a Web application. The CoRE WG=20 will complete the Sensor Measurement Lists (SenML) set of=20 specifications, again with consideration to its adoption in OMA LwM2M. Besides continuing to examine operational and manageability aspects of=20 the CoAP protocol itself, the CoRE WG will also complete the work on=20 RESTCONF-style management functions available via CoAP that are=20 appropriate for constrained node networks (draft-ietf-core-yang-cbor,=20 draft-ietf-core-sid, draft-ietf-core-comi,=20 draft-ietf-core-yang-library). This requires very close coordination=20 with NETCONF and other operations and management WGs. YANG data models=20 are used for manageability. Note that the YANG modeling language is not=20 a target for change in this process, although additional mechanisms that = support YANG modules may be employed in specific cases where significant = performance gains are both attainable and required. The CoRE WG will=20 continue to consider the OMA LwM2M management functions as a=20 well-accepted alternative form of management and provide support at the=20 CoAP protocol level where required. The CoRE WG originally selected DTLS as the basis for the communication=20 security in CoAP. The CoRE WG will work with the TLS WG on the=20 efficiency of this solution. The preferred cipher suites will evolve in=20 cooperation with the TLS WG and CFRG. The CoRE WG considered object security as originally defined in JOSE and = later adapted to the constrained node network requirements in COSE.=20 Building on that, the CoRE WG has defined the Object Security for=20 Constrained RESTful Environments (OSCORE) protocol (RFC 8613) for=20 protecting CoAP messages at the application layer using COSE. The CoRE=20 WG will complete the work on the Group OSCORE protocol=20 (draft-ietf-core-oscore-groupcomm) that enables OSCORE-protection of=20 CoAP messages in group communication environments. Also, the CoRE WG=20 will complete an optimization-oriented profiling of the EDHOC protocol=20 developed in the LAKE WG, when this is used to establish security=20 material for OSCORE (draft-ietf-core-oscore-edhoc). Furthermore, the=20 CoRE WG will perform maintenance as well as possible updating and=20 complementing of the (Group) OSCORE documents above as required. The ACE WG is expected to provide solutions on authentication and=20 authorization that may need complementary elements on the CoRE side. The CoRE WG will coordinate on requirements from many organizations and=20 SDOs. The CoRE WG will closely coordinate with other IETF WGs,=20 particularly of the constrained node networks cluster (6Lo, 6TiSCH,=20 LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT), and with further=20 appropriate groups in the IETF OPS and Security Areas. Work on these=20 subjects, as well as on data/interaction models and design patterns=20 (including follow-up work around the CoRE Interfaces draft) will=20 additionally benefit from close cooperation with the Thing-to-Thing=20 Research Group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --6BE7XqiLAh1mD1RlIgBH9VZKdroPD8i7T-- --91LWUYVh10XIOkBpb2pvHLO3x3i0YWf1h Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmE49CIFAwAAAAAACgkQ7iZktA5Y2kOx tgf+J3qMXbMPrNy+7640e1u3NMUYml53Zfs/gWap6bJXj2BTMoE/t/ZCQy2Vcfn6tOZEqXQaaV8+ lnBAWslF31//r4bNEIjNma2oFhfIscqEuB6K1lbJXOpa/Tp9/i6g1byISZqifWAlzkQZodSOL7Zq JIq+pfdn6edQKFL2lUd6k7qOyQc7GA8aASFLExTSYZyyVdG/0JNp9CAEWFdimQqumXl9VifVs0H1 wB4vaAMUpdVBN52cTDIuknGnMifHGQXCkfHm1QGTOiogH7gBUec3DG6TCgKTFnTxUsKH/NlXzk6q CHyr4x28kb+VEo/aShTdK3Y0TPccu+HxDjtaIaT+bw== =B90X -----END PGP SIGNATURE----- --91LWUYVh10XIOkBpb2pvHLO3x3i0YWf1h-- From nobody Thu Sep 9 04:43:52 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5113A1072; Thu, 9 Sep 2021 04:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0s8gvl8dTG2; Thu, 9 Sep 2021 04:43:30 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2069.outbound.protection.outlook.com [40.107.20.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 78B113A1078; Thu, 9 Sep 2021 04:43:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OViWrdEScKd3+rzYOOaKKbtq70z5qpZ3qz0xqQ52MZE+IPpWmZPTRDfov8bys3A6t9vv+pVZd3+ymtZNApTCCLYJrG3xLBxz5OE/jpOvtADR8dgziLFnqnP5wPudeiuc7MdUcohKIUiownchLWHIboJMQwIf3SYEzCdz9nMXhc9bv4wrRhz04/4Vgcil17CGmOQZ4FrHpa33B5KDFDbJEtZzICOF5RNNf6luAvo1rOExLyWH1zoVmgKT2RFobeA62lSkpJafnujEpiloKIYRItjAObFDfLc2Ju1aIdSAi2gCefvdKtSDxuW8yAqYlB1ni1PMc9KTMaah2e92DkwUqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mJuZfeqD/locQt0tRwtKF61MAq8nnLrYwo7DxCfO1G0=; b=aikRvdq7RjOpA3mPAfIEUicx/mZ/hOBtyXbDu8EAfLHE6tDiGGq/iTfGZT4F/5l1nF0xkKXlGaHlntuDX6m1n++yg5mXfgKkJNABnbSBqm3TZtyZnH4L1W423/6WIXrWb8SeMAX5/In8OceamAYSgcTgcRxosiE68LazjeSFD7fPlcFBIPWoAGAepo8/cPctQB9XEhPG8LLnyjpEwJcWjCQzhD8tzoGrJtEsE1R+MRl1hsCoWE18ykoV+SPS/CtkRipYewVd2jXVEl+LMOUEH0sU3b7JCgKG8jlILD0MEnunV1P3Cvh/ZCNr2ZoiZLMYN7zWl/Wxcu3vOEAzoFpDAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mJuZfeqD/locQt0tRwtKF61MAq8nnLrYwo7DxCfO1G0=; b=Kl4nURFE9SAUyzxeVhAH5dSubVfT0P62S3r7cohLhhQHIMGqLwx/u+3Pp3gNYyDKRLH76t67xs/gyBv77Htkp+zx++CrKkw4lT3bnCVwAPnehmLK3KR4myPN2AH0n+YTXq9he4rJ0gmPg0kBKOwtMZjRJyKsoudMl/pubeODuNg= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2426.eurprd07.prod.outlook.com (2603:10a6:3:70::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.6; Thu, 9 Sep 2021 11:43:26 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875%5]) with mapi id 15.20.4500.015; Thu, 9 Sep 2021 11:43:26 +0000 From: Francesca Palombini To: Carsten Bormann , Bron Gondwana CC: "art@ietf.org" , "core@ietf.org" , "draft-ietf-core-senml-data-ct.all@ietf.org" , "last-call@ietf.org" Thread-Topic: [art] Artart last call review of draft-ietf-core-senml-data-ct-04 Thread-Index: AQHXmbVnLXYrYpL60UytXyU3w+yR4KuEgFAAgBdNmIA= Date: Thu, 9 Sep 2021 11:43:26 +0000 Message-ID: <42CEDAAF-0719-4A49-AAE4-EEE2BBC6B3D9@ericsson.com> References: <162989820511.22802.13018106629607951033@ietfa.amsl.com> <8AE2D0CA-C259-4E4A-8369-601D750DAA9D@tzi.org> In-Reply-To: <8AE2D0CA-C259-4E4A-8369-601D750DAA9D@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f321c9d-93a0-4dcd-eab3-08d97387097f x-ms-traffictypediagnostic: HE1PR0701MB2426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7lNYor9kQXPizPFJ4pM+vfgVWyF9hNGcJmv8GB2u39BDDY4qCZQyCwOp1IweQzmPp/hKtIZqJCv/8ztNEpSKRgnekW+dwHC7yN0Dar55zSCCtDfAz6ljqusXgXPo+P8RkDR7aeOCIr3r7c92Qqk8DC5eC2miDHUORuP/AiuKfpYRTQJQZg5tSsm0rDyrJoeiIysSa5Nwcbj5NDpz7cZDLhP74CbL8u3EisBu+n9TWhiMvETEL1q5OboN4FW6jSCtnkZFjg+5IuhyP8DBOKXGi5GV6xH25WnHp/QczE6Or7wt4zoKO8d4tzvWTS2zVV89/SFhdR1O3BD/yD0Aon8dq0xQ9AxeTPzTLn5rqhF4dcZg8cQ0xF/Ag0Z8dma77Dm01cq6pxVcS1o0g0ssKShOpVp2f9ju2mdMwCSSDgfKdSqiHE6wdAPlb7zceS+gbT88dci8VBt1mYCT6PA9cKBpUmBd1aI9d7k25b8xhk/CvEY5T9zBCMWjth8LGzy38kDYOhKZpa6Q981a7sKgc5ylXV/Nnam499QqlzUD1D3Iw6Ubl1RSkeQzXDG/vOEIgyD412DYX2WYqwuMUYfwJ5kFS9CTwb2WjlOUSFWvQd+MFF5w8q5LK3TdCeDx8Cr/cobr8jgXeDDbpxyWLpg8vC5Jg0C9sVjXEYJ0PPe34a0NMfBd/BTCJR047xem412MLpUv76hwAbcR2ipgh+bCfV+cF7HcE4PIjELNxWwJOxpdrrCUPEBWon/NVVBzpsTRjrazrdJfP58BmabDXUk9+68pldbU+QWbUCdbYw2kp4dAiyGY2Zf2sT8h1f/U4Pee28NWXJVjlJZk7faESjeF43pRBmQG6vXlJt9ZcfLymNpmLME= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(376002)(39860400002)(136003)(36756003)(5660300002)(64756008)(66476007)(4326008)(122000001)(33656002)(38070700005)(6512007)(8676002)(6506007)(66946007)(8936002)(71200400001)(478600001)(66446008)(38100700002)(2616005)(6486002)(54906003)(110136005)(316002)(83380400001)(2906002)(44832011)(86362001)(186003)(966005)(66556008)(76116006)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MVNYdkRhb0Q3UUhHOTJNYjJPSldTa3lXMlhOY3F5ZmN2MkVmeGtVOG1PQ3NJ?= =?utf-8?B?QVlxdTlLdytxQmh0U2VpVjJ1cTMwZGkvMk4vOFIxK3ZXeTFubTgvZ01RcVBB?= =?utf-8?B?dkZoSlp1d25BM2UzdkxVK1RHU3c4b2FFd2RMTnpLMGJkL21LVWxENDZKOStM?= =?utf-8?B?T2J0RW5xUkhXWVczM1o1Z1NVMUZMd01Kb1M1bDVENkpUVWM3SzBkbDBtSlJC?= =?utf-8?B?bU5hL29oU3NxKzJuc0cvTGJLbFBXR01ZM1RlZXowZE5MWDBqdlF6NjR3cCtp?= =?utf-8?B?OGVtYWZ0NkR5MGxrRllwYngwRHdBc29HTkx6RVZTd2xPNnJrNHRKWVlqRVNJ?= =?utf-8?B?c2FJakx4WXVHcVI4aHJROHJoOHlnOFh3bk9NemNRSkNYaWVkWXpUT0UzUnRY?= =?utf-8?B?MzFiTmhEeUNvc05pa2ZsQ0laZlNGa1Z3RjNXV3VCb3VKYjZoU3g3aC9kT2p6?= =?utf-8?B?SDlPNXNZSklTZlhUdlo0OHdjTTFqckptWERsQm9MWnRpTTJzc1JieHkzUHBN?= =?utf-8?B?NjdKbEpRNG96eEhVdmpBc0dqQ25PZEdkUmJsbGUrOG1nbFltY3p4TERHYzBG?= =?utf-8?B?Vm1yaElXL29vN2J2OHU0REV6Y2hMQXZUR0RJRktways5b1QrMitRZ0trTys0?= =?utf-8?B?Vk9ESHZDemh4NnNJaVowVDV6bHJtaGtHdVpVRzRacUNCT2RBa1VhaTNaZmRu?= =?utf-8?B?WVE2MXJKT1U1TTR4ejlSb05icVJIT0JtMXZxMVZ1L1p3dHlFRjNWMVJaRGky?= =?utf-8?B?V0hVUzNaOWVEbVBHQ2NDZUd4OXBuRjFRRHRzcGoxYTArdDlFSnJIZGVOTG5z?= =?utf-8?B?MGVmMGFGT0t2Y2QwY1ZPYU9udDU0dzlDdmdUYU9yZ0hkeU53bnJUVkdKaEF5?= =?utf-8?B?Q3VxazBJRzBTK3gwMk1GYmVaYnNreUhZVUpleHRRTkVxcVJqbWx6UGtNNzlN?= =?utf-8?B?ekdlMWdwWWRxREVac28vZ29ZRG5EYjdlc0lXQWh3NjBmNG9NOVVjcGtlWXhQ?= =?utf-8?B?R0dhSGxJa0R2aExqOTViQXdRekI4UGphQ2tKSzJNWWxNZ2RlTXRkeEJHbG5O?= =?utf-8?B?SWR4cHZrTVJ5Nk9RS2JUZi84YUtpM1BCUXIxcEc3b1A2SUt0U0hHblg3bjZ4?= =?utf-8?B?K2hZS2xvYXJmS2JpN0Jzb1Q0NWl3dUhDdU5PUWQ3b1BSR2xYV3BRMXVnUnRI?= =?utf-8?B?U1A5YVhoTEs3RGI1ZytxWnErUm4ydVBjM0tRSTFieHFrNkl4cENIQjZRNHU3?= =?utf-8?B?VGNZSnROMFEwb3dOZ0tWTjAvNUs4djg0Vy9Mc24xRkRROUsyYXVMYkxaakll?= =?utf-8?B?VHhIVnd6SDBSYVVZL1NvSm40NTMvWnpYeC9QWEpyR0VuQThldHZLYXJuL2pS?= =?utf-8?B?cmFBcUNqRnJFU2FqcU9oaFgzRWxNbVdTRGFSRWhkU2FzSUZkOHVTaktMVkJ2?= =?utf-8?B?d0NHci96TjdDekVrb0QxSERTS1p3bjNsYmhuQW1oenp0YnNBZ0lUM3VRQjhj?= =?utf-8?B?bG9KMTh1eEZQVjllbklyMWJONHJwOEJMRU4vREsvTUxYMCtsU0h2aHJYbDNy?= =?utf-8?B?VEZTblBrZzVaQTRoQ0t3VjFCaDc2NC9nTHZIMkl0R2FqMmoxRDM5UzdSbXEv?= =?utf-8?B?V1JGckg4NUtaTmUwaCtjQk80UXN5QTRaQXRGdW9VOHgrSFBVNVhNTmxGQUZR?= =?utf-8?B?ekJrWmFQbDBNWGRnRzZpL3hSVmhqWnMzbEx1eURvUHZHVU1Uc3diOWoyR1dX?= =?utf-8?B?ZHlzbUNiYmVPd3hTR001RFV4aXRkakJSKzR0d0UwVjVkcndFNmUwdmlpTDIz?= =?utf-8?B?SVVMRE01WThrRFBjeFJQN0plMWVEdVRLRjdEWk9jZXpMSGt2SUdVSk55Q3dL?= =?utf-8?B?aDNIWFduTFgrMjVoMTA3SGRRZjZZdG9sRjJjT2t2T0ZsRmc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <754C9BCC88284646BC97F9B1B927FEAC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f321c9d-93a0-4dcd-eab3-08d97387097f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2021 11:43:26.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4WAJBCpiE72kKVv0sVXjIzFq9s1QXMpfJS6fVVeu3p5JNC83ahCG6QcFmtGukY5SOjmOWBhs2a7hbfyNeM3W+854KzroccKeW4AjHqU1qXbN7cxLmzfiB5C95Lobiwm9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2426 Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 11:43:36 -0000 QnJvbjogdGhhbmtzIGZvciB0aGlzIEFSVEFSVCByZXZpZXchIENhcnN0ZW4sIGF1dGhvcnMsIHRo YW5rcyBmb3IgYWRkcmVzc2luZyBCcm9uJ3MgcmV2aWV3LiBJIGFtIHdhaXRpbmcgb24gdGhlIHVw ZGF0ZWQgcmV2aXNpb24gYmVmb3JlIHNlbmRpbmcgdGhlIGRvY3VtZW50IHRvIElFU0cuDQoNCkZy YW5jZXNjYQ0KDQrvu79PbiAyNS8wOC8yMDIxLCAxOTo1MiwgImFydCBvbiBiZWhhbGYgb2YgQ2Fy c3RlbiBCb3JtYW5uIiA8YXJ0LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNhYm9AdHpp Lm9yZz4gd3JvdGU6DQoNCiAgICBIaSBCcm9uLA0KDQogICAgVGhhbmsgeW91IGZvciB0aGlzIHF1 aXRlIGFjdGlvbmFibGUgcmV2aWV3IQ0KDQogICAgPiBJdCBpcyBtb3N0bHkgZWFzeSB0byB1bmRl cnN0YW5kLCBob3dldmVyIHRoZXJlIGlzIGEgbWlzc2luZyByZWZlcmVuY2UgdG8gb25lDQogICAg PiByZWdpc3RyeSwgYW5kIHNvbWUgcGhyYXNlcyB0aGF0IG1heSBiZSBjb25mdXNpbmcuDQogICAg PiANCiAgICA+IFRoZSBtaXNzaW5nIHJlZ2lzdHJ5IGlzIGhlcmU6DQogICAgPiBodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2h0dHAtcGFyYW1ldGVycy9odHRwLXBhcmFtZXRlcnMueGh0 bWwjY29udGVudC1jb2RpbmcNCiAgICA+IChJIGZvdW5kIGl0IGJ5IGZvbGxvd2luZyBub3JtYXRp dmUgcmVmZXJlbmNlcywgaG93ZXZlciBvdGhlciBzaW1pbGFybHkNCiAgICA+IHJlZ2lzdGVyZWQg ZGF0YSBmaWVsZHMgaW4gdGhpcyBkb2N1bWVudCBsaW5rIHRvIHRoZWlyIHJlZ2lzdHJpZXMsIGFu ZCBjb3VsZA0KICAgID4gbGlrZXdpc2UgYmUgZm91bmQgYnkgZm9sbG93aW5nIHJlZmVyZW5jZXMp DQoNCiAgICBJIGNvbXBsZXRlbHkgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIGJlY29tZSBiZXR0ZXIg aW4gaWRlbnRpZnlpbmcgdGhlIHJlZ2lzdHJpZXMgdGhhdCB3ZSBhcmUgdXNpbmcuICBGaXggYmVs b3cuDQoNCiAgICA+IFRoZSBkb2N1bWVudCBzcGVjaWZpZXMgYENvbnRlbnQtQ29kaW5nYCBhczoN CiAgICA+IA0KICAgID4gICBDb250ZW50LUNvZGluZzogIGEgcmVnaXN0ZXJlZCBuYW1lIGZvciBh biBlbmNvZGluZyB0cmFuc2Zvcm1hdGlvbg0KICAgID4gICAgICB0aGF0IGhhcyBiZWVuIG9yIGNh biBiZSBhcHBsaWVkIHRvIGEgcmVwcmVzZW50YXRpb24uICBDb25mdXNpbmdseSwNCiAgICA+ICAg ICAgaW4gSFRUUCB0aGUgQ29udGVudC1Db2RpbmcgaXMgdGhlbiBnaXZlbiBpbiBhIGhlYWRlciBm aWVsZCBjYWxsZWQNCiAgICA+ICAgICAgIkNvbnRlbnQtRW5jb2RpbmciOyB3ZSAqbmV2ZXIqIHVz ZSB0aGlzIHRlcm0gKGV4Y2VwdCB3aGVuIHdlIGFyZQ0KICAgID4gICAgICBpbiBlcnJvcikuDQog ICAgPiANCiAgICA+IEkgZm91bmQgdGhpcyBxdWl0ZSBjb25mdXNpbmcsIGFuZCBpdCBhbHNvIGNv bWVzIGFjcm9zcyBhcyB2ZXJ5IHNuYXJreSBhbmQNCiAgICA+IHN1Z2dlc3RpbmcgaW5maWdodGlu Zy4gIA0KDQogICAgKEl04oCZcyBtb3JlIGFib3V0IGJlaW5nIGh1bWJsZWQgYnkgaGF2aW5nIG1h ZGUgdGhlIHNhbWUgbWlzdGFrZSBiZWZvcmUsIHNheSBpbiBTZWN0aW9uIDEyLjMgb2YgUkZDIDcy NTLigKYpDQoNCiAgICA+IEkgc3VnZ2VzdCByZW1vdmluZyB0aGUgImV4Y2VwdCB3aGVuIHdlIGFy ZSBpbiBlcnJvciINCiAgICA+IGVudGlyZWx5Lg0KICAgID4gDQogICAgPiBJIGFsc28gZm91bmQg ImhhcyBiZWVuIG9yIGNhbiBiZSIgaXMgYWxzbyBjb25mdXNpbmcuICBJbiB0aGUgY29udGV4dCBv ZiB0aGlzDQogICAgPiBkb2N1bWVudCwgSSB1bmRlcnN0b29kIENvbnRlbnQtQ29kaW5nIGluIGEg YGN0YCBmaWVsZCB0byBtZWFuIHRoYXQgc2FpZCBjb2RpbmcNCiAgICA+IEhBUyBCRUVOIGFwcGxp ZWQgdG8gdGhlIHZhbHVlIGluIGB2ZGAsIGhvd2V2ZXIgdGhpcyB3b3JkaW5nIG1ha2VzIG1lIHF1 ZXN0aW9uDQogICAgPiB0aGF0IGFzc3VtcHRpb24uDQoNCiAgICBUaGF0IHRleHQgd2FzIHN0b2xl biBmcm9tIFJGQyA3MjMxOg0KDQogICAgICAgQ29udGVudCBjb2RpbmcgdmFsdWVzIGluZGljYXRl IGFuIGVuY29kaW5nIHRyYW5zZm9ybWF0aW9uIHRoYXQgaGFzDQogICAgICAgYmVlbiBvciBjYW4g YmUgYXBwbGllZCB0byBhIHJlcHJlc2VudGF0aW9uLiAgQ29udGVudCBjb2RpbmdzIGFyZQ0KDQog ICAgQnV0IOKAnGNhbiBiZSIgaGVyZSBwcm9iYWJseSBpcyBtb3JlIGFib3V0IEFjY2VwdC1FbmNv ZGluZywgZm9yIHdoaWNoIHdlIGRvbuKAmXQgaGF2ZSBhbiBlcXVpdmFsZW50IGluIFNlbk1MLCBz byB3ZSBjYW4gbGVhdmUgdGhpcyBhc3BlY3Qgb3V0Lg0KDQogICAgPiBNYXliZSBzb21ldGhpbmcg bGlrZSB0aGlzIGlzIHN1ZmZpY2llbnQ/DQogICAgPiANCiAgICA+IENvbnRlbnQtQ29kaW5nOiBh IG5hbWUgcmVnaXN0ZXJlZCBpbiBbSUFOQS5jb250ZW50LWNvZGluZ10gYXMgc3BlY2lmaWVkIGJ5 DQogICAgPiBbUkZDNzIzMF0uICBDb25mdXNpbmdseSwgaW4gSFRUUCB0aGUgQ29udGVudC1Db2Rp bmcgaXMgZm91bmQgaW4gYSBmaWVsZCBjYWxsZWQNCiAgICA+ICJDb250ZW50LUVuY29kaW5nIiwg aG93ZXZlciAiQ29udGVudC1Db2RpbmciIGlzIHRoZSBjb3JyZWN0IHRlcm0uDQoNCiAgICBDb21i aW5pbmcgc29tZSBiZXR0ZXIgdXNlIG9mIHJlZmVyZW5jZXMgKHNlZSB5b3VyIHBvaW50IGFib3Zl KSB3aXRoIHRoaXMgaW5wdXQsIEkgY2FtZSB1cCB3aXRoOg0KDQogICAgICAgQ29udGVudC1Db2Rp bmc6ICBBIG5hbWUgcmVnaXN0ZXJlZCBpbiB0aGUgSFRUUCBDb250ZW50IENvZGluZw0KICAgICAg ICAgIHJlZ2lzdHJ5IFtJQU5BLmh0dHAtcGFyYW1ldGVyc10gYXMgc3BlY2lmaWVkIGJ5IFNlY3Rp b24gOC41IG9mDQogICAgICAgICAgW1JGQzcyMzBdLCBpbmRpY2F0aW5nIGFuIGVuY29kaW5nIHRy YW5zZm9ybWF0aW9uIHdpdGggc2VtYW50aWNzDQogICAgICAgICAgZnVydGhlciBzcGVjaWZpZWQg aW4gU2VjdGlvbiAzLjEuMi4xIG9mIFtSRkM3MjMxXS4gIENvbmZ1c2luZ2x5LA0KICAgICAgICAg IGluIEhUVFAgdGhlIENvbnRlbnQtQ29kaW5nIGlzIGZvdW5kIGluIGEgaGVhZGVyIGZpZWxkIGNh bGxlZA0KICAgICAgICAgICJDb250ZW50LUVuY29kaW5nIiwgaG93ZXZlciAiQ29udGVudC1Db2Rp bmciIGlzIHRoZSBjb3JyZWN0IHRlcm0uDQoNCiAgICAoTGlua3MgaW4gdGhlIEhUTUwgdmVyc2lv biBvbiBldmVyeSBzZWN0aW9uIG9yIHJlZ2lzdHJ5IHJlZmVyZW5jZSwgd2hpY2ggYXJlIG5vdCB2 aXNpYmxlIGluIHRoaXMgcGxhaW50ZXh0IGNvcHktcGFzdGUuKQ0KDQogICAgTm93IGluIGh0dHBz Oi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9YjYzYWUyMzQtZTlhMWRiMzItYjYzYWEy YWYtODZlZTg2YmQ1MTA3LTMyNDhiMTEyODk3YmVhZjEmcT0xJmU9MzhlNjQ2MjMtNTJkZC00ODkw LWJlMDItMjMyNThiNmQ1NjZkJnU9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGY29yZS13ZyUy RnNlbm1sLWRhdGEtY3QlMkZjb21taXQlMkY5MGEzZGViDQoNCiAgICA+IFRoZSBvdGhlciBjb25m dXNpbmcgc2VjdGlvbiB3YXMgdGhpcyBpbiBzZWN0aW9uIDM6DQogICAgPiANCiAgICA+ICBJZiBu byAiQCIgc2lnbiBpcyBwcmVzZW50IG91dHNpZGUgdGhlIG1lZGlhIHR5cGUgcGFyYW1ldGVycywg dGhlDQogICAgPiAgQ29udGVudC1Db2RpbmcgaXMgbm90IHNwZWNpZmllZCBhbmQgdGhlICJpZGVu dGl0eSIgQ29udGVudC1Db2RpbmcgaXMgdXNlZCAtLSANCiAgICA+ICBubyBlbmNvZGluZyB0cmFu c2Zvcm1hdGlvbiBpcyBlbXBsb3llZC4NCiAgICA+IA0KICAgID4gIklmIG5vIEAgc2lnbiBpcyBw cmVzZW50IG91dHNpZGUiIGlzIGEgcmVhbGx5IGNsdW5reSB0dXJuIG9mIHBocmFzZSB0aGF0IGxl ZnQNCiAgICA+IG1lIG1vcmUgY29uZnVzZWQgdGhhbiB0aGUgZXhhbXBsZXMhICBJIGFzc3VtZSB0 aGlzIGNvbnN0cnVjdGlvbiB3YXMgdXNlZA0KICAgID4gYmVjYXVzZSB0aGVvcmV0aWNhbGx5IGFu ICdAJyBzaWduIGNvdWxkIGJlIHByZXNlbnQgaW5zaWRlIHRoZSBtZWRpYS10eXBlLCBvcg0KICAg ID4gaW5zaWRlIGEgcGFyYW1ldGVyLCBpZiBjb3JyZWN0bHkgcXVvdGVkLiAgSSB3b3VsZCBzdWdn ZXN0IGF0IGxlYXN0IGNoYW5naW5nDQogICAgPiAicHJlc2VudCBvdXRzaWRlIiB0byBhZnRlciwg b3IgdHJhaWxpbmcsIG9yIHNvbWV0aGluZy4NCiAgICA+IA0KICAgID4gTWF5YmUgdGhpcz8NCiAg ICA+IA0KICAgID4gSWYgbm8gIkAiIHNpZ24gaXMgcHJlc2VudCBhZnRlciB0aGUgbWVkaWEtdHlw ZSBwYXJhbWV0ZXJzLCB0aGVuIG5vDQogICAgPiBDb250ZW50LUNvZGluZyBoYXMgYmVlbiBzcGVj aWZpZWQsIGFuZCB0aGUgImlkZW50aXR5IiBDb250ZW50LUNvZGluZyBpcyB1c2VkIC0tDQogICAg PiBubyBlbmNvZGluZyB0cmFuc2Zvcm1hdGlvbiBpcyBlbXBsb3llZC4NCg0KICAgIEkgcmVzdHJ1 Y3R1cmVkIHRoZSBwYXJhZ3JhcGggYWxvbmcgdGhlc2UgbGluZXM6DQoNCiAgICAgICBUbyBpbmRp Y2F0ZSB0aGF0IGEgQ29udGVudC1Db2RpbmcgaXMgdXNlZCB3aXRoIGEgQ29udGVudC1UeXBlLCB0 aGUNCiAgICAgICBDb250ZW50LUNvZGluZyB2YWx1ZSBpcyBhcHBlbmRlZCB0byB0aGUgQ29udGVu dC1UeXBlIHZhbHVlIChtZWRpYQ0KICAgICAgIHR5cGUgYW5kIHBhcmFtZXRlcnMsIGlmIGFueSks IHNlcGFyYXRlZCBieSBhICJAIiBzaWduLiAgRm9yIGV4YW1wbGUNCiAgICAgICAodXNpbmcgYSBD b250ZW50LUNvZGluZyB2YWx1ZSBvZiAiZGVmbGF0ZSIgYXMgZGVmaW5lZCBpbg0KICAgICAgIFNl Y3Rpb24gNC4yLjIgb2YgW1JGQzcyMzBdKToNCg0KICAgICAgIHRleHQvcGxhaW47IGNoYXJzZXQ9 dXRmLThAZGVmbGF0ZQ0KDQogICAgICAgSWYgbm8gIkAiIHNpZ24gaXMgcHJlc2VudCBhZnRlciB0 aGUgbWVkaWEgdHlwZSBhbmQgcGFyYW1ldGVycywgdGhlbg0KICAgICAgIG5vIENvbnRlbnQtQ29k aW5nIGhhcyBiZWVuIHNwZWNpZmllZCwgYW5kIHRoZSAiaWRlbnRpdHkiIENvbnRlbnQtDQogICAg ICAgQ29kaW5nIGlzIHVzZWQgLS0gbm8gZW5jb2RpbmcgdHJhbnNmb3JtYXRpb24gaXMgZW1wbG95 ZWQuDQoNCiAgICAoQWdhaW4sIGEgbGluayBpbiB0aGUgSFRNTCB2ZXJzaW9uIG9uIHRoZSBzZWN0 aW9uIHJlZmVyZW5jZS4pDQoNCiAgICBOb3cgaW4gaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNv bS92MS91cmw/az0yODMyMTAzNy03N2E5MjkzMS0yODMyNTBhYy04NmVlODZiZDUxMDctNzQ0MGY0 ZTkzMTQ2MDNmYSZxPTEmZT0zOGU2NDYyMy01MmRkLTQ4OTAtYmUwMi0yMzI1OGI2ZDU2NmQmdT1o dHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGc2VubWwtZGF0YS1jdCUyRnB1bGwl MkY0JTJGY29tbWl0cyUyRjRkOTk0YmINCg0KICAgID4gT3RoZXIgdGhhbiB0aG9zZSB0d28gc2xp Z2h0bHkgY29uZnVzaW5nIGJpdHMsIGdyZWF0IGRvY3VtZW50IC0gSSBlbmpveWVkDQogICAgPiBy ZWFkaW5nIGl0IGFuZCB0aGUgaW50ZW50aW9ucywgcHVycG9zZSBhbmQgdXNlIG9mIHRoaXMgZG9j dW1lbnQgYXJlIGNsZWFyLg0KDQogICAgVGhhbmsgeW91IQ0KDQogICAgR3LDvMOfZSwgQ2Fyc3Rl bg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBhcnQgbWFpbGluZyBsaXN0DQogICAgYXJ0QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcnQNCg0K From nobody Fri Sep 10 01:43:26 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16F3A08D9; Fri, 10 Sep 2021 01:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.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 W1zMD7GDRRjA; Fri, 10 Sep 2021 01:43:17 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20602.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::602]) (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 3C0DC3A08DB; Fri, 10 Sep 2021 01:43:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nZ5ly43ahfSRV9fiehMZHPAIkHyyh7jhof/iTHydAzupjzAN5Ly9qRo+OgqyOhMiw4pesPnnwa5kmFikKdPEOGX7POearyKG+8WSwsj1hV0jlcycc9bHC1PRkKlmOs0FOb+6UBxBdG90qZrzOLf1TkwHUvY/LOOke3HeSePVCVPJkNwUSj0G4iHMazNb6/IWiSqUPRwiwJfmNeqq8YwOx1p+u3eCuRs2GhQuW8N2ZLMBdhtdJ3lu75FNn3m5Lrc8KLNovHpE2wb6HzOXJu1WCeZSXz8mCa//VFlQAB9IOGbiS5aNPby5cv8wG32b/brPL81/Hwu1tsoYdY7AXBH1HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eNP+WTYA4cyB4aNcBTBXUc0mqd8lMkX/TFye+K4j4Ek=; b=UUjNw9B2pskF9u5UursHVtgyXNMI/h9eVCyIXt71YXBhFloWgPAIl7FFlAoyBmrN4L230r/fMB8lPXr3MI4d+e7hosb3brN5sn6HmfjycfJwhS9rF27YdiFu/SJ+yoCXvLW0H8Kq8DqGX1Ttt0PtrP2XSILPgdFORgcve3q077Fkzk2V0QpJDXC7maI7ziGr77Tv0tpVcxP+tf6GS0dfar8R3f7TFd6rDmq9PHOqsC8/cE3nNov9SrWlyBrcswGWhi2iGyeJJK8wJmQZJ9OiNTYycX0Txcf5jOEGlGr7yE028OOlMMFlIysxMTzcy4zoJ0iwYvIHmm5dc2OeaM1y5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eNP+WTYA4cyB4aNcBTBXUc0mqd8lMkX/TFye+K4j4Ek=; b=hJ+t1Ip6QlkaS7KG8eFPJ0cqlRGInyDUwxYMPr58IqNkHCilXRFGHuTFxA7r16TuMowGzhmEueoWZN1ieq/MFQL3Xy1BDlaP7dW7CcnCjcF/Rf107oecKzvt0xuYtzweLKvCFvzMtCWMkSEfzq2Kg9bSgvC9/yalmiIMhOUeEH0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uniovi.es; Received: from DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) by DBBPR08MB5994.eurprd08.prod.outlook.com (2603:10a6:10:20d::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.22; Fri, 10 Sep 2021 08:43:01 +0000 Received: from DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395]) by DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395%7]) with mapi id 15.20.4500.017; Fri, 10 Sep 2021 08:43:01 +0000 Cc: garciadan@uniovi.es, EMU WG , "ace@ietf.org" , Rafa Marin-Lopez , core@ietf.org To: =?UTF-8?Q?Christian_Ams=c3=bcss?= References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> From: Dan Garcia Carrillo Message-ID: Date: Fri, 10 Sep 2021 10:42:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7CFFD4FA37F207B354D8AA67" Content-Language: es-ES X-ClientProxiedBy: MR1P264CA0098.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::8) To DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [156.35.171.42] (156.35.171.42) by MR1P264CA0098.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 08:42:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8a117da7-b858-4fcf-1b9c-08d97436feeb X-MS-TrafficTypeDiagnostic: DBBPR08MB5994: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: l5sQOLkZvhgqMXt1dxfE1TzuxxSOJJ/Npj6FucUBX1wwk8Yf4G45nDZ8TylyBApB8svhjQto7y61y8pqUaMeYrm8Tw1DuhgQIXZouJ2sC6MB72/w2y6DLiKqXxEZ13xDyl2KypPvvG6s7WYjoI5aPHxhCiFmsobVsjCNxDJ1II496oCf7qvBSu8RjjK4zkFpbBCmthH/1KEAY1CtKk4xE/5+fMlimSGHVIp5SfbGDZEZmENrLpsVMhyvXvsK39B401kmwsH6jMSpx02Ci9h7e/gU2BJMu16/6FPXjZ4/odhTem/smN5Ma8I2eUMBqC0xAadMFx4zLckWkess9pkOcnxJ4z2HSM/49TY6ZHUek3twpYEbgNfZ8IEurk5D9aN1ilOXHB+JcQEkpTkigBnzQiWyU8HL9Ms21nHvtjZ+KKCKCkcZTk494xGRTv27O6QqnzEIn0gJZXrci2bpV9SWk7snVaTxD+G2wrLTv7K3dcCGYSeXp3Zn/xLabcAfyUABAWHuIqZltgDDU31GK5ECIxynP+n0LjQ27CkpSdonvck0DePY0w1K8u3ULoye4Hp1Bg0cntmBD64OdXjwcsrR1FilZXtet1qNOaKpSu4Rsnw10oEribBETQri/TuNa2Wv7sVA3dEJn1puevt4wGXiRVGm91sAhEAUpGHuA9EmtkLPJo74UZlw7qM9P+m5mEPKclJEYjZTSvvpdDO04s9miDUVJ4nYqQG4C+ysII+MCKbQynm3q0hJsbU5fT0atvQ4wf1lol3XWszYwaS/S+ChjRZ6k9CJURX9cCKtbOd2c0+2pLIYyDbqNoulq02BGXdEcCgfM3lFL/Y8kv2RLxoKQb97/OGgeFqhDzi+qb3pHMFNcRAq85czNFrlRg4S97IoCFSo+fmEd/ViKyHE1vatcA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB6202.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(346002)(366004)(376002)(66574015)(31696002)(83380400001)(52116002)(54906003)(166002)(66556008)(16576012)(36756003)(31686004)(316002)(8936002)(2616005)(66946007)(4326008)(2906002)(956004)(6706004)(38350700002)(66476007)(30864003)(26005)(966005)(6486002)(53546011)(86362001)(8676002)(186003)(33964004)(478600001)(5660300002)(6916009)(38100700002)(429304003)(3940600001)(45980500001)(43740500002)(559001)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?czg0YnFMVTk0VHEweFE5R0NxV3RQTlc5Mjg5VkxDRG5POHBvUmlYUnBqV3J0?= =?utf-8?B?VHNLdmVGY2ttV3VpL0diWEtqKzFrK0dFakZ0MnUzaXBBRzFsUjZ0WEl1MjVo?= =?utf-8?B?VHZGS2xCREliSy9ua0J1MzBNbUlHTzRTdjk4NzBhRm9ieGtFU1I5bVRLOUg5?= =?utf-8?B?MmlFM3BBQldGUnBib1gxcktKNlFoWmNlZ056dnNaandjNU9DQ1BUVXV6NWZL?= =?utf-8?B?bUxBcU14ZTJZQ3lpdVVEZEM1ZC9iR3RiditYYzdFNVVSSXFNLy9NQWZ6WDA2?= =?utf-8?B?YkVmOS9IemNNMVZDVjF4d0NVa3VUQTllVExnaVVmbmQ2RGpWdTlqVS9lUE8v?= =?utf-8?B?dzE0NENiS0ZxbWpoOHhYU0FpbndNaHR5NzJ1a29reGZzcVEzaEZHY1lnTjAr?= =?utf-8?B?TmxqSFlGSUFxYWlLeE9nUXNrb2NWc2ppd09hN3Q3L3gyMnBKaU52UU5acVNm?= =?utf-8?B?THRoSVV5M2k5WTRjM2J6WllsRVJBZGVWLytzVkZtSkt4UEViQzA0RlRaaFpG?= =?utf-8?B?V3V3OGlNdFdnZ050WTdhYjZEVWxpV3JxNTNzb3pxenJ6WlpMWVMwNFIxUjRF?= =?utf-8?B?ZUR4SU52V0UrSDFxaVVmYlFWV0JLTGJXdGpZdHoyL01Lc1Jpa2d5Mm9lTEZi?= =?utf-8?B?bFMwSW1Fd0xEK1V6QllKazZ3VzVqdVo1R3F1eVl0V0hRZ20vY1dCT1V6bEYv?= =?utf-8?B?WXlmTXNkczFDeXV4bC81ZjlEalYwV3lZR1g2dVViV2dsOXk1L05Ma2x3ekx5?= =?utf-8?B?ZlRQaGwzQVljS2pKM0xNajhSRXE1Vk9KSUZvWmY0VGs4UzlXY0x0dW4zSEkx?= =?utf-8?B?VjNLcDFLV3h4cXR6TCtPTG9IRHQ1NVFpeEtOMTJ5SGllcG85L1Z0Y1FTUGcv?= =?utf-8?B?WWJFblExTVBLYmllcEZvYkJGaTl4dG9CamZPeTNnSnF3bVFUcG1mWENhNzZr?= =?utf-8?B?RDVXdVpBT3A5MUFnSnhrWVhiQ3hkV2RQOEdabXF1MzU3V1lpRU01b1BvR1dI?= =?utf-8?B?cDNwV1h5N05ONVNNUE90L2tDWC8xWXFyQ3lHMUwzZXJBcnJqWUMxS09IRmhN?= =?utf-8?B?cXljTXhoNS9YdXFhS1BmUU1YQ2hWN3JWYTdFaXk0aHp3bzhaWXlJZVpwTGlt?= =?utf-8?B?Smp3MVo2SVk5NGtobnpxTzUydi9EZzVTMVp6QTU1OEMwMkxuUmsyQmJGKzE0?= =?utf-8?B?cnpIMUhPanpsUmtSWThTenZld0xrUjdULzdrQk9DNE1uUFVTaDM5d2huNmlJ?= =?utf-8?B?dERHbHM0UkZYSENoU1RkQTIwK0VSMUk2MEZRVDRJWHAxREZkbElBcVdnQWRy?= =?utf-8?B?OGJNUGVaay9aWGd5TmNVZERYL05kaWRQYjg3NWxKcm1MVVEyU29TemVRRXdo?= =?utf-8?B?dW1EMkpjSFdmeEdJc3F5VWFoQUpJL2tVbWZNV3AyZlBya2VIYm5GYy9UR1dm?= =?utf-8?B?KzVOR1BORFRNRU5NTlJVME8xdVJmemxRcUVlcEdSNUFzVi8yeEluR2Z4Yy80?= =?utf-8?B?YlRPWTFMU3MzWmoyRktQL052MVZpVlpENWpJM0JUOG9FV2FmK1dwWUNnZ0Zl?= =?utf-8?B?cS9mY1RMN29mdUtHL1RoMnZDTSs2QzgyaWZoTW5IeHZsQTdVcytMSGVJQUxh?= =?utf-8?B?cTNtR2pWWEpSaHZsS3JaYXM3c2o1NUlwTGNNSlkvaDFSbmkxUnhoY3VYeTA0?= =?utf-8?B?MEplYmJ3eVRQVnRUQS93a3dKemNyYnFqOVhub3plMS83bjRGNUhhTW42WGtW?= =?utf-8?Q?Kuhf8znaSX6+b97sxKF9E0M+ejzb97r6nqSKZ6r?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-Network-Message-Id: 8a117da7-b858-4fcf-1b9c-08d97436feeb X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2021 08:43:01.3568 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Rev8OPvQdgUiceDoUx0CoduX9GRhWOE4x9rIHifRMRGRRzKPBaE57YggE1jsXhSJT9YbKXMr72agGkbV3zNFOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5994 X-MS-Exchange-CrossPremises-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 156.35.171.42 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DBBPR08MB5994.eurprd08.prod.outlook.com Archived-At: Subject: Re: [core] [Ace] CoAP-EAP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 08:43:24 -0000 --------------7CFFD4FA37F207B354D8AA67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Christian, Thank you very much for your detailed revision, Please see inline our comments. > On 16/8/21 16:40, Christian Amsüss wrote: >> Hello CoAP-EAP authors and involved groups, >> (CC'ing core@ as this is a review on CoAP usage), >> >> >> I've read the -03 draft and accumulated a few comments; largely in >> sequence of occurrence. >> >> Over all, the protocol has improved a lot since I've last had my eyes on >> it. Several comments below are about how prescriptive the message types >> are. I believe that this should be resolved towards generality, or else >> the usability of this protocol with generic CoAP components will be >> limited (or, worse, still implemented and then surprisingly >> incompatible). >> >> >> * Figure 1: For readers new to the topic of EAP, I think that it might >>    be useful to extend this to cover also the EAP server or AAA >>    infrastructure, if that can be covered without too much complication. >> >>    Suggestion (without illusions of correctness): >> >>             IoT device            Controller >>           +------------+        +------------+ >>           | EAP peer/  |        | EAP auth./ |+-----+[ AAA infra. ] >>           | CoAP server|+------+| CoAP client|+-----+[ EAP server?] >>           +------------+  CoAP  +------------+  EAP? >>                    \_____ Scope of this document _____/ >> >>                        Figure 1: CoAP-EAP Architecture >> [Authors] This is a good point. We did not include it at first, as having a AAA infrastructure is not mandatory. But the optionality can also be expressed in the figure. We will consider using this for the next version. Please also be aware that this architecture including AAA is assuming something called EAP authenticator in pass-through mode. Nevertheless, an EAP authenticator in standalone mode is also possible, where no AAA exists. >> * `/.well-known/a`: [note: May be irrelevant, see next two items] >> >>    If the designated experts don't go along with a >>    very-short option (I'd kind of doubt you'd get anything shorter than >>    `/.well-known/eap`) and if that puts you up against practical limits, >>    using a short-hand option might be viable. >> >>    So far there's no document for it and I've only pitched the idea >>    briefly at an interim[1] (slides at [2]), but if push comes to shove >>    and you need the compactness, let me know and that work can be >>    expedited. >> >>    [1]: >> https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core >>    [2]: >> https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 [Authors] You are correct. This was addressed by the well-known URI experts and they have proposed to use /.well-known/coap-eap >> >> * Discovering the Controller is described rather generically, but with >>    CoAP discovery as an example. >> >>    As long as CoAP discovery (as per RFC6690/7252) is used, that already >>    produces a URI, which can contain any path the server picked. It has >>    thus no need for a well-known path. >> >>    Are there other discovery options envisioned that'd only result in a >>    network address? Only for these, a well-known path would make sense. >>    (And then it's up to the envisioned client complexity if one is >>    warranted). >> [Authors] This is related to the next point. As long as the IoT device sends the resource for the authentication in this case we would remove the need for the well-known in the IoT device. >>    For comparison, RD[3] explores some of the options. A path may be >>    discovered using CoAP discovery as `?rt=core.rd*` right away from >>    multicast. Or an address may be discovered using an IPv6 RA option, >>    with CoAP discovery acting on that address. Only for cases of very >>    simple endpoints, it also defines a `/.well-known/rd` name that >> can be >>    used without CoAP discovery (and thus link parsing) happening >>    beforehand. The same rationales may apply for EAP (the devices using >>    the resource are mostly servers, otherwise, and send a very simple >>    request to start things), but again that's only if the address was >>    discovered through something that's not CoAP discovery already. >> >>    [3]: >> https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte >> [Authors] This is a good point. We may need to add a discussion of how the service can be discovered since, as you commented, there are different ways to do so. Our initial idea was to contact directly with the Border Router, which is consistent with what you comment about receiving the IPv6 RA to receive the IPv6 Address. Hence the communication would be directly using the /.well-known URI and the discovered IPv6 address. >> * For message 1, why does this need to go to a fixed resource? There has >>    been previous communication in message 0 in which the resource could >>    have been transported. >> >>    Granted, it's not as easy as in messages 2-to-3 etc where the >>    Location-* options are around, but the original message 0 POST could >>    just as well contain the path in the payload. >> >>    There are options as to how to do that precisely (just the URI >>    reference in text form, or a RFC6690 link, or a CBOR list of path >>    segments, or a CRI reference[4] -- if the latter were in WGLC already >>    I'd recommend it wholeheartedly), but either of them would stay more >>    true to the style of the other messages in that the earlier message >>    informs the path choice of the next ones. >> >>    An upside of this would be that it allows better behavior in presence >>    of proxies (see later), even though it may be practical to not spec >>    that out in full here. (But the path would be open for further specs, >>    and they'd just need some setting down of paving stones). >> >>    [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ [Authors] This is an interesting proposal. This is a good alternative to having to use the well-known URI in both entities, leaving it only for the first message from the IoT device to the Controller, which makes sense. >> >> * (Bycatch of suggesting URIs): It may be worth mentioning that the >>    NON's source address can easily be spoofed. Thus, any device on the >>    network can trigger what the authenticator may think of as a >>    device-triggered reauthentication, and the device may think of as an >>    authenticator-triggered reauthentication (provided it works that way, >>    see below when reauthentication is mentioned again). >> [Authors] But this case would not be possible since we mention that (re) authentication is initiated by the device. Thus, when the device sees an authenticator triggered re-authentication will discard that. >>    Even sending full URIs in message 0 would be no worse than the >> current >>    source spoofing. >> >>    Sending URI paths in message 0 would make this minimally better >>    because the attacker would need to guess (or observe from the >> network) >>    the CoAP server's path. [Authors] Correct. >> >> * In 3.1 General flow, the message types are described in high detail. >>    CoAP can generally be used with different transports (some of which >>    don't even do NON/CON). Also, while I think it's reasonable to expect >>    that a CoAP implementation can deal with requests coming in as either >>    CON or NON, I'd expect that some don't offer all possible choices to >>    applications. (A very constrained device may only send NON requests, >>    or an implementation may decide autonomously whether to send >>    piggy-backed or not). >> [Authors] Regarding this, it is worth noting that, except for message 0, the constrained device (CoAP server) is not sending requests but responses. Therefore, it will receive CON requests sent by the non-so-constrained CoAP client (EAP authenticator) Regarding piggybacking, it would be a requirement for this specification, with the goal of saving messages. >>    Can you clarify as to what of this is meant to be normative and what >>    exemplary? >> >>    My recommendation is to state that what is prescribed is the flow of >>    requests and responses (which is what CoAP provides to the next >>    layer), while notes on reliable transmission are recommendations for >>    CoAP-over-UDP/DTLS. A similar statement, which I like a lot, is >>    already in 3.2 on error handling. [Authors] This may be tricky as per the operation of CoAP-EAP. See comments below. >> >>    (I can serve examples of how subtle incompatibilities can develop but >>    go unnoticed, but I'd only go through that if this is all really >>    intended to be prescriptive). >> [Authors] In principle, they are intended to be prescriptive. Therefore, it would be really appreciated if you list the incompatibilities you have in mind. Having said this, relaxing the piggybacked responses in the specification is something that we understand that should not be a problem, except the “undesirable” increment of messages over a constrained link. About the usage of NON or CON, the situation is the following. First of all, as mentioned, the CON request is done by the Controller, which is assumed to be a not-so-constrained device. So we do not foresee a problem there. In any case, we have spent several cycles trying to think how everything would work in the case of using NON, assuming the HATEOAS approach. As Mohit Sethi also commented, “EAP  provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees” (from RFC 3748). Therefore, there was a chance to use NON requests and responses with the help of EAP. To achieve  “ordering guarantees” we have the HATEOAS approach, but in the case of using NON request and responses, as we see it,  the CoAP server would need to handle two resources at the same time. This is the reason. If , for example, message 4 (below) is lost (where the new resource is informed), the CoAP client will not know that the following NON request in the sequence should go to resource /a/y . The only resources still known by CoAP client is /a/x. That means that resource /a/x MUST not be removed yet from the CoAP server. So the CoAP server keeps two resources: current step /a/x and next expected step in /a/y.  If a message from the CoAP client arrives to /a/x it MUST be considered a retransmission from the EAP authenticator state machine because the CoAP client did not receive the new resource /a/y. This EAP retransmission is handled by the EAP peer state machine, though at the application level we could silently discard the payload. However if the NON request arrives to /a/y in message 5, it means that the CoAP client received message 4. In such a case, /a/x is removed , /a/y is the current step and, for example, /a/z becomes the next expected resource. NON [0x8694] POST /a/x |               |                            Token (0xac) |               |                     Payload EAP-X-Req 1 |            3) |<----------------------------------------|               | NON [0x4754]                            |               | Token (0xac)                            |               | 2.01 Created Location-Path [/a/y]       |               | Payload EAP-X-Resp 1                    |            4) |---------------------------------------->| Moreover, each retransmitted EAP request will go to a newNON request to /a/x (with different token values). It may happen that both arrive to the CoAP server that answers with two different NON responses saying that the next resource is /a/y. If one of the NON responses indicating /a/y arrives very much later when the interaction moved forward and it is in resource, let’s say, /a/z, when CoAP client sees /a/y will think that next rsource is let’s say /a/y instead /a/z. That, the CoAP client will process the “old” NON response that said /a/y , when that resource is not available. Therefore the CoAP client would need to keep track, at the application level, of the resources already seen. Otherwise, the CoAP client might get confused. Therefore we are carrying the complexity to the application when this is something it could be solved with CON requests at CoAP level. Finally, another problem we see is that EAP success is not retransmitted, so we believe that, at least, would require a CON request. Therefore, when NON request and responses are used, we need to specify this kind of behaviour in the CoAP server. And that behaviour changes if we are using CON requests because keeping two resources is not necessary.  Is this reasonable?. >> * The reuse of the empty token only works if the peers actually respond >>    with piggy-backed responses, so that's where enforcing the above >> rules >>    would give some benefit -- but at the cost of losing existing CoAP >>    implementations that make no guarantees as to how the response >> will be >>    sent as long as it's reliable. >> [Authors] The use of the Token empty in this case is just proposed as an optimization to be used when possible. This is not intended to be prescriptive. And using NON request and responses we believe should not have an empty value. >> * Proxying: As it is right now, this protocol just barely works across >>    proxies, and only if they support CoAP-EAP explicitly. (And while it >>    may sound odd to even consider that, bear in mind that they are used >>    in a very similar way in RFC9031). >> >>    While it's a bit open whether all CoAP-based protocols should >>    reasonably be expected to work across proxies or not, a remark (maybe >>    before 3.1?) that "If CoAP proxies are used between EAP peer and EAP >>    authenticator, they must be configured with knowledge of this >>    specification, or the operations will fail after step 0." [Authors] Based on your comment, it seems there is no guarantee that any CoAP-based protocol would work across proxies. Our question is whether there is any adaptation or change that would favour working through proxies. At the research level, we worked with proxy and you are right, our assumption is that proxies support CoAP-EAP explicitly (https://ieeexplore.ieee.org/document/8467302 ).  Since we are trying to avoid right now anything tailored to CoAP-EAP and only using CoAP as a means of transport for the exchange, why do you think this would not work with proxies? >> >> * 3.2.2: The use of RST is rather unusual here, for the same reasons as >>    the prescriptive message types. >> >>    A response of 5.03 (Service Unavailable) has roughly the same size, >>    is available independent of transport, and on most libraries *way* >>    easier to use, if they support sending an RST to a well-formed >> message >>    at all. >> >>    (Furthermore, the sender of the 5.03 can encode an estimate of the >>    remaining unavailable time in the Max-Age option; not sure if that is >>    of any help here). >> >> * 3.3.1: "received with the ACK", "sends piggybacked response" are, >>    again, overly specific. "received in the last response" and "sends a >>    response" could work as replacements even if message types are >>    presecriptive. [Authors] We used RST as the examples of the CoAP RFC seemed to convey that meaning when the endpoint is not in a position to respond to the request, but this seems to be an easier way to achieve the same goal. And as you say, if this is easier on implementations we should strive for that. >> >> * 3.3.1: "after the maximum retransmission attempts, the CoAP client >>    will remove the state from its side". >> >>    So the device that's being kicked from the network can delay its own >>    eviction for about a minute as long as it doesn't answer? >> [Authors] This is an interesting use case. To avoid this, we may have to change the behaviour, to a NON-message and just remove the state. >> * 3.3.2: Is reauthentication always triggered by the EAP peer, or can it >>    also be triggered by the authenticator? If the latter, will the >>    authenticator use /.well-known/a again, or POST something to the >>    resource from where it'd DELETE in 3.3.1? [Authors] The answer is yes, EAP peer always triggered the re-authentication, as it is the one interested in maintaining its membership within the domain, or even it could be dormant at some points. A use case for these is LoRaWAN nodes, that have the capability of starting the communication regardless of their class, whereas the Network server may not send a message until it has received something from the IoT device. >> >> * cryptosuites: What's the upgrade model of that hardcoded list? As it >>    is now, it looks pretty static, so updates would be through >> updates of >>    this document. The obvious alternative is an IANA registry with >>    ranges, policies and the usual pros and cons. >> >>    Then again, this is not the first nor last time AEAD algorithms with >>    their parametrization and hash functions are assigned aggregate >>    numbers (I-D.ietf-lake-edhoc comes to mind which has asymmetric algs >>    in the mix too; probably others as well); can we deduplicate this >> with >>    anything? (Possibly by bringing this up with COSE or OSCORE people). >> [Authors] In the next version we will propose a structure to add different parameters to the CoAP-EAP exchange. Within these parameters, we considered the extensibility of the crypto suite algorithms. >> * OSCORE derivation: Is it cryptographically necessary to derive *both* >>    a master secret and a master salt through KDF? (Sounds like a >>    needless step to me, as both only go into KDF once more when the >>    actual OSCORE parameters are derived). I *guess* there's a good >> reason >>    why the MSK is not used as the OSCORE IKM right away and the CSO as >>    OSCORE master salt, but it'd help to have at list a comment here on >>    why that's needed. >> >>    (It may be useful to compare this step to the HKDF steps in OSCORE; >>    their info element is always a 5-element array with a 4th "type" >>    element of "Key" or "IV"; other extractions might just hook in there >>    with different type values, maybe, and save everyone an extra >> handling >>    step). >> [Authors] You are right, there should be a clarification on why this is done the way it is. The main purpose is to use MSK  as the root key for key derivation. It is common practice with the usage of the MSK. If say key were compromised, another one could be derived from the MSK, without having to resort to a new bootstrapping to refresh the MSK. >> * OSCORE ID derivation: >> >>    * Randomly assigned full-length ideas look like an odd choice. They >>      are excessively long (nonce length - 6 is 7 for the MTI >>      AES-CCM-16-64-128 and shorter for other current ones, but I doubt >>      that keeping the IV *short* is necessarily a design criterion for >>      future algorithms). >> >>      What commonly happens here (eg. in the ACE-OSCORE profile, or in >>      EDHOC) is that each party picks a recipient ID out of its pool of >>      currently unused IDs. This makes for shorter keys, and allows the >>      client to be sure that no two peers use the same context. >> >>      Any chance something like that can still make it in? >> [Authors] Did not see that as random but parametrised according to the crypto suite. We will try to make this as straightforward as possible following your comments. >>    * If the parties happen to be assigned the same sender ID, bad things >>      happen (identical key derivation, nonce reuse, nuclear meltdown). >> >>      If the current pattern of KDF'ing IDs stands, this needs to be >>      prevented explicitly. [Authors] Since the Sender and recipient IDs, are derived from the MSK, which is assumed to be fresh key material, I think this should not be a problem. >> >>    * The derivations of "OSCORE RECIPIENT ID" and "OSCORE SENDER ID" are >>      confusing as they each need to happen on both sides, and the terms >>      will match on one and need to be opposite on the other. >> >>      (I couldn't even easily find which is intended to be which). >> >>      My suggestion is to derive "OSCORE EAP PEER SENDER ID" and "OSCORE >>      AUTHENTICATOR SENDER ID" instead. (Or preferably shorter strings). >> [Authors] Good point, thank you. We will address this according to your suggestion. >> * Exmaples: Do you envision particular EAP protocols to be used in the >>    given examples? [Authors] We consider the examples to use lightweight EAP methods. This could be EAP-PSK for instance. >> >> Best regards >> Christian --------------7CFFD4FA37F207B354D8AA67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQogIDwvaGVhZD4NCiAgPGJvZHk+DQogICAgPHAgZGly PSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0 b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC1jZmYxZmE4ZC03ZmZmLTQ5NjktZTdmMS04 MWZjMGMxY2QzMGYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdo dDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRp b246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3Bh Y2U6cHJlLXdyYXA7Ij5EZWFyIENocmlzdGlhbiwmbmJzcDs8L3NwYW4+PC9wPg0KICAgIDxicj4N CiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7 bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9u dC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1k ZWNvcmF0aW9uOm5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3do aXRlLXNwYWNlOnByZS13cmFwOyI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxl ZCByZXZpc2lvbiwmbmJzcDs8L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFj a2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGln bjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij5QbGVhc2Ug c2VlIGlubGluZSBvdXIgY29tbWVudHMuIA0KPC9zcGFuPjwvcD4NCiAgICA8cCBkaXI9Imx0ciIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj MDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQt c3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dmVy dGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNlOnByZS13cmFw OyI+DQo8L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4z ODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xv cjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3 aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQogICAg PGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpjOWNkYjIxNi01OWE3 LWIwNmEtN2NkMC05Mzg2ZTdiNmY5YWVAdW5pb3ZpLmVzIj5Pbg0KICAgICAgMTYvOC8yMSAxNjo0 MCwgQ2hyaXN0aWFuIEFtc8O8c3Mgd3JvdGU6DQogICAgICA8YnI+DQogICAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5IZWxsbyBDb0FQLUVBUCBhdXRob3JzIGFuZCBpbnZvbHZlZA0KICAgICAg ICBncm91cHMsDQogICAgICAgIDxicj4NCiAgICAgICAgKENDJ2luZyBjb3JlQCBhcyB0aGlzIGlz IGEgcmV2aWV3IG9uIENvQVAgdXNhZ2UpLA0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAg ICAgICAgPGJyPg0KICAgICAgICBJJ3ZlIHJlYWQgdGhlIC0wMyBkcmFmdCBhbmQgYWNjdW11bGF0 ZWQgYSBmZXcgY29tbWVudHM7IGxhcmdlbHkNCiAgICAgICAgaW4NCiAgICAgICAgPGJyPg0KICAg ICAgICBzZXF1ZW5jZSBvZiBvY2N1cnJlbmNlLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4N CiAgICAgICAgT3ZlciBhbGwsIHRoZSBwcm90b2NvbCBoYXMgaW1wcm92ZWQgYSBsb3Qgc2luY2Ug SSd2ZSBsYXN0IGhhZCBteQ0KICAgICAgICBleWVzIG9uDQogICAgICAgIDxicj4NCiAgICAgICAg aXQuIFNldmVyYWwgY29tbWVudHMgYmVsb3cgYXJlIGFib3V0IGhvdyBwcmVzY3JpcHRpdmUgdGhl DQogICAgICAgIG1lc3NhZ2UgdHlwZXMNCiAgICAgICAgPGJyPg0KICAgICAgICBhcmUuIEkgYmVs aWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlIHJlc29sdmVkIHRvd2FyZHMgZ2VuZXJhbGl0eSwNCiAg ICAgICAgb3IgZWxzZQ0KICAgICAgICA8YnI+DQogICAgICAgIHRoZSB1c2FiaWxpdHkgb2YgdGhp cyBwcm90b2NvbCB3aXRoIGdlbmVyaWMgQ29BUCBjb21wb25lbnRzIHdpbGwNCiAgICAgICAgYmUN CiAgICAgICAgPGJyPg0KICAgICAgICBsaW1pdGVkIChvciwgd29yc2UsIHN0aWxsIGltcGxlbWVu dGVkIGFuZCB0aGVuIHN1cnByaXNpbmdseQ0KICAgICAgICA8YnI+DQogICAgICAgIGluY29tcGF0 aWJsZSkuDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAg ICogRmlndXJlIDE6IEZvciByZWFkZXJzIG5ldyB0byB0aGUgdG9waWMgb2YgRUFQLCBJIHRoaW5r IHRoYXQgaXQNCiAgICAgICAgbWlnaHQNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJz cDsgYmUgdXNlZnVsIHRvIGV4dGVuZCB0aGlzIHRvIGNvdmVyIGFsc28gdGhlIEVBUCBzZXJ2ZXIg b3IgQUFBDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGluZnJhc3RydWN0dXJl LCBpZiB0aGF0IGNhbiBiZSBjb3ZlcmVkIHdpdGhvdXQgdG9vIG11Y2gNCiAgICAgICAgY29tcGxp Y2F0aW9uLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7 IFN1Z2dlc3Rpb24gKHdpdGhvdXQgaWxsdXNpb25zIG9mIGNvcnJlY3RuZXNzKToNCiAgICAgICAg PGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJb1QgZGV2aWNlJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENvbnRyb2xsZXINCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLSsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBFQVAgcGVlci8mbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IEVBUCBhdXRoLi8gfCstLS0tLStbIEFBQQ0KICAgICAgICBpbmZy YS4gXQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IENvQVAgc2VydmVyfCstLS0tLS0rfCBDb0FQIGNs aWVudHwrLS0tLS0rWyBFQVANCiAgICAgICAgc2VydmVyP10NCiAgICAgICAgPGJyPg0KICAgICAg ICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Ky0tLS0tLS0tLS0tLSsmbmJzcDsgQ29BUCZuYnNwOyArLS0tLS0tLS0tLS0tKyZuYnNwOyBFQVA/ DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBcX19fX18gU2NvcGUgb2YgdGhpcyBkb2N1bWVudCBfX19fXy8NCiAgICAg ICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUg MTogQ29BUC1FQVAgQXJjaGl0ZWN0dXJlDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAw KTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246 IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBpZD0iZG9jcy1pbnRlcm5hbC1ndWlk LTlmMDVjZDNhLTdmZmYtNDdkYy0zMGEwLWVlMWU4NWE0NDRkMCI+W0F1dGhvcnNdIFRoaXMgaXMg YSBnb29kIHBvaW50LiBXZSBkaWQgbm90IGluY2x1ZGUgaXQgYXQgZmlyc3QsIGFzIGhhdmluZyBh IEFBQSBpbmZyYXN0cnVjdHVyZSBpcyBub3QgbWFuZGF0b3J5LiBCdXQgdGhlIG9wdGlvbmFsaXR5 IGNhbiBhbHNvIGJlIGV4cHJlc3NlZCBpbiB0aGUgZmlndXJlLiBXZSB3aWxsIGNvbnNpZGVyIHVz aW5nIHRoaXMgZm9yIHRoZSBuZXh0IHZlcnNpb24uIFBsZWFzZSBhbHNvIGJlIGF3YXJlIHRoYXQg dGhpcyBhcmNoaXRlY3R1cmUgaW5jbHVkaW5nIEFBQSBpcyBhc3N1bWluZyBzb21ldGhpbmcgY2Fs bGVkIEVBUCBhdXRoZW50aWNhdG9yIGluIHBhc3MtdGhyb3VnaCBtb2RlLiBOZXZlcnRoZWxlc3Ms IGFuIEVBUCBhdXRoZW50aWNhdG9yIGluIHN0YW5kYWxvbmUgbW9kZSBpcyBhbHNvIHBvc3NpYmxl LCB3aGVyZSBubyBBQUEgZXhpc3RzLjwvc3Bhbj48L3A+DQogICAgPHA+PGJyPg0KICAgIDwvcD4N CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1iMDZh LTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4qIGAvLndlbGwta25vd24vYWA6IFtub3RlOiBNYXkgYmUNCiAgICAgICAgaXJyZWxldmFu dCwgc2VlIG5leHQgdHdvIGl0ZW1zXQ0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAg ICAgJm5ic3A7Jm5ic3A7IElmIHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgZG9uJ3QgZ28gYWxvbmcg d2l0aCBhDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHZlcnktc2hvcnQgb3B0 aW9uIChJJ2Qga2luZCBvZiBkb3VidCB5b3UnZCBnZXQgYW55dGhpbmcNCiAgICAgICAgc2hvcnRl ciB0aGFuDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGAvLndlbGwta25vd24v ZWFwYCkgYW5kIGlmIHRoYXQgcHV0cyB5b3UgdXAgYWdhaW5zdCBwcmFjdGljYWwNCiAgICAgICAg bGltaXRzLA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB1c2luZyBhIHNob3J0 LWhhbmQgb3B0aW9uIG1pZ2h0IGJlIHZpYWJsZS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+ DQogICAgICAgICZuYnNwOyZuYnNwOyBTbyBmYXIgdGhlcmUncyBubyBkb2N1bWVudCBmb3IgaXQg YW5kIEkndmUgb25seSBwaXRjaGVkIHRoZQ0KICAgICAgICBpZGVhDQogICAgICAgIDxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7IGJyaWVmbHkgYXQgYW4gaW50ZXJpbVsxXSAoc2xpZGVzIGF0IFsy XSksIGJ1dCBpZiBwdXNoIGNvbWVzDQogICAgICAgIHRvIHNob3ZlDQogICAgICAgIDxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7IGFuZCB5b3UgbmVlZCB0aGUgY29tcGFjdG5lc3MsIGxldCBtZSBr bm93IGFuZCB0aGF0IHdvcmsgY2FuDQogICAgICAgIGJlDQogICAgICAgIDxicj4NCiAgICAgICAg Jm5ic3A7Jm5ic3A7IGV4cGVkaXRlZC4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAg ICAgICZuYnNwOyZuYnNwOyBbMV06DQogICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl ZXRleHQiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmlt LTIwMjEtY29yZS0wNS9zZXNzaW9uL2NvcmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy9pbnRlcmltLTIwMjEtY29yZS0wNS9zZXNzaW9uL2NvcmU8L2E+DQogICAgICAgIDxi cj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IFsyXToNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl ZXRleHQiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmlt LTIwMjEtY29yZS0wNS9tYXRlcmlhbHMvc2xpZGVzLWludGVyaW0tMjAyMS1jb3JlLTA1LXNlc3Nh LWNvcmUtb3B0aW9uLWZvci13ZWxsLWtub3duLXJlc291cmNlcy0wMCI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMS1jb3JlLTA1L21hdGVyaWFscy9zbGlk ZXMtaW50ZXJpbS0yMDIxLWNvcmUtMDUtc2Vzc2EtY29yZS1vcHRpb24tZm9yLXdlbGwta25vd24t cmVzb3VyY2VzLTAwPC9hPjxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVv dGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6 MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC0wNDM1NjAyNy03 ZmZmLTY1MzEtZTIyMC1jYjJjZjE1N2NjNWIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNv bG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRl LXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBZb3UgYXJlIGNvcnJlY3QuIFRoaXMgd2FzIGFk ZHJlc3NlZCBieSB0aGUgd2VsbC1rbm93biBVUkkgZXhwZXJ0cyBhbmQgdGhleSBoYXZlIHByb3Bv c2VkIHRvIHVzZSAvLndlbGwta25vd24vY29hcC1lYXA8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4N CiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2 LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4NCiAgICAgICAgKiBEaXNjb3ZlcmluZyB0aGUg Q29udHJvbGxlciBpcyBkZXNjcmliZWQgcmF0aGVyIGdlbmVyaWNhbGx5LA0KICAgICAgICBidXQg d2l0aA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBDb0FQIGRpc2NvdmVyeSBh cyBhbiBleGFtcGxlLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7IEFzIGxvbmcgYXMgQ29BUCBkaXNjb3ZlcnkgKGFzIHBlciBSRkM2NjkwLzcyNTIpIGlz IHVzZWQsIHRoYXQNCiAgICAgICAgYWxyZWFkeQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNw OyZuYnNwOyBwcm9kdWNlcyBhIFVSSSwgd2hpY2ggY2FuIGNvbnRhaW4gYW55IHBhdGggdGhlIHNl cnZlciBwaWNrZWQuDQogICAgICAgIEl0IGhhcw0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNw OyZuYnNwOyB0aHVzIG5vIG5lZWQgZm9yIGEgd2VsbC1rbm93biBwYXRoLg0KICAgICAgICA8YnI+ DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IEFyZSB0aGVyZSBvdGhlciBkaXNj b3Zlcnkgb3B0aW9ucyBlbnZpc2lvbmVkIHRoYXQnZCBvbmx5DQogICAgICAgIHJlc3VsdCBpbiBh DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IG5ldHdvcmsgYWRkcmVzcz8gT25s eSBmb3IgdGhlc2UsIGEgd2VsbC1rbm93biBwYXRoIHdvdWxkIG1ha2UNCiAgICAgICAgc2Vuc2Uu DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IChBbmQgdGhlbiBpdCdzIHVwIHRv IHRoZSBlbnZpc2lvbmVkIGNsaWVudCBjb21wbGV4aXR5IGlmIG9uZQ0KICAgICAgICBpcw0KICAg ICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB3YXJyYW50ZWQpLg0KICAgICAgICA8YnI+ DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQog ICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4t dG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtYjUxMGE5 ODItN2ZmZi0zNjc4LTFiMjQtYWFkNmIyNmViYWZjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3 aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5bQXV0aG9yc10gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBu ZXh0IHBvaW50LiBBcyBsb25nIGFzIHRoZSBJb1QgZGV2aWNlIHNlbmRzIHRoZSByZXNvdXJjZSBm b3IgdGhlIGF1dGhlbnRpY2F0aW9uIGluIHRoaXMgY2FzZSB3ZSB3b3VsZCByZW1vdmUgdGhlIG5l ZWQgZm9yIHRoZSB3ZWxsLWtub3duIGluIHRoZSBJb1QgZGV2aWNlLiANCjwvc3Bhbj48L3A+DQog ICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21h cmdpbi1ib3R0b206MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5z cGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHBy ZS13cmFwOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdl aWdodDo3MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29y YXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUt c3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmku ZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Jm5ic3A7Jm5ic3A7IEZvciBjb21w YXJpc29uLCBSRFszXSBleHBsb3JlcyBzb21lIG9mDQogICAgICAgIHRoZSBvcHRpb25zLiBBIHBh dGggbWF5IGJlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGRpc2NvdmVyZWQg dXNpbmcgQ29BUCBkaXNjb3ZlcnkgYXMgYD9ydD1jb3JlLnJkKmAgcmlnaHQgYXdheQ0KICAgICAg ICBmcm9tDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IG11bHRpY2FzdC4gT3Ig YW4gYWRkcmVzcyBtYXkgYmUgZGlzY292ZXJlZCB1c2luZyBhbiBJUHY2IFJBDQogICAgICAgIG9w dGlvbiwNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgd2l0aCBDb0FQIGRpc2Nv dmVyeSBhY3Rpbmcgb24gdGhhdCBhZGRyZXNzLiBPbmx5IGZvciBjYXNlcyBvZg0KICAgICAgICB2 ZXJ5DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHNpbXBsZSBlbmRwb2ludHMs IGl0IGFsc28gZGVmaW5lcyBhIGAvLndlbGwta25vd24vcmRgIG5hbWUNCiAgICAgICAgdGhhdCBj YW4gYmUNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdXNlZCB3aXRob3V0IENv QVAgZGlzY292ZXJ5IChhbmQgdGh1cyBsaW5rIHBhcnNpbmcpIGhhcHBlbmluZw0KICAgICAgICA8 YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBiZWZvcmVoYW5kLiBUaGUgc2FtZSByYXRpb25hbGVz IG1heSBhcHBseSBmb3IgRUFQICh0aGUNCiAgICAgICAgZGV2aWNlcyB1c2luZw0KICAgICAgICA8 YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB0aGUgcmVzb3VyY2UgYXJlIG1vc3RseSBzZXJ2ZXJz LCBvdGhlcndpc2UsIGFuZCBzZW5kIGEgdmVyeQ0KICAgICAgICBzaW1wbGUNCiAgICAgICAgPGJy Pg0KICAgICAgICAmbmJzcDsmbmJzcDsgcmVxdWVzdCB0byBzdGFydCB0aGluZ3MpLCBidXQgYWdh aW4gdGhhdCdzIG9ubHkgaWYgdGhlDQogICAgICAgIGFkZHJlc3Mgd2FzDQogICAgICAgIDxicj4N CiAgICAgICAgJm5ic3A7Jm5ic3A7IGRpc2NvdmVyZWQgdGhyb3VnaCBzb21ldGhpbmcgdGhhdCdz IG5vdCBDb0FQIGRpc2NvdmVyeQ0KICAgICAgICBhbHJlYWR5Lg0KICAgICAgICA8YnI+DQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IFszXToNCjxhIGNsYXNzPSJtb3otdHh0LWxp bmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt aWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0yOC5odG1sI25hbWUtcmQtZGlzY292ZXJ5LWFu ZC1vdGhlci1pbnRlIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYt Y29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMjguaHRtbCNuYW1lLXJkLWRpc2NvdmVyeS1hbmQtb3Ro ZXItaW50ZTwvYT48YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8 L2Jsb2NrcXVvdGU+DQogICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRy YW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC05MGMzNjdlYy03ZmZmLTk4MTQtM2Yy YS1iNzAyOGY1NTY4ZGQiPltBdXRob3JzXSBUaGlzIGlzIGEgZ29vZCBwb2ludC4gV2UgbWF5IG5l ZWQgdG8gYWRkIGEgZGlzY3Vzc2lvbiBvZiBob3cgdGhlIHNlcnZpY2UgY2FuIGJlIGRpc2NvdmVy ZWQgc2luY2UsIGFzIHlvdSBjb21tZW50ZWQsIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyB0byBk byBzby4gT3VyIGluaXRpYWwgaWRlYSB3YXMgdG8gY29udGFjdCBkaXJlY3RseSB3aXRoIHRoZSBC b3JkZXIgUm91dGVyLCB3aGljaCBpcyBjb25zaXN0ZW50IHdpdGggd2hhdCB5b3UgY29tbWVudCBh Ym91dCByZWNlaXZpbmcgdGhlIElQdjYgUkEgdG8gcmVjZWl2ZSB0aGUgSVB2NiBBZGRyZXNzLiBI ZW5jZSB0aGUgY29tbXVuaWNhdGlvbiB3b3VsZCBiZSBkaXJlY3RseSB1c2luZyB0aGUgLy53ZWxs LWtub3duIFVSSSBhbmQgdGhlIGRpc2NvdmVyZWQgSVB2NiBhZGRyZXNzLiA8L3NwYW4+PC9wPg0K ICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0i bWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAg ICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiBGb3IgbWVzc2FnZSAxLCB3aHkgZG9lcyB0aGlz IG5lZWQgdG8gZ28NCiAgICAgICAgdG8gYSBmaXhlZCByZXNvdXJjZT8gVGhlcmUgaGFzDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGJlZW4gcHJldmlvdXMgY29tbXVuaWNhdGlv biBpbiBtZXNzYWdlIDAgaW4gd2hpY2ggdGhlDQogICAgICAgIHJlc291cmNlIGNvdWxkDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGhhdmUgYmVlbiB0cmFuc3BvcnRlZC4NCiAg ICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBHcmFudGVkLCBp dCdzIG5vdCBhcyBlYXN5IGFzIGluIG1lc3NhZ2VzIDItdG8tMyBldGMgd2hlcmUgdGhlDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IExvY2F0aW9uLSogb3B0aW9ucyBhcmUgYXJv dW5kLCBidXQgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgMA0KICAgICAgICBQT1NUIGNvdWxkDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGp1c3QgYXMgd2VsbCBjb250YWluIHRoZSBw YXRoIGluIHRoZSBwYXlsb2FkLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAg Jm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSBvcHRpb25zIGFzIHRvIGhvdyB0byBkbyB0aGF0IHByZWNp c2VseSAoanVzdCB0aGUNCiAgICAgICAgVVJJDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7IHJlZmVyZW5jZSBpbiB0ZXh0IGZvcm0sIG9yIGEgUkZDNjY5MCBsaW5rLCBvciBhIENC T1IgbGlzdCBvZg0KICAgICAgICBwYXRoDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7IHNlZ21lbnRzLCBvciBhIENSSSByZWZlcmVuY2VbNF0gLS0gaWYgdGhlIGxhdHRlciB3ZXJl IGluIFdHTEMNCiAgICAgICAgYWxyZWFkeQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZu YnNwOyBJJ2QgcmVjb21tZW5kIGl0IHdob2xlaGVhcnRlZGx5KSwgYnV0IGVpdGhlciBvZiB0aGVt IHdvdWxkDQogICAgICAgIHN0YXkgbW9yZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZu YnNwOyB0cnVlIHRvIHRoZSBzdHlsZSBvZiB0aGUgb3RoZXIgbWVzc2FnZXMgaW4gdGhhdCB0aGUg ZWFybGllcg0KICAgICAgICBtZXNzYWdlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7IGluZm9ybXMgdGhlIHBhdGggY2hvaWNlIG9mIHRoZSBuZXh0IG9uZXMuDQogICAgICAgIDxi cj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgQW4gdXBzaWRlIG9mIHRoaXMg d291bGQgYmUgdGhhdCBpdCBhbGxvd3MgYmV0dGVyIGJlaGF2aW9yIGluDQogICAgICAgIHByZXNl bmNlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IG9mIHByb3hpZXMgKHNlZSBs YXRlciksIGV2ZW4gdGhvdWdoIGl0IG1heSBiZSBwcmFjdGljYWwgdG8NCiAgICAgICAgbm90IHNw ZWMNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdGhhdCBvdXQgaW4gZnVsbCBo ZXJlLiAoQnV0IHRoZSBwYXRoIHdvdWxkIGJlIG9wZW4gZm9yDQogICAgICAgIGZ1cnRoZXIgc3Bl Y3MsDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGFuZCB0aGV5J2QganVzdCBu ZWVkIHNvbWUgc2V0dGluZyBkb3duIG9mIHBhdmluZyBzdG9uZXMpLg0KICAgICAgICA8YnI+DQog ICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IFs0XTogPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1jb3JlLWhyZWYvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWNvcmUtaHJlZi88L2E+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4N CiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29s b3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUt c3BhY2U6IHByZS13cmFwOyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC0yY2E0NmMwOS03ZmZmLWVi NzItZjFjNi1iZGY1MzA0ZTE5ZGYiPltBdXRob3JzXSBUaGlzIGlzIGFuIGludGVyZXN0aW5nIHBy b3Bvc2FsLiBUaGlzIGlzIGEgZ29vZCBhbHRlcm5hdGl2ZSB0byBoYXZpbmcgdG8gdXNlIHRoZSB3 ZWxsLWtub3duIFVSSSBpbiBib3RoIGVudGl0aWVzLCBsZWF2aW5nIGl0IG9ubHkgZm9yIHRoZSBm aXJzdCBtZXNzYWdlIGZyb20gdGhlIElvVCBkZXZpY2UgdG8gdGhlIENvbnRyb2xsZXIsIHdoaWNo IG1ha2VzIHNlbnNlLiA8L3NwYW4+PC9wPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNp dGU9Im1pZDpjOWNkYjIxNi01OWE3LWIwNmEtN2NkMC05Mzg2ZTdiNmY5YWVAdW5pb3ZpLmVzIj4N CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICA8YnI+DQogICAgICAgICog KEJ5Y2F0Y2ggb2Ygc3VnZ2VzdGluZyBVUklzKTogSXQgbWF5IGJlIHdvcnRoIG1lbnRpb25pbmcg dGhhdA0KICAgICAgICB0aGUNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgTk9O J3Mgc291cmNlIGFkZHJlc3MgY2FuIGVhc2lseSBiZSBzcG9vZmVkLiBUaHVzLCBhbnkgZGV2aWNl DQogICAgICAgIG9uIHRoZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBuZXR3 b3JrIGNhbiB0cmlnZ2VyIHdoYXQgdGhlIGF1dGhlbnRpY2F0b3IgbWF5IHRoaW5rIG9mIGFzIGEN CiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZGV2aWNlLXRyaWdnZXJlZCByZWF1 dGhlbnRpY2F0aW9uLCBhbmQgdGhlIGRldmljZSBtYXkgdGhpbmsNCiAgICAgICAgb2YgYXMgYW4N CiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYXV0aGVudGljYXRvci10cmlnZ2Vy ZWQgcmVhdXRoZW50aWNhdGlvbiAocHJvdmlkZWQgaXQgd29ya3MNCiAgICAgICAgdGhhdCB3YXks DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHNlZSBiZWxvdyB3aGVuIHJlYXV0 aGVudGljYXRpb24gaXMgbWVudGlvbmVkIGFnYWluKS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8 YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwIGRpcj0i bHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9t OjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtYzA4OGNhOGYtN2ZmZi0yODJjLWJlMDgtMzVk ZDliNTE5MzlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBB cmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7 Ij5bQXV0aG9yc10gQnV0IHRoaXMgY2FzZSB3b3VsZCBub3QgYmUgcG9zc2libGUgc2luY2Ugd2Ug bWVudGlvbiB0aGF0IChyZSkgYXV0aGVudGljYXRpb24gaXMgaW5pdGlhdGVkIGJ5IHRoZSBkZXZp Y2UuIFRodXMsIHdoZW4gdGhlIGRldmljZSBzZWVzIGFuIGF1dGhlbnRpY2F0b3IgdHJpZ2dlcmVk IHJlLWF1dGhlbnRpY2F0aW9uIHdpbGwgZGlzY2FyZCB0aGF0Ljwvc3Bhbj48L3A+DQogICAgPHA+ PGJyPg0KICAgIDwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Yzlj ZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4mbmJzcDsmbmJzcDsgRXZlbiBzZW5kaW5nIGZ1bGwgVVJJcyBp biBtZXNzYWdlIDANCiAgICAgICAgd291bGQgYmUgbm8gd29yc2UgdGhhbiB0aGUgY3VycmVudA0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBzb3VyY2Ugc3Bvb2ZpbmcuDQogICAg ICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgU2VuZGluZyBVUkkg cGF0aHMgaW4gbWVzc2FnZSAwIHdvdWxkIG1ha2UgdGhpcyBtaW5pbWFsbHkNCiAgICAgICAgYmV0 dGVyDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGJlY2F1c2UgdGhlIGF0dGFj a2VyIHdvdWxkIG5lZWQgdG8gZ3Vlc3MgKG9yIG9ic2VydmUgZnJvbSB0aGUNCiAgICAgICAgbmV0 d29yaykNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdGhlIENvQVAgc2VydmVy J3MgcGF0aC4NCiAgICAgICAgPGJyPg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgIDwvYmxvY2tx dW90ZT4NCiAgICA8YnI+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4 O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3Vp ZC0xNWZjYzdjZi03ZmZmLTg3OWMtNWQxYy0yMzUzZmFhZDEwYjMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBi YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBDb3JyZWN0Ljwvc3Bhbj48 L3A+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6 MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6 IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3Bh Y2U6IHByZS13cmFwOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtm b250LXdlaWdodDo3MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0 LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7 d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQogICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1 bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4N CiAgICAgICAgKiBJbiAzLjEgR2VuZXJhbCBmbG93LCB0aGUgbWVzc2FnZSB0eXBlcyBhcmUgZGVz Y3JpYmVkIGluIGhpZ2gNCiAgICAgICAgZGV0YWlsLg0KICAgICAgICA8YnI+DQogICAgICAgICZu YnNwOyZuYnNwOyBDb0FQIGNhbiBnZW5lcmFsbHkgYmUgdXNlZCB3aXRoIGRpZmZlcmVudCB0cmFu c3BvcnRzIChzb21lIG9mDQogICAgICAgIHdoaWNoDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IGRvbid0IGV2ZW4gZG8gTk9OL0NPTikuIEFsc28sIHdoaWxlIEkgdGhpbmsgaXQn cyByZWFzb25hYmxlDQogICAgICAgIHRvIGV4cGVjdA0KICAgICAgICA8YnI+DQogICAgICAgICZu YnNwOyZuYnNwOyB0aGF0IGEgQ29BUCBpbXBsZW1lbnRhdGlvbiBjYW4gZGVhbCB3aXRoIHJlcXVl c3RzIGNvbWluZyBpbg0KICAgICAgICBhcyBlaXRoZXINCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgQ09OIG9yIE5PTiwgSSdkIGV4cGVjdCB0aGF0IHNvbWUgZG9uJ3Qgb2ZmZXIg YWxsIHBvc3NpYmxlDQogICAgICAgIGNob2ljZXMgdG8NCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgYXBwbGljYXRpb25zLiAoQSB2ZXJ5IGNvbnN0cmFpbmVkIGRldmljZSBtYXkg b25seSBzZW5kIE5PTg0KICAgICAgICByZXF1ZXN0cywNCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgb3IgYW4gaW1wbGVtZW50YXRpb24gbWF5IGRlY2lkZSBhdXRvbm9tb3VzbHkg d2hldGhlciB0byBzZW5kDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHBpZ2d5 LWJhY2tlZCBvciBub3QpLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxv Y2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5l LWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFs aWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+DQo8L3NwYW4+PC9wPg0KICAg IDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJn aW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3Bh cmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUt d3JhcDsiPltBdXRob3JzXSBSZWdhcmRpbmcgdGhpcywgaXQgaXMgd29ydGggbm90aW5nIHRoYXQs IGV4Y2VwdCBmb3IgbWVzc2FnZSAwLCB0aGUgY29uc3RyYWluZWQgZGV2aWNlIChDb0FQIHNlcnZl cikgaXMgbm90IHNlbmRpbmcgcmVxdWVzdHMgYnV0IHJlc3BvbnNlcy4gVGhlcmVmb3JlLCBpdCB3 aWxsIHJlY2VpdmUgQ09OIHJlcXVlc3RzIHNlbnQgYnkgdGhlIG5vbi1zby1jb25zdHJhaW5lZCBD b0FQIGNsaWVudCAoRUFQIGF1dGhlbnRpY2F0b3IpPC9zcGFuPjwvcD4NCiAgICA8YnI+DQogICAg PHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdp bi1ib3R0b206MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+UmVnYXJkaW5nIHBpZ2d5YmFja2luZywgaXQgd291bGQgYmUgYSByZXF1aXJlbWVudCBm b3IgdGhpcyBzcGVjaWZpY2F0aW9uLCB3aXRoIHRoZSBnb2FsIG9mIHNhdmluZyBtZXNzYWdlcy48 L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPg0KPC9zcGFuPjwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVu aW92aS5lcyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4mbmJzcDsmbmJzcDsgQ2Fu IHlvdSBjbGFyaWZ5IGFzIHRvIHdoYXQgb2YgdGhpcyBpcw0KICAgICAgICBtZWFudCB0byBiZSBu b3JtYXRpdmUgYW5kIHdoYXQNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZXhl bXBsYXJ5Pw0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7 IE15IHJlY29tbWVuZGF0aW9uIGlzIHRvIHN0YXRlIHRoYXQgd2hhdCBpcyBwcmVzY3JpYmVkIGlz IHRoZQ0KICAgICAgICBmbG93IG9mDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7 IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgKHdoaWNoIGlzIHdoYXQgQ29BUCBwcm92aWRlcyB0byB0 aGUNCiAgICAgICAgbmV4dA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBsYXll ciksIHdoaWxlIG5vdGVzIG9uIHJlbGlhYmxlIHRyYW5zbWlzc2lvbiBhcmUNCiAgICAgICAgcmVj b21tZW5kYXRpb25zIGZvcg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBDb0FQ LW92ZXItVURQL0RUTFMuIEEgc2ltaWxhciBzdGF0ZW1lbnQsIHdoaWNoIEkgbGlrZSBhIGxvdCwN CiAgICAgICAgaXMNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYWxyZWFkeSBp biAzLjIgb24gZXJyb3IgaGFuZGxpbmcuDQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90 ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdo dDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJu YWwtZ3VpZC1lYWIzNmJmOC03ZmZmLTUyNTUtMmZjOS00OGRiMDQ5N2IwYzQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dy b3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij5bQXV0aG9yc10g VGhpcyBtYXkgYmUgdHJpY2t5IGFzIHBlciB0aGUgb3BlcmF0aW9uIG9mIENvQVAtRUFQLiBTZWUg Y29tbWVudHMgYmVsb3cuPC9zcGFuPjwvcD4NCiAgICA8cD48YnI+DQogICAgPC9wPg0KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpjOWNkYjIxNi01OWE3LWIwNmEtN2NkMC05 Mzg2ZTdiNmY5YWVAdW5pb3ZpLmVzIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyAoSSBjYW4gc2VydmUgZXhhbXBsZXMg b2YgaG93IHN1YnRsZSBpbmNvbXBhdGliaWxpdGllcyBjYW4NCiAgICAgICAgZGV2ZWxvcCBidXQN CiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZ28gdW5ub3RpY2VkLCBidXQgSSdk IG9ubHkgZ28gdGhyb3VnaCB0aGF0IGlmIHRoaXMgaXMgYWxsDQogICAgICAgIHJlYWxseQ0KICAg ICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBpbnRlbmRlZCB0byBiZSBwcmVzY3JpcHRp dmUpLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAg ICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4 O3RleHQtYWxpZ246DQogICAgICBqdXN0aWZ5O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206 MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+W0F1 dGhvcnNdIEluIHByaW5jaXBsZSwgdGhleSBhcmUgaW50ZW5kZWQgdG8gYmUgcHJlc2NyaXB0aXZl LiBUaGVyZWZvcmUsIGl0IHdvdWxkIGJlIHJlYWxseSBhcHByZWNpYXRlZCBpZiB5b3UgbGlzdCB0 aGUgaW5jb21wYXRpYmlsaXRpZXMgeW91IGhhdmUgaW4gbWluZC48L3NwYW4+PC9wPg0KICAgIDxi cj4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4dC1hbGlnbjoN CiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigw LCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwt YWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5IYXZpbmcgc2FpZCB0aGlz LCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+ cmVsYXhpbmcgdGhlIHBpZ2d5YmFja2VkIHJlc3BvbnNlcyBpbiB0aGUgc3BlY2lmaWNhdGlvbiBp cyBzb21ldGhpbmcgdGhhdCB3ZSB1bmRlcnN0YW5kIHRoYXQgc2hvdWxkIG5vdCBiZSBhIHByb2Js ZW0sIGV4Y2VwdCB0aGUg4oCcdW5kZXNpcmFibGXigJ0gaW5jcmVtZW50IG9mIG1lc3NhZ2VzIG92 ZXIgYSBjb25zdHJhaW5lZCBsaW5rLjwvc3Bhbj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0i bHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTtt YXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7 IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkFib3V0IHRoZSB1c2FnZSBvZiBOT04gb3IgQ09OLCB0 aGUgc2l0dWF0aW9uIGlzIHRoZSBmb2xsb3dpbmcuIEZpcnN0IG9mIGFsbCwgYXMgbWVudGlvbmVk LCB0aGUgQ09OIHJlcXVlc3QgaXMgZG9uZSBieSB0aGUgQ29udHJvbGxlciwgd2hpY2ggaXMgYXNz dW1lZCB0byBiZSBhIG5vdC1zby1jb25zdHJhaW5lZCBkZXZpY2UuIFNvIHdlIGRvIG5vdCBmb3Jl c2VlIGEgcHJvYmxlbSB0aGVyZS4gSW4gYW55IGNhc2UsIHdlIGhhdmUgc3BlbnQgc2V2ZXJhbCBj eWNsZXMgdHJ5aW5nIHRvIHRoaW5rIGhvdyBldmVyeXRoaW5nIHdvdWxkIHdvcmsgaW4gdGhlIGNh c2Ugb2YgdXNpbmcgTk9OLCBhc3N1bWluZyB0aGUgSEFURU9BUyBhcHByb2FjaC4mbmJzcDs8L3Nw YW4+PC9wPg0KICAgIDxicj4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEu Mzg7dGV4dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRv bTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5B cyBNb2hpdCBTZXRoaSBhbHNvIGNvbW1lbnRlZCwg4oCcRUFQJm5ic3A7IHByb3ZpZGVzIGl0cyBv d24gc3VwcG9ydCBmb3IgZHVwbGljYXRlIGVsaW1pbmF0aW9uIGFuZCByZXRyYW5zbWlzc2lvbiwg YnV0IGlzIHJlbGlhbnQgb24gbG93ZXIgbGF5ZXIgb3JkZXJpbmcgZ3VhcmFudGVlc+KAnSAoZnJv bSBSRkMgMzc0OCkuJm5ic3A7PC9zcGFuPjwvcD4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEuMzg7dGV4dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7 bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7Ij5UaGVyZWZvcmUsIHRoZXJlIHdhcyBhIGNoYW5jZSB0byB1c2UgTk9OIHJlcXVl c3RzIGFuZCByZXNwb25zZXMgd2l0aCB0aGUgaGVscCBvZiBFQVAuIFRvIGFjaGlldmUmbmJzcDsg 4oCcb3JkZXJpbmcgZ3VhcmFudGVlc+KAnSB3ZSBoYXZlIHRoZSBIQVRFT0FTIGFwcHJvYWNoLCBi dXQgaW4gdGhlIGNhc2Ugb2YgdXNpbmcgTk9OIHJlcXVlc3QgYW5kIHJlc3BvbnNlcywgYXMgd2Ug c2VlIGl0LCZuYnNwOyB0aGUgQ29BUCBzZXJ2ZXIgd291bGQgbmVlZCB0byBoYW5kbGUgdHdvIHJl c291cmNlcyBhdCB0aGUgc2FtZSB0aW1lLiBUaGlzIGlzIHRoZSByZWFzb24uIElmICwgZm9yIGV4 YW1wbGUsIG1lc3NhZ2UgNCAoYmVsb3cpIGlzIGxvc3QgKHdoZXJlIHRoZSBuZXcgcmVzb3VyY2Ug aXMgaW5mb3JtZWQpLCB0aGUgQ29BUCBjbGllbnQgd2lsbCBub3Qga25vdyB0aGF0IHRoZSBmb2xs b3dpbmcgTk9OIHJlcXVlc3QgaW4gdGhlIHNlcXVlbmNlIHNob3VsZCBnbyB0byByZXNvdXJjZSAv YS95IC4gVGhlIG9ubHkgcmVzb3VyY2VzIHN0aWxsIGtub3duIGJ5IENvQVAgY2xpZW50IGlzIC9h L3guIFRoYXQgbWVhbnMgdGhhdCByZXNvdXJjZSAvYS94IE1VU1Qgbm90IGJlIHJlbW92ZWQgeWV0 IGZyb20gdGhlIENvQVAgc2VydmVyLiBTbyB0aGUgQ29BUCBzZXJ2ZXIga2VlcHMgdHdvIHJlc291 cmNlczogY3VycmVudCBzdGVwIC9hL3ggYW5kIG5leHQgZXhwZWN0ZWQgc3RlcCBpbiAvYS95LiZu YnNwOyBJZiBhIG1lc3NhZ2UgZnJvbSB0aGUgQ29BUCBjbGllbnQgYXJyaXZlcyB0byAvYS94IGl0 IE1VU1QgYmUgY29uc2lkZXJlZCBhIHJldHJhbnNtaXNzaW9uIGZyb20gdGhlIEVBUCBhdXRoZW50 aWNhdG9yIHN0YXRlIG1hY2hpbmUgYmVjYXVzZSB0aGUgQ29BUCBjbGllbnQgZGlkIG5vdCByZWNl aXZlIHRoZSBuZXcgcmVzb3VyY2UgL2EveS4gVGhpcyBFQVAgcmV0cmFuc21pc3Npb24gaXMgaGFu ZGxlZCBieSB0aGUgRUFQIHBlZXIgc3RhdGUgbWFjaGluZSwgdGhvdWdoIGF0IHRoZSBhcHBsaWNh dGlvbiBsZXZlbCB3ZSBjb3VsZCBzaWxlbnRseSBkaXNjYXJkIHRoZSBwYXlsb2FkLiBIb3dldmVy IGlmIHRoZSBOT04gcmVxdWVzdCBhcnJpdmVzIHRvIC9hL3kgaW4gbWVzc2FnZSA1LCBpdCBtZWFu cyB0aGF0IHRoZSBDb0FQIGNsaWVudCByZWNlaXZlZCBtZXNzYWdlIDQuIEluIHN1Y2ggYSBjYXNl LCAvYS94IGlzIHJlbW92ZWQgLCAvYS95IGlzIHRoZSBjdXJyZW50IHN0ZXAgYW5kLCBmb3IgZXhh bXBsZSwgL2EveiBiZWNvbWVzIHRoZSBuZXh0IGV4cGVjdGVkIHJlc291cmNlLiZuYnNwOzwvc3Bh bj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4z ODt0ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9t OjBwdDsiPjxmb250IGZhY2U9IkNvdXJpZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3Bh Y2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTk9OIFsweDg2OTRdIFBPU1QgL2EveCB8PC9zcGFuPjwvZm9udD48L3A+DQogICAgPHAg ZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O3RleHQtYWxpZ246DQogICAgICBqdXN0 aWZ5O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PGZvbnQgZmFjZT0iQ291cmll cg0KICAgICAgICBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl bnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBUb2tlbiAoMHhhYykgfDwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgIDxw IGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVz dGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxmb250IGZhY2U9IkNvdXJp ZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGF5bG9hZCBF QVAtWC1SZXEgMSB8PC9zcGFuPjwvZm9udD48L3A+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJs aW5lLWhlaWdodDoxLjM4O3RleHQtYWxpZ246DQogICAgICBqdXN0aWZ5O21hcmdpbi10b3A6MHB0 O21hcmdpbi1ib3R0b206MHB0OyI+PGZvbnQgZmFjZT0iQ291cmllcg0KICAgICAgICBOZXcsIENv dXJpZXIsIG1vbm9zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGlj YWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDszKSB8 Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PC9zcGFuPjwvZm9u dD48L3A+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O3RleHQtYWxp Z246DQogICAgICBqdXN0aWZ5O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PGZv bnQgZmFjZT0iQ291cmllcg0KICAgICAgICBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1j b2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0 ZS1zcGFjZTogcHJlLXdyYXA7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IE5PTiBbMHg0 NzU0XSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48L2Zv bnQ+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFs aWduOg0KICAgICAganVzdGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxm b250IGZhY2U9IkNvdXJpZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQt Y29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hp dGUtc3BhY2U6IHByZS13cmFwOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBUb2tlbiAo MHhhYykmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PC9m b250PjwvcD4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4dC1h bGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48 Zm9udCBmYWNlPSJDb3VyaWVyDQogICAgICAgIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgMi4wMSBD cmVhdGVkIExvY2F0aW9uLVBhdGggWy9hL3ldICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+ PC9mb250PjwvcD4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4 dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7 Ij48Zm9udCBmYWNlPSJDb3VyaWVyDQogICAgICAgIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7 IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgUGF5 bG9hZCBFQVAtWC1SZXNwIDEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgIDxw IGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVz dGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxmb250IGZhY2U9IkNvdXJp ZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7NCkgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fDwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgIDxicj4NCiAgICA8cCBkaXI9Imx0ciIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRv cDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1z cGFjZTogcHJlLXdyYXA7Ij5Nb3Jlb3ZlciwgZWFjaCByZXRyYW5zbWl0dGVkIEVBUCByZXF1ZXN0 IHdpbGwgZ28gdG8gYSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRy YW5zcGFyZW50OyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyI+bmV3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiPiBOT04gcmVxdWVzdCB0byAvYS94ICh3aXRoIGRpZmZlcmVudCB0b2tlbiB2 YWx1ZXMpLiBJdCBtYXkgaGFwcGVuIHRoYXQgYm90aCBhcnJpdmUgdG8gdGhlIENvQVAgc2VydmVy IHRoYXQgYW5zd2VycyB3aXRoIHR3byBkaWZmZXJlbnQgTk9OIHJlc3BvbnNlcyBzYXlpbmcgdGhh dCB0aGUgbmV4dCByZXNvdXJjZSBpcyAvYS95LiBJZiBvbmUgb2YgdGhlIE5PTiByZXNwb25zZXMg aW5kaWNhdGluZyAvYS95IGFycml2ZXMgdmVyeSBtdWNoIGxhdGVyIHdoZW4gdGhlIGludGVyYWN0 aW9uIG1vdmVkIGZvcndhcmQgYW5kIGl0IGlzIGluIHJlc291cmNlLCBsZXTigJlzIHNheSwgL2Ev eiwgd2hlbiBDb0FQIGNsaWVudCBzZWVzIC9hL3kgd2lsbCB0aGluayB0aGF0IG5leHQgcnNvdXJj ZSBpcyBsZXTigJlzIHNheSAvYS95IGluc3RlYWQgL2Evei4gVGhhdCwgdGhlIENvQVAgY2xpZW50 IHdpbGwgcHJvY2VzcyB0aGUg4oCcb2xk4oCdIE5PTiByZXNwb25zZSB0aGF0IHNhaWQgL2EveSAs IHdoZW4gdGhhdCByZXNvdXJjZSBpcyBub3QgYXZhaWxhYmxlLiBUaGVyZWZvcmUgdGhlIENvQVAg Y2xpZW50IHdvdWxkIG5lZWQgdG8ga2VlcCB0cmFjaywgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVs LCBvZiB0aGUgcmVzb3VyY2VzIGFscmVhZHkgc2Vlbi4gT3RoZXJ3aXNlLCB0aGUgQ29BUCBjbGll bnQgbWlnaHQgZ2V0IGNvbmZ1c2VkLiBUaGVyZWZvcmUgd2UgYXJlIGNhcnJ5aW5nIHRoZSBjb21w bGV4aXR5IHRvIHRoZSBhcHBsaWNhdGlvbiB3aGVuIHRoaXMgaXMgc29tZXRoaW5nIGl0IGNvdWxk IGJlIHNvbHZlZCB3aXRoIENPTiByZXF1ZXN0cyBhdCBDb0FQIGxldmVsLiZuYnNwOzwvc3Bhbj48 L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0 ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBw dDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBj b2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkZpbmFs bHksIGFub3RoZXIgcHJvYmxlbSB3ZSBzZWUgaXMgdGhhdCBFQVAgc3VjY2VzcyBpcyBub3QgcmV0 cmFuc21pdHRlZCwgc28gd2UgYmVsaWV2ZSB0aGF0LCBhdCBsZWFzdCwgd291bGQgcmVxdWlyZSBh IENPTiByZXF1ZXN0LiZuYnNwOzwvc3Bhbj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRy IiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPlRoZXJlZm9yZSwgd2hlbiBOT04gcmVxdWVzdCBhbmQgcmVz cG9uc2VzIGFyZSB1c2VkLCB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhpcyBraW5kIG9mIGJlaGF2aW91 ciBpbiB0aGUgQ29BUCBzZXJ2ZXIuIEFuZCB0aGF0IGJlaGF2aW91ciBjaGFuZ2VzIGlmIHdlIGFy ZSB1c2luZyBDT04gcmVxdWVzdHMgYmVjYXVzZSBrZWVwaW5nIHR3byByZXNvdXJjZXMgaXMgbm90 IG5lY2Vzc2FyeS4mbmJzcDsgSXMgdGhpcyByZWFzb25hYmxlPy48L3NwYW4+PC9wPg0KICAgIDxi cj4NCiAgICA8YnI+DQogICAgPGJyPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZl N2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiBUaGUg cmV1c2Ugb2YgdGhlIGVtcHR5IHRva2VuIG9ubHkgd29ya3MNCiAgICAgICAgaWYgdGhlIHBlZXJz IGFjdHVhbGx5IHJlc3BvbmQNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgd2l0 aCBwaWdneS1iYWNrZWQgcmVzcG9uc2VzLCBzbyB0aGF0J3Mgd2hlcmUgZW5mb3JjaW5nIHRoZQ0K ICAgICAgICBhYm92ZSBydWxlcw0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB3 b3VsZCBnaXZlIHNvbWUgYmVuZWZpdCAtLSBidXQgYXQgdGhlIGNvc3Qgb2YgbG9zaW5nIGV4aXN0 aW5nDQogICAgICAgIENvQVANCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgaW1w bGVtZW50YXRpb25zIHRoYXQgbWFrZSBubyBndWFyYW50ZWVzIGFzIHRvIGhvdyB0aGUNCiAgICAg ICAgcmVzcG9uc2Ugd2lsbCBiZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBz ZW50IGFzIGxvbmcgYXMgaXQncyByZWxpYWJsZS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+ DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwPjxiciBpZD0i ZG9jcy1pbnRlcm5hbC1ndWlkLTkwZTJjYmM4LTdmZmYtMDRkZC03NjgwLWZmM2NhYjBhZDg5ZSI+ DQogICAgPC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBUaGUgdXNlIG9mIHRoZSBUb2tlbiBlbXB0 eSBpbiB0aGlzIGNhc2UgaXMganVzdCBwcm9wb3NlZCBhcyBhbiBvcHRpbWl6YXRpb24gdG8gYmUg dXNlZCB3aGVuIHBvc3NpYmxlLiBUaGlzIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBwcmVzY3JpcHRp dmUuIEFuZCB1c2luZyBOT04gcmVxdWVzdCBhbmQgcmVzcG9uc2VzIHdlIGJlbGlldmUgc2hvdWxk IG5vdCBoYXZlIGFuIGVtcHR5IHZhbHVlLjwvc3Bhbj48L3A+DQogICAgPHA+PGJyPg0KICAgIDwv cD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1i MDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4qIFByb3h5aW5nOiBBcyBpdCBpcyByaWdodCBub3csIHRoaXMNCiAgICAgICAgcHJv dG9jb2wganVzdCBiYXJlbHkgd29ya3MgYWNyb3NzDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IHByb3hpZXMsIGFuZCBvbmx5IGlmIHRoZXkgc3VwcG9ydCBDb0FQLUVBUCBleHBs aWNpdGx5LiAoQW5kDQogICAgICAgIHdoaWxlIGl0DQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IG1heSBzb3VuZCBvZGQgdG8gZXZlbiBjb25zaWRlciB0aGF0LCBiZWFyIGluIG1p bmQgdGhhdCB0aGV5DQogICAgICAgIGFyZSB1c2VkDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IGluIGEgdmVyeSBzaW1pbGFyIHdheSBpbiBSRkM5MDMxKS4NCiAgICAgICAgPGJy Pg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBXaGlsZSBpdCdzIGEgYml0IG9w ZW4gd2hldGhlciBhbGwgQ29BUC1iYXNlZCBwcm90b2NvbHMgc2hvdWxkDQogICAgICAgIDxicj4N CiAgICAgICAgJm5ic3A7Jm5ic3A7IHJlYXNvbmFibHkgYmUgZXhwZWN0ZWQgdG8gd29yayBhY3Jv c3MgcHJveGllcyBvciBub3QsIGENCiAgICAgICAgcmVtYXJrIChtYXliZQ0KICAgICAgICA8YnI+ DQogICAgICAgICZuYnNwOyZuYnNwOyBiZWZvcmUgMy4xPykgdGhhdCAmcXVvdDtJZiBDb0FQIHBy b3hpZXMgYXJlIHVzZWQgYmV0d2VlbiBFQVAgcGVlcg0KICAgICAgICBhbmQgRUFQDQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0b3IsIHRoZXkgbXVzdCBiZSBj b25maWd1cmVkIHdpdGgga25vd2xlZGdlIG9mIHRoaXMNCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiwgb3IgdGhlIG9wZXJhdGlvbnMgd2lsbCBmYWlsIGFm dGVyIHN0ZXAgMC4mcXVvdDsNCiAgICAgICAgPGJyPg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAg IDwvYmxvY2txdW90ZT4NCiAgICA8cD48YnIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC1kMDFmZTlj MS03ZmZmLTQ5MTAtNjJkNy03MjM4YTM2ZmI3NjkiPg0KICAgICAgPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+W0F1dGhvcnNdIEJhc2VkIG9uIHlvdXIgY29t bWVudCwgaXQgc2VlbXMgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgYW55IENvQVAtYmFzZWQg cHJvdG9jb2wgd291bGQgd29yayBhY3Jvc3MgcHJveGllcy4gT3VyIHF1ZXN0aW9uIGlzIHdoZXRo ZXIgdGhlcmUgaXMgYW55IGFkYXB0YXRpb24gb3IgY2hhbmdlIHRoYXQgd291bGQgZmF2b3VyIHdv cmtpbmcgdGhyb3VnaCBwcm94aWVzLiBBdCB0aGUgcmVzZWFyY2ggbGV2ZWwsIHdlIHdvcmtlZCB3 aXRoIHByb3h5IGFuZCB5b3UgYXJlIHJpZ2h0LCBvdXIgYXNzdW1wdGlvbiBpcyB0aGF0IHByb3hp ZXMgc3VwcG9ydCBDb0FQLUVBUCBleHBsaWNpdGx5ICg8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9p ZWVleHBsb3JlLmllZWUub3JnL2RvY3VtZW50Lzg0NjczMDIiIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246bm9uZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFy aWFsOyBjb2xvcjogcmdiKDE3LCA4NSwgMjA0KTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl bnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyB0ZXh0LWRlY29yYXRpb24tc2tpcC1pbms6IG5vbmU7IHZlcnRpY2Fs LWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+aHR0cHM6Ly9pZWVleHBs b3JlLmllZWUub3JnL2RvY3VtZW50Lzg0NjczMDI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBi YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPikuJm5ic3A7IFNpbmNlIHdlIGFyZSB0cnlp bmcgdG8gYXZvaWQgcmlnaHQgbm93IGFueXRoaW5nIHRhaWxvcmVkIHRvIENvQVAtRUFQIGFuZCBv bmx5IHVzaW5nIENvQVAgYXMgYSBtZWFucyBvZiB0cmFuc3BvcnQgZm9yIHRoZSBleGNoYW5nZSwg d2h5IGRvIHlvdSB0aGluayB0aGlzIHdvdWxkIG5vdCB3b3JrIHdpdGggcHJveGllcz88L3NwYW4+ PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMi Pg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4NCiAgICAgICAg KiAzLjIuMjogVGhlIHVzZSBvZiBSU1QgaXMgcmF0aGVyIHVudXN1YWwgaGVyZSwgZm9yIHRoZSBz YW1lDQogICAgICAgIHJlYXNvbnMgYXMNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJz cDsgdGhlIHByZXNjcmlwdGl2ZSBtZXNzYWdlIHR5cGVzLg0KICAgICAgICA8YnI+DQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IEEgcmVzcG9uc2Ugb2YgNS4wMyAoU2VydmljZSBV bmF2YWlsYWJsZSkgaGFzIHJvdWdobHkgdGhlIHNhbWUNCiAgICAgICAgc2l6ZSwNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgaXMgYXZhaWxhYmxlIGluZGVwZW5kZW50IG9mIHRy YW5zcG9ydCwgYW5kIG9uIG1vc3QgbGlicmFyaWVzDQogICAgICAgICp3YXkqDQogICAgICAgIDxi cj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGVhc2llciB0byB1c2UsIGlmIHRoZXkgc3VwcG9ydCBz ZW5kaW5nIGFuIFJTVCB0byBhDQogICAgICAgIHdlbGwtZm9ybWVkIG1lc3NhZ2UNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYXQgYWxsLg0KICAgICAgICA8YnI+DQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IChGdXJ0aGVybW9yZSwgdGhlIHNlbmRlciBvZiB0 aGUgNS4wMyBjYW4gZW5jb2RlIGFuIGVzdGltYXRlDQogICAgICAgIG9mIHRoZQ0KICAgICAgICA8 YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyByZW1haW5pbmcgdW5hdmFpbGFibGUgdGltZSBpbiB0 aGUgTWF4LUFnZSBvcHRpb247IG5vdCBzdXJlIGlmDQogICAgICAgIHRoYXQgaXMNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgb2YgYW55IGhlbHAgaGVyZSkuDQogICAgICAgIDxi cj4NCiAgICAgICAgPGJyPg0KICAgICAgICAqIDMuMy4xOiAmcXVvdDtyZWNlaXZlZCB3aXRoIHRo ZSBBQ0smcXVvdDssICZxdW90O3NlbmRzIHBpZ2d5YmFja2VkIHJlc3BvbnNlJnF1b3Q7DQogICAg ICAgIGFyZSwNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYWdhaW4sIG92ZXJs eSBzcGVjaWZpYy4gJnF1b3Q7cmVjZWl2ZWQgaW4gdGhlIGxhc3QgcmVzcG9uc2UmcXVvdDsgYW5k DQogICAgICAgICZxdW90O3NlbmRzIGENCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJz cDsgcmVzcG9uc2UmcXVvdDsgY291bGQgd29yayBhcyByZXBsYWNlbWVudHMgZXZlbiBpZiBtZXNz YWdlIHR5cGVzDQogICAgICAgIGFyZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNw OyBwcmVzZWNyaXB0aXZlLg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAg PC9ibG9ja3F1b3RlPg0KICAgIDxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtNDc3YmViYTctN2ZmZi04YTU5LTQ1 OTYtOWU1ZTk0YzAwYzZhIj5bQXV0aG9yc10gV2UgdXNlZCBSU1QgYXMgdGhlIGV4YW1wbGVzIG9m IHRoZSBDb0FQIFJGQyBzZWVtZWQgdG8gY29udmV5IHRoYXQgbWVhbmluZyB3aGVuIHRoZSBlbmRw b2ludCBpcyBub3QgaW4gYSBwb3NpdGlvbiB0byByZXNwb25kIHRvIHRoZSByZXF1ZXN0LCBidXQg dGhpcyBzZWVtcyB0byBiZSBhbiBlYXNpZXIgd2F5IHRvIGFjaGlldmUgdGhlIHNhbWUgZ29hbC4g QW5kIGFzIHlvdSBzYXksIGlmIHRoaXMgaXMgZWFzaWVyIG9uIGltcGxlbWVudGF0aW9ucyB3ZSBz aG91bGQgc3RyaXZlIGZvciB0aGF0LiA8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+ DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2 YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQogICAgICAgIDxicj4NCiAgICAgICAgKiAzLjMuMTogJnF1b3Q7YWZ0ZXIgdGhlIG1h eGltdW0gcmV0cmFuc21pc3Npb24gYXR0ZW1wdHMsIHRoZSBDb0FQDQogICAgICAgIGNsaWVudA0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB3aWxsIHJlbW92ZSB0aGUgc3RhdGUg ZnJvbSBpdHMgc2lkZSZxdW90Oy4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAg ICZuYnNwOyZuYnNwOyBTbyB0aGUgZGV2aWNlIHRoYXQncyBiZWluZyBraWNrZWQgZnJvbSB0aGUg bmV0d29yayBjYW4gZGVsYXkNCiAgICAgICAgaXRzIG93bg0KICAgICAgICA8YnI+DQogICAgICAg ICZuYnNwOyZuYnNwOyBldmljdGlvbiBmb3IgYWJvdXQgYSBtaW51dGUgYXMgbG9uZyBhcyBpdCBk b2Vzbid0IGFuc3dlcj8NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2Nr cXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGln bjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBUaGlzIGlzIGFu IGludGVyZXN0aW5nIHVzZSBjYXNlLiBUbyBhdm9pZCB0aGlzLCB3ZSBtYXkgaGF2ZSB0byBjaGFu Z2UgdGhlIGJlaGF2aW91ciwgdG8gYSBOT04tbWVzc2FnZSBhbmQganVzdCByZW1vdmUgdGhlIHN0 YXRlLiA8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2Zjlh ZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiAzLjMuMjogSXMg cmVhdXRoZW50aWNhdGlvbiBhbHdheXMNCiAgICAgICAgdHJpZ2dlcmVkIGJ5IHRoZSBFQVAgcGVl ciwgb3IgY2FuIGl0DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGFsc28gYmUg dHJpZ2dlcmVkIGJ5IHRoZSBhdXRoZW50aWNhdG9yPyBJZiB0aGUgbGF0dGVyLCB3aWxsDQogICAg ICAgIHRoZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdG9y IHVzZSAvLndlbGwta25vd24vYSBhZ2Fpbiwgb3IgUE9TVCBzb21ldGhpbmcgdG8NCiAgICAgICAg dGhlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHJlc291cmNlIGZyb20gd2hl cmUgaXQnZCBERUxFVEUgaW4gMy4zLjE/DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90 ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdo dDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJu YWwtZ3VpZC04MzRlZjQ0Ni03ZmZmLTFiOGEtNDdlZS0yMDk5ZDI2ZWUyM2QiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGln bjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBUaGUgYW5zd2Vy IGlzIHllcywgRUFQIHBlZXIgYWx3YXlzIHRyaWdnZXJlZCB0aGUgcmUtYXV0aGVudGljYXRpb24s IGFzIGl0IGlzIHRoZSBvbmUgaW50ZXJlc3RlZCBpbiBtYWludGFpbmluZyBpdHMgbWVtYmVyc2hp cCB3aXRoaW4gdGhlIGRvbWFpbiwgb3IgZXZlbiBpdCBjb3VsZCBiZSBkb3JtYW50IGF0IHNvbWUg cG9pbnRzLiBBIHVzZSBjYXNlIGZvciB0aGVzZSBpcyBMb1JhV0FOIG5vZGVzLCB0aGF0IGhhdmUg dGhlIGNhcGFiaWxpdHkgb2Ygc3RhcnRpbmcgdGhlIGNvbW11bmljYXRpb24gcmVnYXJkbGVzcyBv ZiB0aGVpciBjbGFzcywgd2hlcmVhcyB0aGUgTmV0d29yayBzZXJ2ZXIgbWF5IG5vdCBzZW5kIGEg bWVzc2FnZSB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgc29tZXRoaW5nIGZyb20gdGhlIElvVCBkZXZp Y2UuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpBcmlh bDtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWlnaHQ6 NzAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNvcmF0aW9u Om5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNl OnByZS13cmFwOyI+DQo8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkz ODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog ICAgICAgIDxicj4NCiAgICAgICAgKiBjcnlwdG9zdWl0ZXM6IFdoYXQncyB0aGUgdXBncmFkZSBt b2RlbCBvZiB0aGF0IGhhcmRjb2RlZCBsaXN0Pw0KICAgICAgICBBcyBpdA0KICAgICAgICA8YnI+ DQogICAgICAgICZuYnNwOyZuYnNwOyBpcyBub3csIGl0IGxvb2tzIHByZXR0eSBzdGF0aWMsIHNv IHVwZGF0ZXMgd291bGQgYmUgdGhyb3VnaA0KICAgICAgICB1cGRhdGVzIG9mDQogICAgICAgIDxi cj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHRoaXMgZG9jdW1lbnQuIFRoZSBvYnZpb3VzIGFsdGVy bmF0aXZlIGlzIGFuIElBTkEgcmVnaXN0cnkNCiAgICAgICAgd2l0aA0KICAgICAgICA8YnI+DQog ICAgICAgICZuYnNwOyZuYnNwOyByYW5nZXMsIHBvbGljaWVzIGFuZCB0aGUgdXN1YWwgcHJvcyBh bmQgY29ucy4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNw OyBUaGVuIGFnYWluLCB0aGlzIGlzIG5vdCB0aGUgZmlyc3Qgbm9yIGxhc3QgdGltZSBBRUFEDQog ICAgICAgIGFsZ29yaXRobXMgd2l0aA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNw OyB0aGVpciBwYXJhbWV0cml6YXRpb24gYW5kIGhhc2ggZnVuY3Rpb25zIGFyZSBhc3NpZ25lZA0K ICAgICAgICBhZ2dyZWdhdGUNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgbnVt YmVycyAoSS1ELmlldGYtbGFrZS1lZGhvYyBjb21lcyB0byBtaW5kIHdoaWNoIGhhcw0KICAgICAg ICBhc3ltbWV0cmljIGFsZ3MNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgaW4g dGhlIG1peCB0b287IHByb2JhYmx5IG90aGVycyBhcyB3ZWxsKTsgY2FuIHdlIGRlZHVwbGljYXRl DQogICAgICAgIHRoaXMgd2l0aA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBh bnl0aGluZz8gKFBvc3NpYmx5IGJ5IGJyaW5naW5nIHRoaXMgdXAgd2l0aCBDT1NFIG9yIE9TQ09S RQ0KICAgICAgICBwZW9wbGUpLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwv YmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRy IiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBw dDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtNTRjZDgzNTMtN2ZmZi1kZTY5LWVmOTAtMzRkZDA2 ZThlN2I0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5b QXV0aG9yc10gSW4gdGhlIG5leHQgdmVyc2lvbiB3ZSB3aWxsIHByb3Bvc2UgYSBzdHJ1Y3R1cmUg dG8gYWRkIGRpZmZlcmVudCBwYXJhbWV0ZXJzIHRvIHRoZSBDb0FQLUVBUCBleGNoYW5nZS4gV2l0 aGluIHRoZXNlIHBhcmFtZXRlcnMsIHdlIGNvbnNpZGVyZWQgdGhlIGV4dGVuc2liaWxpdHkgb2Yg dGhlIGNyeXB0byBzdWl0ZSBhbGdvcml0aG1zLjwvc3Bhbj48L3A+DQogICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2Zjlh ZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiBPU0NPUkUgZGVy aXZhdGlvbjogSXMgaXQNCiAgICAgICAgY3J5cHRvZ3JhcGhpY2FsbHkgbmVjZXNzYXJ5IHRvIGRl cml2ZSAqYm90aCoNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYSBtYXN0ZXIg c2VjcmV0IGFuZCBhIG1hc3RlciBzYWx0IHRocm91Z2ggS0RGPyAoU291bmRzIGxpa2UgYQ0KICAg ICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBuZWVkbGVzcyBzdGVwIHRvIG1lLCBhcyBi b3RoIG9ubHkgZ28gaW50byBLREYgb25jZSBtb3JlIHdoZW4NCiAgICAgICAgdGhlDQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGFjdHVhbCBPU0NPUkUgcGFyYW1ldGVycyBhcmUg ZGVyaXZlZCkuIEkgKmd1ZXNzKiB0aGVyZSdzIGENCiAgICAgICAgZ29vZCByZWFzb24NCiAgICAg ICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgd2h5IHRoZSBNU0sgaXMgbm90IHVzZWQgYXMg dGhlIE9TQ09SRSBJS00gcmlnaHQgYXdheSBhbmQgdGhlDQogICAgICAgIENTTyBhcw0KICAgICAg ICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBPU0NPUkUgbWFzdGVyIHNhbHQsIGJ1dCBpdCdk IGhlbHAgdG8gaGF2ZSBhdCBsaXN0IGEgY29tbWVudA0KICAgICAgICBoZXJlIG9uDQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHdoeSB0aGF0J3MgbmVlZGVkLg0KICAgICAgICA8 YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IChJdCBtYXkgYmUgdXNlZnVs IHRvIGNvbXBhcmUgdGhpcyBzdGVwIHRvIHRoZSBIS0RGIHN0ZXBzIGluDQogICAgICAgIE9TQ09S RTsNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdGhlaXIgaW5mbyBlbGVtZW50 IGlzIGFsd2F5cyBhIDUtZWxlbWVudCBhcnJheSB3aXRoIGEgNHRoDQogICAgICAgICZxdW90O3R5 cGUmcXVvdDsNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZWxlbWVudCBvZiAm cXVvdDtLZXkmcXVvdDsgb3IgJnF1b3Q7SVYmcXVvdDs7IG90aGVyIGV4dHJhY3Rpb25zIG1pZ2h0 IGp1c3QgaG9vaw0KICAgICAgICBpbiB0aGVyZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNw OyZuYnNwOyB3aXRoIGRpZmZlcmVudCB0eXBlIHZhbHVlcywgbWF5YmUsIGFuZCBzYXZlIGV2ZXJ5 b25lIGFuIGV4dHJhDQogICAgICAgIGhhbmRsaW5nDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IHN0ZXApLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxv Y2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5l LWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3Mt aW50ZXJuYWwtZ3VpZC02YWU3ZWMyMi03ZmZmLTQxNjMtYmRkNS00NGM1Yzg5YzUyNzIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdi KDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNh bC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBZb3Ug YXJlIHJpZ2h0LCB0aGVyZSBzaG91bGQgYmUgYSBjbGFyaWZpY2F0aW9uIG9uIHdoeSB0aGlzIGlz IGRvbmUgdGhlIHdheSBpdCBpcy4gVGhlIG1haW4gcHVycG9zZSBpcyB0byB1c2UgTVNLJm5ic3A7 IGFzIHRoZSByb290IGtleSBmb3Iga2V5IGRlcml2YXRpb24uIEl0IGlzIGNvbW1vbiBwcmFjdGlj ZSB3aXRoIHRoZSB1c2FnZSBvZiB0aGUgTVNLLiBJZiBzYXkga2V5IHdlcmUgY29tcHJvbWlzZWQs IGFub3RoZXIgb25lIGNvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgTVNLLCB3aXRob3V0IGhhdmlu ZyB0byByZXNvcnQgdG8gYSBuZXcgYm9vdHN0cmFwcGluZyB0byByZWZyZXNoIHRoZSBNU0suPC9z cGFuPjwvcD4NCiAgICA8cD48YnI+DQogICAgPC9wPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNpdGU9Im1pZDpjOWNkYjIxNi01OWE3LWIwNmEtN2NkMC05Mzg2ZTdiNmY5YWVAdW5pb3Zp LmVzIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPiogT1NDT1JFIElEIGRlcml2YXRp b246DQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgKiBS YW5kb21seSBhc3NpZ25lZCBmdWxsLWxlbmd0aCBpZGVhcyBsb29rIGxpa2UgYW4gb2RkDQogICAg ICAgIGNob2ljZS4gVGhleQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhcmUgZXhjZXNzaXZlbHkgbG9uZyAobm9uY2UgbGVuZ3RoIC0gNiBpcyA3IGZvciB0 aGUgTVRJDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFF Uy1DQ00tMTYtNjQtMTI4IGFuZCBzaG9ydGVyIGZvciBvdGhlciBjdXJyZW50IG9uZXMsIGJ1dCBJ DQogICAgICAgIGRvdWJ0DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoYXQga2VlcGluZyB0aGUgSVYgKnNob3J0KiBpcyBuZWNlc3NhcmlseSBhIGRlc2ln bg0KICAgICAgICBjcml0ZXJpb24gZm9yDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGZ1dHVyZSBhbGdvcml0aG1zKS4NCiAgICAgICAgPGJyPg0KICAgICAg ICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGF0IGNvbW1vbmx5IGhh cHBlbnMgaGVyZSAoZWcuIGluIHRoZSBBQ0UtT1NDT1JFIHByb2ZpbGUsDQogICAgICAgIG9yIGlu DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVESE9DKSBp cyB0aGF0IGVhY2ggcGFydHkgcGlja3MgYSByZWNpcGllbnQgSUQgb3V0IG9mIGl0cw0KICAgICAg ICBwb29sIG9mDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGN1cnJlbnRseSB1bnVzZWQgSURzLiBUaGlzIG1ha2VzIGZvciBzaG9ydGVyIGtleXMsIGFuZA0K ICAgICAgICBhbGxvd3MgdGhlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNsaWVudCB0byBiZSBzdXJlIHRoYXQgbm8gdHdvIHBlZXJzIHVzZSB0aGUgc2Ft ZSBjb250ZXh0Lg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFueSBjaGFuY2Ugc29tZXRoaW5nIGxpa2UgdGhhdCBjYW4gc3RpbGwg bWFrZSBpdCBpbj8NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVv dGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWln aHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVy bmFsLWd1aWQtYjA3MDE4NjYtN2ZmZi1mN2MyLWViM2ItMGQyNTI5NTVlMjNhIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAw LCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxp Z246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5bQXV0aG9yc10gRGlkIG5vdCBz ZWUgdGhhdCBhcyByYW5kb20gYnV0IHBhcmFtZXRyaXNlZCBhY2NvcmRpbmcgdG8gdGhlIGNyeXB0 byBzdWl0ZS4gV2Ugd2lsbCB0cnkgdG8gbWFrZSB0aGlzIGFzIHN0cmFpZ2h0Zm9yd2FyZCBhcyBw b3NzaWJsZSBmb2xsb3dpbmcgeW91ciBjb21tZW50cy4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1j b2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo3MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12 YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQog ICAgPHA+PGJyPg0KICAgIDwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJt aWQ6YzljZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4mbmJzcDsmbmJzcDsgKiBJZiB0aGUgcGFydGllcyBo YXBwZW4gdG8gYmUgYXNzaWduZWQNCiAgICAgICAgdGhlIHNhbWUgc2VuZGVyIElELCBiYWQgdGhp bmdzDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhcHBl biAoaWRlbnRpY2FsIGtleSBkZXJpdmF0aW9uLCBub25jZSByZXVzZSwgbnVjbGVhcg0KICAgICAg ICBtZWx0ZG93bikuDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIGN1cnJlbnQgcGF0dGVybiBvZiBLREYnaW5nIElEcyBz dGFuZHMsIHRoaXMgbmVlZHMgdG8NCiAgICAgICAgYmUNCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJldmVudGVkIGV4cGxpY2l0bHkuDQogICAgICAgIDxi cj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAg IDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJn aW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtMjAxZjliNmQtN2ZmZi0zMGYy LWI4ZDEtZjRjMDE5OWQ0N2FjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7Ij5bQXV0aG9yc10gU2luY2UgdGhlIFNlbmRlciBhbmQgcmVjaXBpZW50IElEcywg YXJlIGRlcml2ZWQgZnJvbSB0aGUgTVNLLCB3aGljaCBpcyBhc3N1bWVkIHRvIGJlIGZyZXNoIGtl eSBtYXRlcmlhbCwgSSB0aGluayB0aGlzIHNob3VsZCBub3QgYmUgYSBwcm9ibGVtLiA8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAw MDAwMDtiYWNrZ3JvdW5kLWNvbG9yOnRyYW5zcGFyZW50O2ZvbnQtd2VpZ2h0OjcwMDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lO3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcDsi Pg0KPC9zcGFuPjwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Yzlj ZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsg KiBUaGUgZGVyaXZhdGlvbnMgb2YgJnF1b3Q7T1NDT1JFIFJFQ0lQSUVOVCBJRCZxdW90OyBhbmQg JnF1b3Q7T1NDT1JFIFNFTkRFUg0KICAgICAgICBJRCZxdW90OyBhcmUNCiAgICAgICAgPGJyPg0K ICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZnVzaW5nIGFzIHRoZXkgZWFjaCBu ZWVkIHRvIGhhcHBlbiBvbiBib3RoIHNpZGVzLCBhbmQNCiAgICAgICAgdGhlIHRlcm1zDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpbGwgbWF0Y2ggb24g b25lIGFuZCBuZWVkIHRvIGJlIG9wcG9zaXRlIG9uIHRoZSBvdGhlci4NCiAgICAgICAgPGJyPg0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoSSBjb3VsZG4n dCBldmVuIGVhc2lseSBmaW5kIHdoaWNoIGlzIGludGVuZGVkIHRvIGJlDQogICAgICAgIHdoaWNo KS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBNeSBzdWdnZXN0aW9uIGlzIHRvIGRlcml2ZSAmcXVvdDtPU0NPUkUgRUFQIFBFRVIg U0VOREVSIElEJnF1b3Q7IGFuZA0KICAgICAgICAmcXVvdDtPU0NPUkUNCiAgICAgICAgPGJyPg0K ICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQVVUSEVOVElDQVRPUiBTRU5ERVIgSUQm cXVvdDsgaW5zdGVhZC4gKE9yIHByZWZlcmFibHkgc2hvcnRlcg0KICAgICAgICBzdHJpbmdzKS4N CiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9i bG9ja3F1b3RlPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtMzAy NmRiY2ItN2ZmZi01ZDEyLWE0ZTctOTg0NTlkZjllMTIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5l OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5bQXV0aG9yc10gR29vZCBwb2ludCwgdGhhbmsgeW91 LiBXZSB3aWxsIGFkZHJlc3MgdGhpcyBhY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9uLjwvc3Bh bj48L3A+DQogICAgPHA+PGJyPg0KICAgIDwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5l cyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4qIEV4bWFwbGVzOiBEbyB5b3UgZW52 aXNpb24gcGFydGljdWxhciBFQVANCiAgICAgICAgcHJvdG9jb2xzIHRvIGJlIHVzZWQgaW4gdGhl DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGdpdmVuIGV4YW1wbGVzPw0KICAg ICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxw IGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4t Ym90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtNDA1ODc1ZDYtN2ZmZi1jMzAxLTlh OGItNzViZmVlMzk4NTlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJl LXdyYXA7Ij5bQXV0aG9yc10gV2UgY29uc2lkZXIgdGhlIGV4YW1wbGVzIHRvIHVzZSBsaWdodHdl aWdodCBFQVAgbWV0aG9kcy4gVGhpcyBjb3VsZCBiZSBFQVAtUFNLIGZvciBpbnN0YW5jZS4gDQo8 L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlv dmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4NCiAg ICAgICAgQmVzdCByZWdhcmRzDQogICAgICAgIDxicj4NCiAgICAgICAgQ2hyaXN0aWFuDQogICAg ICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogIDwvYm9k eT4NCjwvaHRtbD4NCg== --------------7CFFD4FA37F207B354D8AA67-- From nobody Mon Sep 13 05:25:44 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377333A0A40 for ; Mon, 13 Sep 2021 05:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUNKq1lT0rF1 for ; Mon, 13 Sep 2021 05:25:37 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A673A0A3D for ; Mon, 13 Sep 2021 05:25:35 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A973341687 for ; Mon, 13 Sep 2021 14:25:31 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4B542D7 for ; Mon, 13 Sep 2021 14:25:30 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8c44:e3df:d5ca:1614]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E2EDC245 for ; Mon, 13 Sep 2021 14:25:29 +0200 (CEST) Received: (nullmailer pid 2343715 invoked by uid 1000); Mon, 13 Sep 2021 12:25:29 -0000 Date: Mon, 13 Sep 2021 14:25:29 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ATHClaA6UB9XB/K" Content-Disposition: inline Archived-At: Subject: [core] Story for "How do I get my HTTP authentication token in?" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 12:25:42 -0000 --6ATHClaA6UB9XB/K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, being the 3rd time[1][2][3] that someone (publicly) wants to put a bearer token into a CoAP option, I think it's time for a FAQ entry, but I don't know what precisely to put there. The standard answer is "don't use bearer tokens, and set up your connection PoP'ing your token", but at least the folks at [3] can't do that as long as one of their deployments[4] has a trusted gateway that passes on the token. So, what's the best we can recommend them to do? * If the transport is OSCORE, they can probably use EDHOC and stuff it into a custom ID_CRED_I in the style of an UCCS, limiting the bearer to the initiator role. (If of course they had a CWT it'd be really straightforward). (Nice benefit over the frequent "pass it as an option" approach is that it's now in the payload and can thus be blockwised.) * Is there any point in DTLS where a equivalent information could be fed in? (There's TLS-CWT[5], could that too do UCCS?) (I think we should provide some guidance, for otherwise things will just be deployed anyway, and CoAP blamed when they fail.) BR c [1]: http://mailarchive.ietf.org/arch/msg/core/Wnr3G_2sTpErDP4XoQ0o0HPmk5c [2]: https://stackoverflow.com/questions/58374333/how-to-send-token-in-coap= -requests [3]: https://github.com/matrix-org/matrix-doc/pull/3079#issuecomment-917708= 454 [4]: https://gitlab.com/comatrix/comatrix/-/tree/master [5]: https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-cwt-02 --=20 We are dreamers, shapers, singers, and makers. -- Elric --6ATHClaA6UB9XB/K Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmE/QzMACgkQOY0REtOk veFiwg/+JMWdhHhUYvOVv+gokpTPFQy53Y1+ul3nraCOTc2aqZ2/IlVc5Tgd7TvY CUYSWfEIui2rEpjxqCngyq0ymRR4qRySaVWa8xSm8/oBkJLvUlisjQPLnIm7JoOt B2OeSHqnSH1WR9PbXB1vB3EWnvxHiC2NhtR2o9a2fO70uoGtqC2xpukGFBA4j2oQ ip4/SuD8+QjT48ncGITcRwX4nBWdC1pkCI4OhZj2vSte4gRQeWA93uyDVbhc4qtg wiNkNN0o6G+KHFcemFB9TwdpehJ0KWvaaitMPPDFFRXw4iFp5xQuPh6thQvkcAcx fKI0jtpkme7E6D7w0SXasp9rOws5d8qkZ3T4uAekRdNCY/wbNoFvBWANVDP2Ln9R Apyj765UfqHcfL9ABiYXNI4KDgJQCEfwSD5pqBSknG1bP4IIVRs6mbR7oO1y9Dcs Y0+5W3UvGCVPUceXy6YPpi8SG8gxUrFirsKEw2mhhpqBE5bCaa7xM7+Lk12MaSra eJahk1auHou6mfu4lRn7tIpFDC7FOU/8mqEbSVrgEQKuqPwcIhZxEDvl37n6T50n iQh6qRTNwiNA826Nd0jeXVROo/JHWHtzUZwcqrQ2nTgM/Flpnl43nVvPyalo+bD8 H0nnPFCWGStZiRVByqJXG4T9v+YHh3it59Rg15F8RETYqbqWpdA= =s6BE -----END PGP SIGNATURE----- --6ATHClaA6UB9XB/K-- From nobody Mon Sep 13 22:21:07 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16893A11B3 for ; Mon, 13 Sep 2021 22:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 373idUejBDlO for ; Mon, 13 Sep 2021 22:20:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 1CC453A11AA for ; Mon, 13 Sep 2021 22:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631596849; bh=qfe8ZpFS/0kKm6bFGMc1b2x54TnTuZ2GXHA3X/IFdrU=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=hLLIhpGe8ieDMwF9hc4UfRS6TzjzybbymUXuFZZ0uucCbNhUVizaft+lbib4YRfqm eYWlY8r3JBnt6es+hVF1L5XGVBwpyyfhLUNJHUHqMi2umOAyFoskZ/WVboDYHwJIxk 0H0eqXDrRxyT7/u169+jglH/Lvy76uovlSpBW2KM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([88.152.185.165]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTRMs-1mKYpx0UGK-00TpWF; Tue, 14 Sep 2021 07:20:49 +0200 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= References: Cc: "core@ietf.org" From: Achim Kraus Message-ID: Date: Tue, 14 Sep 2021 07:20:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:dntoDPe8Dj3gZEhq8VuVmPy1lXr2TEVgIoIhE6s9aMb0eObht60 X2/MIaTrZlhZ/pCSdIny2ri7HsWUO7gLTLDGU4XSpcipNdLOCEDWvl9mtFHJp4a8h6idanK F81FEFnqmGt5Eo414CXhnW6Mu03Wwaj2Z53gT/yV1wGwfHUPJxPgaRvC0AftYXBI/uWvB60 wWnXcTkrdKcJe7EkRyRlg== X-UI-Out-Filterresults: notjunk:1;V03:K0:UIyT9I56st4=:/nLkamedMNYDGMP5j+3B8B +TpGUtOkgvIbcQ20ssZFP58tl3Px3RpPX6+F76/scK8qLkaFqzqrdwkbzIHBYK2LGQgB3WT2Z X/A+V4lWVWQ2kBr+mneRSsTGlirpKRF1VC/rZk91DkgAJexlytiAzTBh8ieVTrOkAPaSqhQZt 5NwjXJlxT8S1kcI6I0rHQAmvfOPv+qPOMw7fyE0or1GK8/DRNVLb+LVs6LoCj/4Rogdbk4HcL Gck3rJ++2/6q6v0plPH3+rfVNq0/TLrsICLZgTuwZW17/USZBrGBTgghmaXv49KjO/PU+TZRU jpmyRc/q5qPtNhx5xZCieyZezcH9omjNwaZS14gt8d2EK+IwfBYvIs8VDwvaQgsKGGaFLSfoi w9DE9cl95oKTZdGBcrJj2nJ2ijDZ6SyaCHhghXSaAPCM2lySChPt33misNNkZ8blb267lVlaE g0odG8C86SDY4I7LGXSdt7NDyLxMKgaz3NhHxFJGvVPGKmfuvvvhSOe8IY0UYxOL1v0Fk/8Js Lkp5DghOehIYVapoxygEtT8RGahSFGf7MiYfNlnejjSOTXDtTQK5zBCTfwvZAW8+bQcUsfhJC xK29eJ6+JYu/p8zDYzhf62WBh+KnNY/EsfXQS3v3pWWM7fiO7Uf0PwJtL/qJgeswXMTPh+TuD Xor0a3eX/drVPPrJzlks5MTllQUYfVcTiUPU9nH5seXFj+Q0MERa2vGPB08iaV6BwZpZQN1mQ afAO2MIULNbAspI7nuBkS7Mx0MzJyYHrLTTRZL2XwjKB31gZdal0OoH9Yw2ZVC50gyGw+T5x/ Xf/+73FXRbAk7MRLrV/ZDWTh2OLlNIRI0TQ0XxO/AWiCnNGikCiORElgDMbFv5s81L2tNJi4f Xmi9n/buN8jGWpExkXqR0yAHa8k/5syZw18yD6rjOh3gcvnRkdiLvkV54PPgAch9vjibYoCP8 eVfD8BLEBlxc1abNJe/T2fjtKEI+X587esPkvCriUK4fMgtev4ZpCXFviDhtSZM57BLlSYERo RkSc3CW/oR9O4Ho9FEzwseinuF7hLSUCaXxVUxWAwDCgOR7Tco9GeM0d6G0ecoSSZIkmK6koy N6/2ZxOEYgCMQE= Archived-At: Subject: Re: [core] Story for "How do I get my HTTP authentication token in?" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 05:21:05 -0000 Hi Christian, thanks for taking action. I would like to add one more use-case to consider, it's the approach using the token for http-communication with a coap2http cross-proxy as in https://cloud.google.com/community/tutorials/cloud-iot-coap-proxy https://github.com/GoogleCloudPlatform/community/tree/master/tutorials/clo= ud-iot-coap-proxy There the communication between the client and the proxy uses DTLS and a bearer token is sent in order to use a general HTTPs API. best regards Achim Kraus Am 13.09.21 um 14:25 schrieb Christian Ams=FCss: > Hello CoRE, > > being the 3rd time[1][2][3] that someone (publicly) wants to put a > bearer token into a CoAP option, I think it's time for a FAQ entry, but > I don't know what precisely to put there. > > The standard answer is "don't use bearer tokens, and set up your > connection PoP'ing your token", but at least the folks at [3] can't do > that as long as one of their deployments[4] has a trusted gateway that > passes on the token. > > So, what's the best we can recommend them to do? > > * If the transport is OSCORE, they can probably use EDHOC and stuff it > into a custom ID_CRED_I in the style of an UCCS, limiting the bearer > to the initiator role. (If of course they had a CWT it'd be really > straightforward). > > (Nice benefit over the frequent "pass it as an option" approach is > that it's now in the payload and can thus be blockwised.) > > * Is there any point in DTLS where a equivalent information could be fed > in? (There's TLS-CWT[5], could that too do UCCS?) > > (I think we should provide some guidance, for otherwise things will just > be deployed anyway, and CoAP blamed when they fail.) > > BR > c > > [1]: http://mailarchive.ietf.org/arch/msg/core/Wnr3G_2sTpErDP4XoQ0o0HPmk= 5c > [2]: https://stackoverflow.com/questions/58374333/how-to-send-token-in-c= oap-requests > [3]: https://github.com/matrix-org/matrix-doc/pull/3079#issuecomment-917= 708454 > [4]: https://gitlab.com/comatrix/comatrix/-/tree/master > [5]: https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-cwt-02 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From m.s.bradbury@lancaster.ac.uk Tue Sep 14 01:09:57 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCD43A0E6B for ; Tue, 14 Sep 2021 01:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=livelancsac.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 gEMqaZ3U1IUJ for ; Tue, 14 Sep 2021 01:09:53 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110126.outbound.protection.outlook.com [40.107.11.126]) (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 BCD933A0E63 for ; Tue, 14 Sep 2021 01:09:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q5nDo7OEAYwpRZePDf4ZpFq3JiG8K0T77arTf2bCV+VxQGUdu3EYmwCDVgR5oUr/97aCd2BjdBrGkU2aFO90lqlq4RY6hyeRNDxzHOpGdEmCCwJSDy8OnClADrC1I1/FAcWGzA+FI4qFTesTA2lUJUXpHrPpxK63wmNYfKZB7oe/gXeGsPFY4/6d/izqqp4gGt1wLOewl7dGJI7pXDbPW0NDdHOfecasEr8gS9iW0kbb+o00oxJRKLDrd7MQQgxdfLW0Yy9IlZvVdYR+AZFY6DQqEaj+PqM9n8PabvQ5C8pr9m+kKdtsguL8sp24zPyyr6XFwLAr2yiqnts+kIkFNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jiX9dQqmoAEh9x/63WC67yAo9vM1IqTOvUHLw/siNsw=; b=jI2R8nnVx72QsmEL7Nkzr7rrNnziuXIv9unCjvWW1hU8YIrIPu+3tEIr9sd/S3eV0Xq8YLBpaBGPreRj1qs5fsvfXmC7NI8PIrWSeH6JQuoGZ2eCEdOETShbvuB3ZFvK6vw/wGZdv/s8b64Ch0pcUieTmcX9VxsrVYuuaJYk1z1xSxi2Uwk/16MMMqLE1DrE0KEl02N36NwN0ZqC1pQHjk/oSQ97DN0fssVohAtbGds2n5zNOmVzfilif/EYodgS00JB8fN6XSIoqd63DUAOC5TDy5bYUYl7D2SLfzLmC/Df92rcTJoTHrHpmcnsAuMhSBAy1Wb8bEcnavxNtjXkKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lancaster.ac.uk; dmarc=pass action=none header.from=lancaster.ac.uk; dkim=pass header.d=lancaster.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=livelancsac.onmicrosoft.com; s=selector2-livelancsac-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jiX9dQqmoAEh9x/63WC67yAo9vM1IqTOvUHLw/siNsw=; b=eRdoKppKHEeLKbvJsl17nnA8r1l2/d/7Zv8J5YQzr38UcCT//bXqvCK6Aq3ct6hLicCEVx6HtTksxN1oxxKxeYjVbtQWPTuovjMtbW5S3LWD+PMDIa79pS5BMuAgqmad1D5nx8t2JzqOdWhX3R4bhPEiXCC1jirxperAOXhbojI= Received: from CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:3b::13) by CWLP265MB2243.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:60::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.15; Tue, 14 Sep 2021 08:09:49 +0000 Received: from CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM ([fe80::a881:5a67:9cc0:752c]) by CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM ([fe80::a881:5a67:9cc0:752c%3]) with mapi id 15.20.4500.019; Tue, 14 Sep 2021 08:09:49 +0000 From: "Bradbury, Matthew" To: "core@ietf.org" CC: =?iso-8859-1?Q?G=F6ran_Selander?= , =?iso-8859-1?Q?Christian_Ams=FCss?= Thread-Topic: Additional use cases for Group OSCORE Thread-Index: AdepPvWBxRUPF0VTRBWaJQfnO46XhA== Date: Tue, 14 Sep 2021 08:09:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=lancaster.ac.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e592856-f430-4a93-b00d-08d9775705a2 x-ms-traffictypediagnostic: CWLP265MB2243: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q3OyFYQ+gc0jwH8nfe4PpicbTA9whBuQPWkfrlw4ARc+88qZM47cwH/zMF4gP9QtuytuVQelOSv8FiafM4EuER3yjMtr+NuBfoee2KU2rH66YUabVpKWTYbRquwwICryzWs/7+CYBv7afH9eorMmPpcZfIY9QkRvl5TIylICp0nk2RoByrxIymQY8r2/gFuXNry/MgcTUJvp+vkPlBca6zIjse1A/M8NWGfQEqQtMAqlKAY6crhkpYRy2okg3WLsB0Dw04k/MT9Cy6O0C7atZdigJxZTJ7ADnI2CWufe5UQ9sCbek6nzbISm3a1de7BfMLmpPq4aObBUu08p4OyeS0Dp7/CxNW2u8CvSyyjiP/rliq9OVelG0f+hIPnxPSvry7uH93SIJx3hXfxTaKse1L47JO6mgNLFQP7KkGFxcsLFfR1PwndvVRAcitJwEFcRtF+VrpiyR1gp2jOP0FM8SDDhDyFC2B/5Uifxx+dOmCMWOiFuxZ3Oi1pw8L7oD/KakLUJ6XFWtamTfHbILpxxKQGmc+uW5qu7j86R9Cxg2WoJuk3D2dGCpaFWHyL57FlUtZ00eleItAPsICsvPNkQOEJrzoRREx2g9oIkfI7R5TsVZXo1L4C1Senv3Qc1aFh99QVXK2UlgXYGO0MY/cJmLa0Skgb9tr3wend+Vtkv9nE9JrA/27KMG6Bi1EGxqRSSu7uL3dDWQSlqpwqwpjnGz4rDHg5v2bAaRKG0zSsBO5UgaMTsQzMXGcou+5czS3oCiK17pTywUFkK5ZHCZUxRzWNFQkxeHGi2wuF3Nrpw0bM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(7696005)(52536014)(6916009)(6506007)(966005)(66476007)(66556008)(83380400001)(8936002)(54906003)(26005)(66446008)(71200400001)(64756008)(66946007)(55016002)(2906002)(4326008)(38100700002)(86362001)(8676002)(9686003)(66574015)(33656002)(508600001)(316002)(186003)(122000001)(55236004)(5660300002)(38070700005)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?3IemVALglXu3GYY/GfYWSxfpcnuvxWWwTfbvGiRh4qVTl5y252nsTkw+GQ?= =?iso-8859-1?Q?G1GVpb3557Q71BVjgcYbVaVlbBSSZR85HyEs/S+HljK6hYoFsyn6CMbGn5?= =?iso-8859-1?Q?3adQwGgJ2YCCXdWnlEL6ZHk+uqrOPa0MDdxlBU86A3YRR7dJO1i3HwWN7u?= =?iso-8859-1?Q?ovMTQa7PpFRIA4hcRNh3S238EAF20AIIPUaoKGbbkMMIcze2lj7DX6m9Tt?= =?iso-8859-1?Q?NeYn+rEshzqWUOh56OJz0ubI5Pql93xd1AEyRU2syXYGbM2A9x8OirJ9zn?= =?iso-8859-1?Q?4VIAekRS0ubLSqqz7HCeSHBR/Nj1Yz5mwGEnf5culcfvQ4woL+5v6eHlzj?= =?iso-8859-1?Q?9y1CsjpDyKq1/jGUCCfRCKicZ1yeaqIu/tXQcjkrtCawctLJaXQ16h+hkG?= =?iso-8859-1?Q?+Ib/QJuoCgwt2bweN90PWf7X+ODk0kmh8ji9VELFPQ6sYih9pfmMyBQSqi?= =?iso-8859-1?Q?lM+hmDS2BahVz9qlQvApi14BcPwjqdYUwwJckdjPyFOdx1Y0WXsNGfdauL?= =?iso-8859-1?Q?yIwSM6bjz+d/risZfqMi6ytSdKjB7BPPLvhfq+lcnycBoNX6bM6q1RdJU9?= =?iso-8859-1?Q?cqxk0v5CuLPWSkBBaUh/hau+jd+cBrpJ+3N0+NJ5RDn8WqLwKS1HAjgHRX?= =?iso-8859-1?Q?W8kK6nimNsLTQgYD6oDxuEd/rZdzo/T9Q5Z3G7hROCDmCVixhTusyMLq0W?= =?iso-8859-1?Q?c5qg4Cf3QJSLyd+7ylpzq3AfiHAklJGmWvvZJd5r1K3ewejwh3xNanzX1M?= =?iso-8859-1?Q?zckv630senf0Ox9neaymV6M9vsO1AboTy+qMt5CqTbl42rXxY3e2yhFBk1?= =?iso-8859-1?Q?abDVgNYX+jLYZdsdw8ig6oCXdIreZMR8BxPZhyus44OsyAI0WDFFuJzFWX?= =?iso-8859-1?Q?4s3AYjl2cPWKgtL2ZSi5lxqlw0zy2lzk+mqGKif1V31kUjQH8ISeDwHmlT?= =?iso-8859-1?Q?Nja1XEuSMy2MO4p94EI+aAFV0v40NIlYN76ITYl6fdJjmDvyldR9IfOc6e?= =?iso-8859-1?Q?ocRmdawNmuT2kI/PO5MJUDwans8Ff0qmvpTmYhsB1X6RKuFFYud3AfpLwv?= =?iso-8859-1?Q?CuD8lDDZKTFD0YhA2NTPitIdhM8gD9JVpqs4q1kdKfGffImL3eUYijP6SY?= =?iso-8859-1?Q?gSqm0HNnNGw8EaQ7v3uk8J+iY8OjGf7q/2SuPz+J5yismYgJJVv+Zw3PJ4?= =?iso-8859-1?Q?ubAL0+CfaK3XTGSYBqCLCyFoW3HKnL4DXoHnl+Zaaep6QjWR7qyZio07RK?= =?iso-8859-1?Q?pZ/HNALy2cKAUELN+zw/nOuiSLszVm6+b6kYIMxmXl8JUNO0Ybe1uM13qG?= =?iso-8859-1?Q?q2OF/wNhgrSMusjgDCcgQ74Cq8yhXNkfO/YTBSjIlfpulKe84PDVNN9ofm?= =?iso-8859-1?Q?4Mf2ABGO7x?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CWXP265MB099943F6D34A935386EFD90780DA9CWXP265MB0999GBRP_" MIME-Version: 1.0 X-OriginatorOrg: lancaster.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6e592856-f430-4a93-b00d-08d9775705a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2021 08:09:48.9534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c9bcd11-977a-4e9c-a9a0-bc734090164a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oQaymQY8GH2QXJ57/YcnkUxySSlkHoiwfSN/zwV1qtrqy1d7OqW9oQ6EFg/VwME0y62HHB96b7kYYgeWCyCy1rL5kYnCbz5eQYyneX0/K0Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB2243 Archived-At: X-Mailman-Approved-At: Tue, 14 Sep 2021 01:34:14 -0700 Subject: [core] Additional use cases for Group OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 08:11:11 -0000 --_000_CWXP265MB099943F6D34A935386EFD90780DA9CWXP265MB0999GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I recently watched a talk by Christian Ams=FCss [1] which included an intro= duction to the CoRE ecosystem, including OSCORE, where I asked if Group OSC= ORE supports multicasting unencrypted digitally signed messages. Below are = some details of my use case for this capability, and also another use case = from connected vehicles that may be applicable. I have recently been using OSCORE in a project looking at task offloading f= rom IoT devices to edge nodes [2]. As part of this project, a trust model w= as used to assess trust in edge node behaviour. We wanted to incorporate re= putation beliefs from other IoT nodes. As an incentive to not lie about rep= utation beliefs or to tell different agents about different belief values, = we have those beliefs sent in the clear with a digital signature for integr= ity, authentication, and non-repudiation. It is important that the reputati= on message is not sent multiple times and encrypted with a different key ea= ch time, as this potentially allows devices to lie about reputation. My intent was to use Group OSCORE to multicast an unencrypted and digitally= signed message containing reputation, but due to lack of support have inst= ead attached a digital signature inside the CoAP payload. An alternative to= multicasting unencrypted digitally signed messages that would be acceptabl= e, is encrypting the message with a shared secret that all devices are awar= e of and then only sending this message containing reputation information o= nce. I am also aware of a similar requirement in connected vehicles, where CAM (= safety) and DENM (event) messages are broadcasted where the content is unen= crypted but digitally signed. Messages are unencrypted to avoid the time co= st of setting up shared secrets for encryption which may impact on the safe= ty of the sending vehicle and surrounding vehicles. There is some more info= rmation on this at [3]. [1] https://christian.amsuess.com/presentations/2021/summit-core/ [2] https://raw.githubusercontent.com/MBradbury/publications/master/papers/= SAC-DADS2021.pdf [3] https://www.etsi.org/deliver/etsi_en/302600_302699/30263702/01.04.01_60= /en_30263702v010401p.pdf Many thanks, Matthew Bradbury | Lecturer in Cyber Security School of Computing and Communications | Lancaster University --_000_CWXP265MB099943F6D34A935386EFD90780DA9CWXP265MB0999GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I recently watched a talk by Christian Ams=FCss [1] = which included an introduction to the CoRE ecosystem, including OSCORE, whe= re I asked if Group OSCORE supports multicasting unencrypted digitally sign= ed messages. Below are some details of my use case for this capability, and also another use case from connect= ed vehicles that may be applicable.

 

I have recently been using OSCORE in a project looki= ng at task offloading from IoT devices to edge nodes [2]. As part of this p= roject, a trust model was used to assess trust in edge node behaviour. We w= anted to incorporate reputation beliefs from other IoT nodes. As an incentive to not lie about reputation beliefs = or to tell different agents about different belief values, we have those be= liefs sent in the clear with a digital signature for integrity, authenticat= ion, and non-repudiation. It is important that the reputation message is not sent multiple times and encry= pted with a different key each time, as this potentially allows devices to = lie about reputation.

 

My intent was to use Group OSCORE to multicast an un= encrypted and digitally signed message containing reputation, but due to la= ck of support have instead attached a digital signature inside the CoAP pay= load. An alternative to multicasting unencrypted digitally signed messages that would be acceptable, is encrypt= ing the message with a shared secret that all devices are aware of and then= only sending this message containing reputation information once.

 

I am also aware of a similar requirement in conne= cted vehicles, where CAM (safety) and DENM (event) messages are broadcasted= where the content is unencrypted but digitally signed. Messages are unencr= ypted to avoid the time cost of setting up shared secrets for encryption which may impact on the safety of the sen= ding vehicle and surrounding vehicles. There is some more information on th= is at [3].

 

[1] https://christian.amsuess.com/presentations/2021/summit-core/

[2] https://raw.githubusercontent.com/MBradbury/publications/master/papers/SAC-= DADS2021.pdf

[3] https://www.etsi.org/deliver/etsi_en/302600_302699/30263702/01.04.01_60/en_= 30263702v010401p.pdf

 

Many thanks,

 

Matthe= w Bradbury | Lecturer in Cyber Security

School of= Computing and Communications | Lancaster University

 

--_000_CWXP265MB099943F6D34A935386EFD90780DA9CWXP265MB0999GBRP_-- From nobody Wed Sep 15 03:01:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532953A0C0D for ; Wed, 15 Sep 2021 03:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OOvBAJ1O_Ew for ; Wed, 15 Sep 2021 03:01:24 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70072.outbound.protection.outlook.com [40.107.7.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2189D3A0C04 for ; Wed, 15 Sep 2021 03:01:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SRwHD3AzS+BAEtzahMfCEcC0DyOF03bpYIJ4WIGl/UhRfMgFCf1LKv1ZWVprfuRdSEwEa2Pk4gckHHJp+NqAiXD2RTnurha8b6aGI/9buZUgdRMKybdytjieDd8WUfJJahD+iEicNVMD29/pYd5vuN7C9ePSu38Ktm/HxiQHrdsZjLe/yN+aIGYHA2Cr4qQGGAIQ9w+pX5VMxw+G/NzMbV0EAMdcxpxcOSTN4mAcIvoQmlPHsTPxUuAsq50e14Aa/DO72YnZV8jJ6FKWgVl9e/aSHASVZsP0Ux9BLHb3OssuylOZpKFV2xIdbiY3B6oSEV/3KPZOxsdzbZ3IfWMCww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zw/BXEeCnaUb4qlpH67DRJCZnH8tQ8Zpiq+iKXihuz8=; b=kGCV9utG6IRqmI9MVrkPVBvuhnlrkvqqcjK8HU+0kZZBjh0/VUwL5p+5v85syUhul0qEfF6Jlbq42YDEg9VVs98J4oAezfmxvrr+5awAV1nH861a8ufDXvX0DHxbCypdM9IgxATvnSAIRAQgbo1WHiO8YTIdlyFjVdjgGYlikKrstecBOMTmxkbGRHRvNyyLjUU95PjTj2lbIYoGH3QyjrPKyX1ALDaz9DYz6zcTOBMgCYMOzeEhUDV+wHkHsd+e3sqPvs15ioAtQQeVdnBIOkNeziW79NV5HIndDZfD4fz1bG2yYzfrWVRorMX4ZXq45/0o/lGxIdL1JYDwtrDkqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zw/BXEeCnaUb4qlpH67DRJCZnH8tQ8Zpiq+iKXihuz8=; b=VYlXMhbFOB2x0iBxZUL1jt82HIIK6HfN2Q+23W5nnmdsc11yq6l6+wbKxcRMsJgnMKkxpFVDzVnNCVWN+9AT6XD37+cmnTzjCmon7mGirtmZc1IbC2VuZE7yOyPiguYsRvrEZ5Y8YO/l2yz5BvJzsjJpHaTuYWLWPDRQOBsGRkI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.16; Wed, 15 Sep 2021 10:01:19 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172%7]) with mapi id 15.20.4500.019; Wed, 15 Sep 2021 10:01:19 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <04cf2ef3-7d53-2b8a-51ce-eef1e57731d3@ri.se> Message-ID: <8cc6ea05-15a2-1ef5-8666-e35311086bc7@ri.se> Date: Wed, 15 Sep 2021 12:01:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <04cf2ef3-7d53-2b8a-51ce-eef1e57731d3@ri.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s7u4XTp3tSWtTKfm719B21t7Cqtt7j17S" X-ClientProxiedBy: OL1P279CA0071.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:15::22) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (185.236.42.87) by OL1P279CA0071.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:15::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14 via Frontend Transport; Wed, 15 Sep 2021 10:01:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9efa8815-c0fa-47a0-089b-08d9782fc3bb X-MS-TrafficTypeDiagnostic: DB8P189MB1032: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ag4CIxNcteIftDQtLoKGXyEjUuUN8aaKukO3JK6vtHvGYQBjRRH3DySMl1/pvZzW0aWHZhItFFn1SHzrFMndK3CxJoCcLWGcg7l8OhWkFnOo50hvc/qyw2VNF9bTPZmjag/wU+X4JKwkiYxer6bvkhmKYK9EggyXD78O8uDcQoPKVoWnU/2knQtidpm2tOzDEN/tmwNS0nnPgEE14JHf/R6K1Km8GomWtS/mnZwdwvngFuzxMoYMsb3X2qwZSbrQhwU8v2nJCDCVJeyarI+UhqDXK7RCYfjvjGuQ8NcZY+cy0su9m/Nh7xwhawqq+ROOnY5zZF0c3HFGR19vbSCcsZDtKiMOSTFwnOcP7NaPp6xAwTmRyArxkKCaiO0fUEzE1spCRe/cZjLsYYJ2beMO8d8ZBJDAMin3pUU9JBLWZvjLtJEKGKfN6bv0GVPQygqty24RkcMNzcb+VJrxWqN3iFoD8l4TjlJLW3+/S9DQAdiobkPpUftWAvjaM7njDcbHKYtYp19ukXOrxPBjP9Fz1o3ZwfeqccxUVuL7jbOsNxH9X8tTVLkxRr8jdFwYhXsIJOH+rJ13jpuoXomjZyK4+nyUTZ4fU6NN+w7g9PC78ZgfpMGdr4b2/X8vW8jJdcCIJh2S5jQ09agtZraL73btFBHdGT1Lwm5y5AyvdT3wQUUSzKAU+TQqyjmtE3hnhN275O781WR7BCA+P9A9dXvOAJU94gLp6uvtOH88bm0Sgad0T4n0iGgqd1snJJjClr3SVPqY/7iHApngRBFjdvcB0I5mIqAo6J8zfXXy+6ELV/19GfoGdhRnTMNK+G7wjbXx X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(31696002)(16576012)(53546011)(235185007)(83380400001)(6486002)(316002)(8936002)(38100700002)(26005)(956004)(66946007)(21480400003)(66556008)(66476007)(36756003)(5660300002)(6666004)(6916009)(8676002)(2906002)(186003)(86362001)(66574015)(2616005)(966005)(44832011)(33964004)(508600001)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c3h0UVFhb0pibkM5TFVlRlV1R0oyM1dhUW1PUXgwL291cjRVM1FRS1J4V1pP?= =?utf-8?B?YWlnQ2pYQTNEdmNxektQVXQ1RE1OZDdLN0pNcXZLa215YlJxWHVTUTRQczhQ?= =?utf-8?B?SWNrZ3V2VXVvYmU5MTV3b0RzRVkzRHl2VDc4bnVneEJGMEpGK2JlWjNQTmI5?= =?utf-8?B?a25xLzE4YzF3ZTVCa3RpQzBORWVnUGZsbW9sSkRjN2lxM0RpRk1KMEszWlhn?= =?utf-8?B?VGw3V3g5L1F4L25GczlEbHVtbG5uZFl5UW0zNlpNa2VLMjl0QUhtSytKZ3RJ?= =?utf-8?B?b0VrNGRoVVhSUjVyQUxmVzZFdThtdm0va1FzMExYRjJlcVRTM1VWM3RoVWs1?= =?utf-8?B?Z2Z2ZTVhTGtZNXVTdkhmdVlQWXd1RzcrSlo2b2ZCUTF0a0lUeUQyci9uWmFG?= =?utf-8?B?eWxTUnhidzY4WmRlbEZKWTlXR3Z3RGN5d3FRQlJ4L3BoRmRJUThXMzNxSXUx?= =?utf-8?B?NEtxS1A4S1BRR1pDMzY5WlF2MVpJemduaVVVR3I4SDIzajZMbE5CM1VGRFhJ?= =?utf-8?B?RTFZb0gwWXhyTkZwNjVYM2hnMksvTzRuZmEzTmxYWFkvVEFZVGRGeWJkcnNh?= =?utf-8?B?cW5wYXZNWmJiR1NmWUlyWURkUFJSV1BrMkNWNTJnMmw1cHBQSGtsdTFHd0x3?= =?utf-8?B?NEVYbEZGZ055cm00bUFtL1kzNEMvZUZ2QzllN2d3YXJGN1dkWDBudVlXYXhT?= =?utf-8?B?MzlqQ0duSHg5SXVLQlc0WWdoZXhGc3VJOVQ3MW44REpHdUEzQVhzU080TXk4?= =?utf-8?B?SzFEQXgrV1BFK2lFSDV0dGl3aGFFRlNEL2RPOXNhQ1FwRk5EaEc3RXMxOUFC?= =?utf-8?B?VkY4SWZsTXRDQmtqT2k0WjN1TUhxa2hhdHhabTNZRWE3NWdNWVMxNlBLN01v?= =?utf-8?B?Z2xpUzR3U25YSDB4Q256WFY4TFFwbkhZMWx4ZDRUUnhQKzkzdW9kblFTaHhz?= =?utf-8?B?dUtKTDBjT2d5aUFPNks5QXBoVzNLd056YVpsN1RMa3pzZmloR1drYVpFTk03?= =?utf-8?B?dzFWSjVFNGNrMzJkcGRTMExoQkZBUE82ZGVOeUJOY05Uc2lnbmtST2FKc0Jw?= =?utf-8?B?ZUdKcXdYdlpLWUpRM2VCeDNKeDdrcytYUnRrOTBwVi8wdDN3Y2puYTJRaGJY?= =?utf-8?B?SW1seVZScUp6dUIxcHhkdDNjbStkKzZUL0Y0SldGMnBWQjRlKzdXTnNJWnVC?= =?utf-8?B?VnFnN1U3UFRBcXNMMTRWYkxEQXJ4c3ZMd3ZrNkFDc09weGpBRG1XamVXTnJw?= =?utf-8?B?NEE0dklmQllSMEtaaDE2SU5uTnVsNWVjcEZxR3U4ZlZ1bHJCTW10b0VYcHFI?= =?utf-8?B?VGVVNDVpQ093OURvMjFEeEZnczFWZm9tUVNQWDVqdUwrZEo2TUh1NlpJWmRH?= =?utf-8?B?UWtiUlNHR1RHZzB3YllCMmNhMFlYaUtleFc3aTNId0JwSm1pSHBZZFNTRXEy?= =?utf-8?B?b0RHakppeC80VWF6TjVya2EycDNmdVFVT2tkSW9iNHRHaDFHTzkxNWtBaFMx?= =?utf-8?B?SVJyR2NjYm5FYlBZdXAyM25oSmtNYUlOc2hZa2p6WFV1ZXpNcXN6QzVxZ2VS?= =?utf-8?B?aVdLM0MrcmpLWjBjczdteEo4VHo4S3ZHUlpOMXBUbkNvOGVMRTNpd1Vad0hh?= =?utf-8?B?NGFZUGY5MTQ2QTRFbjZWNFVJa2tBTURoM1c5RXJZZnVYSGVCSFc1Rysxa3R3?= =?utf-8?B?QWFGRSt1dmJyc3pVT2lwdWRjUktCUXE5dnA3YlFSbkd0Um5KQ2R4WE1hQ3Z3?= =?utf-8?Q?J/vG+x2D7T58RY3JLbnRwS+Szlflq01V3k3PhNJ?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 9efa8815-c0fa-47a0-089b-08d9782fc3bb X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2021 10:01:19.4416 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5cHU4T5nthJKpYnzi5c8QKYUhg2093UrqFnZ3ErtcQJuoWm8bJbWH46FwnFMCEhTR4wicQKVL9DV5UYBvp0LvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1032 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-09-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 10:01:30 -0000 --s7u4XTp3tSWtTKfm719B21t7Cqtt7j17S Content-Type: multipart/mixed; boundary="bF4KwfAh5OwKDXC7pPyb5do9TCrMplAzR"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <8cc6ea05-15a2-1ef5-8666-e35311086bc7@ri.se> Subject: Re: CoRE WG Virtual Interim 2021-09-15 References: <04cf2ef3-7d53-2b8a-51ce-eef1e57731d3@ri.se> In-Reply-To: <04cf2ef3-7d53-2b8a-51ce-eef1e57731d3@ri.se> --bF4KwfAh5OwKDXC7pPyb5do9TCrMplAzR Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting today,=20 September 15th at 14:00 UTC. The agenda is available at [1]. As per the Datatracker, the meeting will be on Meetecho [2], while=20 minutes will be taken at [3]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-10/session/cor= e [2]=20 https://meetings.conf.meetecho.com/interim/?short=3D086b9da2-6dc7-4de8-89= 69-ef42503ad5cc [3] https://codimd.ietf.org/notes-ietf-interim-2021-core-10-core On 2021-09-08 19:19, Marco Tiloca wrote: > Dear all, > > Just a reminder that we'll have a virtual interim meeting on=20 > Wednesday, September 15th at 14:00 UTC. The agenda is available at [1].= > > As per the Datatracker, the meeting will be on Meetecho [2]. > > Best, > Marco and Jaime > > > [1]=20 > https://datatracker.ietf.org/meeting/interim-2021-core-10/session/core > > [2]=20 > https://meetings.conf.meetecho.com/interim/?short=3D086b9da2-6dc7-4de8-= 8969-ef42503ad5cc > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --bF4KwfAh5OwKDXC7pPyb5do9TCrMplAzR-- --s7u4XTp3tSWtTKfm719B21t7Cqtt7j17S Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmFBxGwFAwAAAAAACgkQ7iZktA5Y2kNg Ywf+JNxrH2tn+E9UeDxNFhzYfI9NblY8l3gtTqr+zCfUCjDb1c8/5PQ0Rq4MMEPjcTA5mf5Uqiyh RZc39Q+9a733J3aXD1nzg6+wc6MnJwzuHdpJekxNS3cc7BFVfdRUDF8s9Cra4Gg5mNMVKa3Hx492 606Ab8oNFfztyv2KOPZyThBrwzbwTowDLI6J1Zg82XmDxnnpKYubxVAV6h1CJw0IqiKcZo+x2ig7 bDrHSFGdceVQNxYmhJLi5meFt/LwTfR6xaO30hably72uutzDxyumoXYqyeAqXgEOYghNdO7r9YA SwByJe2y6od5ovqL7lpQkJG5XaaksZ0F+DEgMYWp4A== =F57k -----END PGP SIGNATURE----- --s7u4XTp3tSWtTKfm719B21t7Cqtt7j17S-- From nobody Wed Sep 15 04:28:08 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2353A13E1; Wed, 15 Sep 2021 04:27: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSvrbSLg1JUa; Wed, 15 Sep 2021 04:27:17 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0582F3A13DA; Wed, 15 Sep 2021 04:27:14 -0700 (PDT) Received: from smtpclient.apple (p548dcf6e.dip0.t-ipconnect.de [84.141.207.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4H8dGl28nrz2xLM; Wed, 15 Sep 2021 13:27:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <163092350360.5169.1299765677300317336@ietfa.amsl.com> Date: Wed, 15 Sep 2021 13:27:10 +0200 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163092350360.5169.1299765677300317336@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] [Last-Call] Genart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 11:27:23 -0000 Hi Christer, thank you for this review. One interesting side note I have from reading the review is: The CoRE WG, which produced this specification, is probably best known = for maintaining the CoAP protocol, but it also has some other = specifications, in particular with respect to data formats. One example is the RFC 6690 link-format, which is well tied-in to the = CoAP discovery mechanisms (RFC 7252 /.well-known/core, CoRE resource = discovery). SenML is the other major data format, with CoRAL coming up =E2=80=94 = both of these formats are really independent of CoAP, but of course have = been designed to fit well with CoAP-based environments. With that additional context, let=E2=80=99s dive in: > Summary: I have reviewed the document. I have one technical comment, = but the > rest is mostly editorial. Related to that, I do think the document = could use > some editorial clean-up, e.g., when it comes to consistent = terminology. I think > it is also good not to assume that the reader knows CoAP, and to make = sure the > appropriate references/explanations are present when CoAP is referred = to. >=20 > Major issues: N/A >=20 > Minor issues: >=20 > Q1 (TECHNICAL): >=20 > What happens if the receiver does not support the "ct" value? Is it a > server-error? If so, what response code is used? I think that should = be > specified. SenML is a data format; the specific protocol using which SenML data are = passed around and how recipients of SenML would react in such a protocol = to data they cannot process is not specified in SenML. However, with = respect to the extension point of adding new field names, Section 4.4 of = RFC 8428 says: The SenML format can be extended with further custom fields. [=E2=80=A6= ] =20 Implementations MUST ignore fields they don't recognize unless that field has a label name that ends with the "_" character, in which case an error MUST be generated. So, as far as this can go while staying protocol-agnostic, the answer to = this question is already fully specified in the base SenML document. > Nits/editorial comments: >=20 > Q2 (EDITORIAL): >=20 > The text should use consistent terminology. See below for a few = examples: >=20 > The Abstract says: >=20 > "The Sensor Measurement Lists (SenML) media type supports multiple > types of values, from numbers to text strings and arbitrary binary > data values. In order to simplify processing of the data values, > this document proposes to specify a new SenML field for indicating > the Content-Format of the data." >=20 > First the text talks about types of values, and then suddenly the > Content-Format of the data. Indeed, the abstract is a rather unfortunate contraction of the text in = the introduction, which states explicitly that this document is about = just one type of data, the =E2=80=9Cvd=E2=80=9D field, i.e. binary data = (see Section 4.2 of RFC 8428). So we fixed the abstract: OLD: In order to simplify processing of the data values, this document = proposes to specify a new SenML field for indicating the Content-Format of the data. NEW: In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for indicating the Content-Format of those binary data values, i.e., their Internet media type including parameters as well as any Content-Coding applied. Now in https://github.com/core-wg/senml-data-ct/commit/cc54f6b > Content-Format is the name of the new field - that is not what you are > indicating. You are using the new field to indicate something. The name of the new field is =E2=80=9Cct=E2=80=9D (or =E2=80=9Cbct=E2=80=9D= for the corresponding base field). =20 It is used to indicate the Content-Format, a precise definition of which = for the purposes of this document follows in Section 2. > Also, "Content-Format" is also used by CoAP, so please check that it = is clear > what is referred to whenever mentioned. >=20 > The text in Section 1 says: >=20 > "To facilitate automatic interpretation it is useful to be able to > indicate an Internet media type and content-coding right in the SenML > Record." >=20 > ...and, the test in Section 7 says: >=20 > "The indication of a media type in the data does not exempt a = consuming > application from properly checking its inputs." >=20 > Now the text suddenly talks about "an Internet media type and = content-coding", > when it earlier (in the Abstract) talked about value of type. Again, the abstract is excessively condensed here, see fix above. > Q3 (EDITORIAL): >=20 > The text says: >=20 > "The CoAP Content-Format (Section 12.3 of [RFC7252]) provides just = this > information" >=20 > I think it would be good with a little introduction on how CoAP is = related to > all this. The abstract of RFC 8428 says: =E2=80=A6 A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. (talking about the SenML media types.) >=20 > Also "provides just this information" probably needs some re-wording. To facilitate automatic interpretation it is useful to be able to indicate an Internet media type and content-coding right in the SenML Record. The CoAP Content-Format (Section 12.3 of [RFC7252]) provides just this information; =E2=80=A6 OK, we expanded this a bit into: OLD: Content-Format ({{Section 12.3 of -coap}}) provides just this information; enclosing a Content-Format number (in this case number 60 = as defined for content-type application/cbor in {{-cbor}}) in the Record is illustrated in {{ex-2}}. All registered CoAP Content-Formats are listed NEW: Content-Format ({{Section 12.3 of -coap}}) provides this information in the form of a single unsigned integer; enclosing a = Content-Format number (in this case number 60 as defined for content-type application/cbor in {{-cbor}}) in the Record is illustrated in {{ex-2}}. All registered CoAP Content-Formatn numbers are = listed Now in https://github.com/core-wg/senml-data-ct/commit/09c105c and https://github.com/core-wg/senml-data-ct/commit/57e4713 > Q4 (EDITORIAL): >=20 > Section 6 contains the ABNF for the new fields. >=20 > Is there a reason you don't define them in the same way as the basic = field is > defined in RFC 8428 (there is no ABNF)? Yes. The field values for the fields in RFC 8428 have a rather simple = structure (see Table 1 in Section 4.3); there was no need to provide = ABNF. A Content-Format-Spec can get complicated; there is no single = standard that can be used to reference the ABNF for it from. So we define it here. > Q5 (EDITORIAL): >=20 > The text in Section 7 says: >=20 > "The indication of a media type in the data does not exempt a = consuming > application from properly checking its inputs." >=20 > I assume that by "its inputs" you refer to "received SenML data". >=20 > Shouldn't properly checking inputs be a generic CoAP security = consideration? It sure is, and this security consideration is maybe stating the = obvious, but from the point of view of examining the change this spec = brings to the security considerations of SenML, this is one of the = significant items. When stating the obvious, there is always a danger that this is = misunderstood to mean something different, but I think the current text = is innocuous here. I have prepared a -05 on the basis of this review and the AD review; = I=E2=80=99ll submit this once my computer has risen up from installing a = mandatory security update... Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 15 06:06:10 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F743A182A; Wed, 15 Sep 2021 06:06:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163171116243.32399.15377911886918102300@ietfa.amsl.com> Date: Wed, 15 Sep 2021 06:06:02 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-data-ct-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 13:06:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : SenML Data Value Content-Format Indication Authors : Ari Keränen Carsten Bormann Filename : draft-ietf-core-senml-data-ct-05.txt Pages : 10 Date : 2021-09-15 Abstract: The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for indicating the Content-Format of those binary data values, i.e., their Internet media type including parameters as well as any Content-Coding applied. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-data-ct-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 16 00:22:39 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929C83A1C52 for ; Thu, 16 Sep 2021 00:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC5gnlNnKItL for ; Thu, 16 Sep 2021 00:22:32 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2086.outbound.protection.outlook.com [40.107.22.86]) (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 F01093A1C4E for ; Thu, 16 Sep 2021 00:22:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dFR5U0/jnS/OI7DJQ1TmKtrmAKZvU+jluEKCA6NII6xWscYJgiN38ANacHXS4vK3Y45zMScJoCTCzdE6CnNCNFFkp0ccLaRwnua4C+JuaLY6KiypSj8OBLwYUB8v9Ofks6UKPU9qnZSeYj+dzaWlk+1E2jdMvTwE3wNudU4f6B8Y7vyxm5s08+moaYakbgCllUxe5P+qeRwj6KV6O0ps6IEOvh3h6La6ofrFAz91xJT+bdTidR0xUVvBJPYXeDQtICOKGYtFwAH4aBMCpkJwysuGv3KYyA/Lylu+eIoKnDfQojqHoGsU5imWGXih8XQIjrn2GbaU6HxgLmfA9/4DGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vkswe4pTrg3pkDny1NpAhHGqb/VY9LDh1RoD5zZM8vo=; b=KmQ3rsSXJRR+hIevUJiQTePSE/OeB0VJtYWoLPRhAWyWy+rBegQBCkrDTA2kMFt5QikLkyYS+8aRGGL/umOuu2ncfAkBusWvpzV2KkiZMNn9SlWwRZw6tkwwmywecNTjyifjlXbB9nGqLb1oBUCdMc3rTLYFfzA3pQIQnFJY13DubMAr/+xSVNFMGNAWYYcX7dh+rUYEz3ceSNrRGT6TlypVYSgsmlO5nrHctMHShEtd1HGtLiao9FQ2nrcg16bXiYsspGS3ajRoYnmbo2fuwXMvpOo/dq+kJYIpC//yaQvy0MCqWjzNVia0NJRxl+dfsboEGR7ZrfKdGBscJthpQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vkswe4pTrg3pkDny1NpAhHGqb/VY9LDh1RoD5zZM8vo=; b=OkAPpXa9gxr0nPA1VUlOP+Su5rRfX30Er3PTP9RI8+k67EGnrrxbvTIej5v6H+AoPq9IRR5hoF7Abdfw+KEpmTa+W7AbewAlo7W/64HNcjkgBBjJxBxVTYCRzIyuffWX67slbbJZJH340xcnN78O2yVqUSn8ESkddwq6/IEpOb0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1515.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a0::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Thu, 16 Sep 2021 07:22:27 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172%7]) with mapi id 15.20.4523.016; Thu, 16 Sep 2021 07:22:27 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Message-ID: Date: Thu, 16 Sep 2021 09:22:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NiFUh2Sq4cq39CaDvSeFRB3DsKivuaPm7" X-ClientProxiedBy: HE1PR05CA0198.eurprd05.prod.outlook.com (2603:10a6:3:f9::22) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.4] (185.219.140.234) by HE1PR05CA0198.eurprd05.prod.outlook.com (2603:10a6:3:f9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14 via Frontend Transport; Thu, 16 Sep 2021 07:22:26 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7803bd95-afdf-4ca7-239b-08d978e2bc40 X-MS-TrafficTypeDiagnostic: DB9P189MB1515: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: m6PE+Tae1QVzOjqIIpN1iXv8CnT/HnJ/RtVFQmgPQq7C9MO5fSf4U6J6HUImFz9xJ/cMUgPNAYAZkxVpn8MajjD+MawvNLHSREda8KJ/+HDwK9FKAH1my9av12UpsSZxAByDOaiNHaDR1rPZw0Zm+SoQcfLT+YdLt1ltYCoAuKhdhvykBdafFJu6tAejOPQ/iZReJwQaS0I7aI/3mf+XK8w/G5iQbfCKo35X8C+oGHQhBryEiTwccm/4ugz1LeHZ6NlAJCwnhYoGw5uWIfPjD2mBbRs6SJ4WGUFsFzBAQiQHCTMTQiElhh24IFVJnQnIbGNLXpwisd/0bAJSsuQr7pJK8TZe3U28IK7jVWfssmvdqXy88Xw4NI/5QH9mbvXmIO55nhTsXqxvcrqeFcN02u5W7o47AUl4liCzzadN5DWcGBXO7ZRD5mMJcJGO76s2zUW8YSryTK+nOYFZUbKvS6VP9f/HmZA5Wp+uDF9khtw3Y78iaLhTuXghagLm11qGOvB16XjSjH7Jo40FSGPBpxZwSxZ+PfdKiK5rOyKF8dq6OJdqTD7vyide64FjrYWiQSycegK50Y3iROyvuAfRgy3wa3CXRxMiTWZZ4cwllHkzkMGYv2w2kEU3JvC+ZqxGhNAmj9ovV4bhQ0fQTLOX7jvesjRihM4iI0hVPnJQI1RgiZM44Zp1rhN96xwvu+7c0mOymOAu33xse2zT5jqFT4IsLJpDcGnfKBhlJ5nGTCjgsGnqP84BiuEEL8P6lxRBgV4ZNLWHurnbQ/hFpmXumdpHm74fF3uTQlDi1IZg3Fr1cmOfg6XrFutjEKafWo58 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39850400004)(396003)(366004)(376002)(6486002)(6666004)(8936002)(966005)(478600001)(38100700002)(235185007)(186003)(2906002)(44832011)(33964004)(86362001)(26005)(5660300002)(31686004)(31696002)(956004)(2616005)(66476007)(6916009)(66946007)(66556008)(316002)(30864003)(36756003)(8676002)(21480400003)(66574015)(53546011)(83380400001)(16576012)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cjhyWXMzeDlzakF6ckxlZWlDd0hhUjhmQnJaei9Xd2RFZU40alJ3akxLZk9B?= =?utf-8?B?ZWxUOW9JcStlKzlrU2VtOGdBb2tUOGJERlczR2l6Slhyb1BYWlZuSDFJTVBU?= =?utf-8?B?Z1ZHc2hEUFVGZlJJS3p2LzRkVFhJNVgzWkNjdlNpd1JheW1pcnFCS2MrT2x3?= =?utf-8?B?cVhQOEJwOTU3UmJXclFHb0swbmF4V2QyN29OSWVZb1ZZVzUrdmdqMFdNWDVS?= =?utf-8?B?OHFsOWRQRm1PSStuUkdyV1ZneENrUUlQc3gvU0QrNzErNzcvdXF2YmZycWJv?= =?utf-8?B?Z3NwK1NRaVFJT2RGZWtOdjBoeFppYitFSTFjakMxSmdCR1ZHR2pkS1pLWldK?= =?utf-8?B?ZElqOEhlN05JVk1sZVRwdUlwK2ZPNDdzbnBIaVIyRWd3WGtNZ3BlRktBV0w0?= =?utf-8?B?bjA0RzhXWERJTlFFeFdFMWNUNzZYbEZkOUt6eTVPMTVOWU8weEZmVkJjQ0pC?= =?utf-8?B?Nm1DVHhCQkpGamR6T0dJbjYxRWQ5ZlFxSmRWSGd5OTE4MVFPMjczcnN0Rlgw?= =?utf-8?B?K01kL0R1Tk5QNDVKdEJUT21xZkltRHNqOFdUdXhrNGpTSzBHQnhhZU9INWM1?= =?utf-8?B?cEhNdnBsaW9saHRKV2pMZW4rUno2VFRBZVlOcEdWTlRzZUx1VFQwakhRaEtP?= =?utf-8?B?dkNwWG44cHplWUpHS3c5b1hVMUhVaEdJYnpadVBzZmFTQWt1Q1p2V0Q5U0NV?= =?utf-8?B?MXZ0ZUhubVJNT0F0OHUvNTdFRnlJeTF5Q2ZrVEVsNlJrc3kzOGpGUDkveXBO?= =?utf-8?B?bS80TVJpVzRrbXU0SjB3ZFNqanZFSmVmakhPSzFUTnNkRGtJSDRiSjJ2OEJh?= =?utf-8?B?Z0pvUkhXci8yNTlWS3ltZXkrQXR0UVR4YUtSc0E2bnYyQUhMUGR3Y0dtWHJv?= =?utf-8?B?a2hDVktOV09UUlhEWW5iYkNtZTNsOE1wQWpabjlEWFlWWGZxcWZvUHBZMDU3?= =?utf-8?B?SmQyUG1tNFk1Tm5jRnhvLytEVWpPRllxSHdHQlhyVDBjQmU0cFBUWTNlUDJn?= =?utf-8?B?bVNEYWdYNEErSTZLZlZUbEVBZDhoUGk1d2U4Zk9rU2JiWXRNNWVyQmRNTklw?= =?utf-8?B?VzhYOGxRNzI4T1dGeUhONktlRG0vY2VvaHdiNk1lWGF6aUF6RWh0R2p0SDlC?= =?utf-8?B?N1M2ak5rdGVHMUtWNUJFUWNSWlNjenlGelBHQXBqeUVobUk0V1ZnZEVNZDRK?= =?utf-8?B?YTFWK1o5UE9CMERvaEM5eW5CQ2dERTRoRjNRUU55bHhMVDV5REJFUjFQSjh6?= =?utf-8?B?UDlSakprbGsrWDUwcUVDUlk1anhycWxnVjEzZFErTlJNNnE3UmUzQkxhSk9h?= =?utf-8?B?YmJNTjFJb3ExL01MdHhEYXYzeTRpeWpNRUl5azVha0xZVDYrTjEvUkNXOUNL?= =?utf-8?B?OEVSTVE1SldIWjhWanI4clc0ZGFPSjJGUElGaHBVc0dhdlZsSmM1dHArTURV?= =?utf-8?B?dmFhUjVMWUlRdC9OMkhHY0wzM3B6eGNJQzhDa21zalIvSmI5UllUM3dnVVM5?= =?utf-8?B?VkhCWXoyaEhnUGVxV09TY2lQZ0xYb3ZyWEJnaFdXSjlGbnIzM2RoNXk0U1Bu?= =?utf-8?B?OWMzQVBhaWpTZjNXdUFhR216dnQvSzMyMVlVL1Fhc2Y3SE5GczFYclJtNTYr?= =?utf-8?B?clhVL0o0bjJianoxQ2hBY3dsQ2Z2WjJjNHBuN0JNOEVlT3NpLzVCMGJjemhu?= =?utf-8?B?R2VIRDlPSFFQdzh0Z2d0SEJ6d2dKSy8vV1BkdXBMZlBoWGIrQUhTTHUrUDF4?= =?utf-8?Q?oazU4CszXjDtavD5lMtJEpwPn3ErT+rRFkc/VI9?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 7803bd95-afdf-4ca7-239b-08d978e2bc40 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2021 07:22:26.9950 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: T+cv+h7VRN+dkD91nReSHR68DkssRUrNLmgyW/tlyQMhvHhcWPHrKt7MQVOokgDK7PGs+VfJ/FwOqIsWpWn3Lg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1515 Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 07:22:38 -0000 --NiFUh2Sq4cq39CaDvSeFRB3DsKivuaPm7 Content-Type: multipart/mixed; boundary="LUiepe7mswSQHmKX6FlFJ4jBFXADARmD2"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: CoRE rechartering: proposed text References: In-Reply-To: --LUiepe7mswSQHmKX6FlFJ4jBFXADARmD2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, During the 2021-09-15 interim meeting [1], we had a good first=20 discussion on the proposed new text for the possible updated charter. As mentioned at the meeting, please take some time to review the new=20 text and possibly provide input/comments. Even in case you are just fine = with the text "as is", it is valuable feedback to say so. Please, provide your comments and proposed changes: - In this mail thread, where the first message [2] also includes the new = proposed charter text; and/or - In this CodiMD document [3], where editing requires to be logged in=20 with your Datatracker account. The new charter text is also available on our Github at [4], together=20 with a diff from the present charter text at [5]. Thanks, Marco and Jaime [1]=20 https://datatracker.ietf.org/doc/minutes-interim-2021-core-10-20210915160= 0/ [2] https://mailarchive.ietf.org/arch/msg/core/haBtninO85UjsyqASeeO0FFr_W= o/ [3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both [4]=20 https://github.com/core-wg/core-wg.github.io/blob/master/core-charter.txt= [5]=20 https://github.com/core-wg/core-wg.github.io/commit/133861a92ef62a2130427= 521455fb58bce23aa3e?branch=3D133861a92ef62a2130427521455fb58bce23aa3e&dif= f=3Dsplit On 2021-09-08 19:34, Marco Tiloca wrote: > Hi all, > > During the CoRE session at IETF 111 [1][2], it was proposed to update=20 > our charter, for better reflecting the current status of our work.=20 > This is also helpful for the IESG review processing and for newcomers=20 > to more easily understand the WG scope and direction. > > As promised, the Chairs have prepared an initial proposed text for the = > WG to consider. Please, find the proposed text at the end of this mail = > as well as in the CodiMD at [3]. > > With that as starting point, this mail starts a discussion on the new=20 > charter text. Please, provide your comments and proposed changes here=20 > on the mailing list or in the CodiMD at [3] (editing requires to be=20 > logged in). > > Best, > Marco and Jaime > > > [1] https://datatracker.ietf.org/doc/minutes-111-core/ > > [2]=20 > https://datatracker.ietf.org/meeting/111/materials/slides-111-core-chai= rs-slides-00.pdf > > [3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The CoRE Working Group (WG) provides a framework for resource-oriented = > applications intended to run on constrained IP networks. A constrained = > IP network has limited packet sizes, may exhibit a high degree of=20 > packet loss, and may have a substantial number of devices that may be=20 > powered off at any point in time but periodically "wake up" for brief=20 > periods of time. These networks and the nodes within them are=20 > characterized by severe limits on throughput, available power, and=20 > particularly on the complexity that can be supported with limited code = > size and limited RAM per node [RFC 7228]. More generally, we speak of=20 > constrained node networks whenever at least some of the nodes and=20 > networks involved exhibit these characteristics. Low-Power Wireless=20 > Personal Area Networks (LoWPANs) are an example of this type of=20 > network. Constrained networks can occur as part of home and building=20 > automation, energy management, and the Internet of Things. > > The CoRE WG will define a framework for a limited class of=20 > applications: those that deal with the manipulation of simple=20 > resources on constrained networks. This includes applications to=20 > monitor simple sensors (e.g., temperature sensors, light sensors, and=20 > power meters), to control actuators (e.g., light switches, heating=20 > controllers, and door locks), and to manage devices. > > The general architecture targeted by the CoRE WG framework consists of = > nodes on the constrained network, called Devices, that are responsible = > for one or more Resources that may represent sensors, actuators,=20 > combinations of values, and/or other information. Devices send=20 > messages to change and query resources on other Devices. A Device can=20 > send notifications about changed resource values to Devices that have=20 > expressed their interest to receive notification about changes. A=20 > Device can also publish or be queried about its resources. Typically,=20 > a single physical host on the network would have just one Device but a = > host might represent multiple logical Devices. The specific=20 > terminology to be used here is to be decided by the working group. > > As part of the framework for building these applications, the CoRE WG=20 > has defined the Constrained Application Protocol (CoAP) for the=20 > manipulation of Resources on a Device. CoAP is designed for use=20 > between Devices on the same constrained network, between Devices and=20 > general nodes on the Internet, and between Devices on different=20 > constrained networks both joined by an internet. CoAP is also being=20 > used via other mechanisms, such as SMS on mobile communication=20 > networks. CoAP targets the type of operating environments defined in=20 > the ROLL and 6Lo WGs, which have additional constraints compared to=20 > normal IP networks. Nevertheless, the CoAP protocol also operates over = > traditional IP networks. > > There also may be intermediary nodes acting as proxies that possibly=20 > also interconnect between other Internet protocols and the Devices=20 > using the CoAP protocol. It is worth noting that a proxy does not have = > to occur at the boundary between the constrained network and the more=20 > general network, but can be deployed at various locations in the=20 > less-constrained network. The CoRE WG will continue to evolve the=20 > support of proxies for CoAP to increase their practical applicability. > > CoAP supports various forms of "caching". Beyond the benefits of=20 > caching already well known from REST, caching can be used to increase=20 > energy savings of low-power nodes by allowing them to be normally-off=20 > [RFC 7228]. For example, a temperature sensor might wake up every five = > minutes and send the current temperature to a proxy that has expressed = > interest in notifications. When the proxy receives a request over CoAP = > or HTTP for that temperature resource, it can respond with the last=20 > notified value, instead of trying to query the Device which may not be = > reachable at this time. The CoRE WG will continue to evolve this model = > to increase its practical applicability. > > The CoRE WG will perform maintenance as well as possible updating and=20 > complementing on its first four standards-track specifications as=20 > required: > > - RFC 6690 > - RFC 7252 > - RFC 7641 > - RFC 7959 > > The CoRE WG will continue to evolve the support for CoAP group=20 > communication originally developed in the Experimental RFC 7390. The=20 > CoRE WG will not develop a solution for reliable multicast delivery of = > CoAP messages, which will remain Non-Confirmable when sent over=20 > multicast. > > RFC 7252 defines a basic HTTP mapping for CoAP, which was further=20 > elaborated in RFC 8075. This mapping will be evolved and supported by=20 > further documents as required. > > CoAP was initially designed to work over UDP and DTLS. Later on,=20 > mapping were defined between CoAP and IP-based transports, especially=20 > TCP and WebSockets including a secure version over TLS (RFC 8323). The = > CoRE WG will continue defining transport mappings for alternative=20 > transports as required, both IP-based and non IP-based (e.g., SMS and=20 > Bluetooth), working with the Security Area on potentially addressing=20 > the security gap. This includes defining appropriate URI schemes.=20 > Continued compatibility with CoAP over SMS as defined in OMA=20 > Lightweight Machine-to-Machine (LwM2M) will be considered.=20 > Furthermore, the CoRE WG will work on solutions to facilitate the=20 > signaling of transports available to a Device. > > The CoRE WG will continue and complete its work on the CoRE Resource=20 > Directory (draft-ietf-core-resource-directory), as already partially=20 > adopted by OMA LwM2M, and will perform maintenance as well as possible = > updating, complementing and specification of relevant uses as=20 > required. A primary related consideration is the interoperability with = > DNS-SD and the work of the dnssd WG. The use of CoAP to transport DNS=20 > queries and responses will also be investigated. Furthermore, the CoRE = > WG will also continue and complete its work on enabling broker-based=20 > publish-subscribe-style communication over CoAP=20 > (draft-ietf-core-coap-pubsub). > > The CoRE WG will work on related data formats, such as alternative=20 > representations of RFC 6690 link format and RFC 7390 group=20 > communication information. Also, the CoRE WG will complete its work on = > Constrained Resource Identifiers for serializing URI components in=20 > CBOR (draft-ietf-core-href). Furthermore, the CoRE WG will develop=20 > CoRAL (draft-ietf-core-coral), a constrained RESTful application=20 > language suitable also for constrained node networks, which comprises=20 > an information model and an interaction model, and is intended for=20 > driving automated software agents that navigate a Web application. The = > CoRE WG will complete the Sensor Measurement Lists (SenML) set of=20 > specifications, again with consideration to its adoption in OMA LwM2M. > > Besides continuing to examine operational and manageability aspects of = > the CoAP protocol itself, the CoRE WG will also complete the work on=20 > RESTCONF-style management functions available via CoAP that are=20 > appropriate for constrained node networks (draft-ietf-core-yang-cbor,=20 > draft-ietf-core-sid, draft-ietf-core-comi,=20 > draft-ietf-core-yang-library). This requires very close coordination=20 > with NETCONF and other operations and management WGs. YANG data models = > are used for manageability. Note that the YANG modeling language is=20 > not a target for change in this process, although additional=20 > mechanisms that support YANG modules may be employed in specific cases = > where significant performance gains are both attainable and required.=20 > The CoRE WG will continue to consider the OMA LwM2M management=20 > functions as a well-accepted alternative form of management and=20 > provide support at the CoAP protocol level where required. > > The CoRE WG originally selected DTLS as the basis for the=20 > communication security in CoAP. The CoRE WG will work with the TLS WG=20 > on the efficiency of this solution. The preferred cipher suites will=20 > evolve in cooperation with the TLS WG and CFRG. > > The CoRE WG considered object security as originally defined in JOSE=20 > and later adapted to the constrained node network requirements in=20 > COSE. Building on that, the CoRE WG has defined the Object Security=20 > for Constrained RESTful Environments (OSCORE) protocol (RFC 8613) for=20 > protecting CoAP messages at the application layer using COSE. The CoRE = > WG will complete the work on the Group OSCORE protocol=20 > (draft-ietf-core-oscore-groupcomm) that enables OSCORE-protection of=20 > CoAP messages in group communication environments. Also, the CoRE WG=20 > will complete an optimization-oriented profiling of the EDHOC protocol = > developed in the LAKE WG, when this is used to establish security=20 > material for OSCORE (draft-ietf-core-oscore-edhoc). Furthermore, the=20 > CoRE WG will perform maintenance as well as possible updating and=20 > complementing of the (Group) OSCORE documents above as required. > > The ACE WG is expected to provide solutions on authentication and=20 > authorization that may need complementary elements on the CoRE side. > > The CoRE WG will coordinate on requirements from many organizations=20 > and SDOs. The CoRE WG will closely coordinate with other IETF WGs,=20 > particularly of the constrained node networks cluster (6Lo, 6TiSCH,=20 > LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT), and with further=20 > appropriate groups in the IETF OPS and Security Areas. Work on these=20 > subjects, as well as on data/interaction models and design patterns=20 > (including follow-up work around the CoRE Interfaces draft) will=20 > additionally benefit from close cooperation with the Thing-to-Thing=20 > Research Group. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --LUiepe7mswSQHmKX6FlFJ4jBFXADARmD2-- --NiFUh2Sq4cq39CaDvSeFRB3DsKivuaPm7 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmFC8KoFAwAAAAAACgkQ7iZktA5Y2kP3 qwf+MAPOj4BF/WaMTwSzLn81UM2+LrNr6SDLFMBasxa7Y/86C3sRWRlDk0aWca+UEzvBaZt04c4d 5nuEiTeLsohwiVFCaayq/HLGl7B/29cf+Z5Ww79caQwPDlLn62xztMoPy6cB6wFzgFDNVRSay6cm zJg8w+TP8Bc2cnNrxI+N2DbJhkJX5DYMQQwG0M09/V2pEh8l+GpxZ4+TxSvMqakRQTGqaEtJwKOX n0+sJG2p+XzW4ljUHNN+BjSnjx/Ah3xSeLqTlbllnFkYhGgAhH8RtlrOCoYHTqyAcxD8yWRjT2yA djzmYHDjZWL2IcPyGmAGOXiQUNxinMxJl381P+83ZA== =hTj7 -----END PGP SIGNATURE----- --NiFUh2Sq4cq39CaDvSeFRB3DsKivuaPm7-- From nobody Thu Sep 16 02:50:10 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D633A2276; Thu, 16 Sep 2021 02:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAeL0ye6V7DO; Thu, 16 Sep 2021 02:50:02 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00069.outbound.protection.outlook.com [40.107.0.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 E337C3A2272; Thu, 16 Sep 2021 02:50:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ARpkJYN4cqnSgtkfFKL+j6IgmNhzLHfbXQeAQlM2q/10xMHujYnQh5Fiur7gy/aOnySlixowptkGYEVnnhD82+dvDR3bS1BFqktR2VZumpe7gGbI2l0Y+iMUBVW+BkY6LqykvldS1ZGeFIZgweWRwmWo+YjrLDd51FJM+uTuNr2nHsjzqKVgpASgsUubVqeXfmQ/B+NaKXGFuowRo0wDeX2qExt1Ywsy59oRuK04fFOl8RDgQty7JFdxAmTtGUX+K7QhWt5dw+qyIhXZLuQmMbptdee8DdR1CSHjviVfN4XBbE2A+RxX3zQARmrL9GOFhxRlSEdNy58vqISh4eV8fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TAT16GPlYOO+7w+q5IMDJrA6vz5eRWbh6XG/tVU985w=; b=hrV68JvmLYjS+CzOaa5U2xqDDAK8uZ8x/ecl75im/Fdt7mSgV0lmazaJXqFy5Xh0AvwWSjDnAMPz+rHZDfo1e0TeRpaJwXMo7/7JNdccwxkhF3SATsi4ur32glcrnG2DhivuRM10kBCDoKI9ifR5kYiqn+paX5eayyLETFLmu+yAZox/N6Oe6Py3eVHyxqxq0canErrimrbQXurhYpa2Rj/H7HhmTByn1IxknGE5wHDR9wK55gz/AITYSQ6TIxlobH3EExCrCVyaW5V8fMZgn/B9P5DvJCbcR0BdruBD6taWxLFI3yJn5L2uBojDF5j8dUfQjOpktrSd3Kz7Z8xuQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TAT16GPlYOO+7w+q5IMDJrA6vz5eRWbh6XG/tVU985w=; b=iiHoGs1e6TyOOEs6ox+phGxrH+k81IQFDI+D7umz97cz2lhIQd8UwhkcdvpenSDSx1Sdxw9l2PNZIJYd7yoXoi9sfAL0Yl62MQ9soWBiE3l5AwmQ67uce9qbisLQrTrVg+RKR3CWEooFBT8+6thg3yLeBx+ArtUjz2xcHQGyJYQ= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0701MB2267.eurprd07.prod.outlook.com (2603:10a6:3:2a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.9; Thu, 16 Sep 2021 09:49:54 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::49b7:5cc:5aeb:fb2a]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::49b7:5cc:5aeb:fb2a%4]) with mapi id 15.20.4523.014; Thu, 16 Sep 2021 09:49:55 +0000 From: Christer Holmberg To: Carsten Bormann CC: "gen-art@ietf.org" , "last-call@ietf.org" , "draft-ietf-core-senml-data-ct.all@ietf.org" , "core@ietf.org" Thread-Topic: [Last-Call] Genart last call review of draft-ietf-core-senml-data-ct-04 Thread-Index: AQHXqiSnF9F3eGD7I0OSQbkNtCY/T6umZn3Q Date: Thu, 16 Sep 2021 09:49:54 +0000 Message-ID: References: <163092350360.5169.1299765677300317336@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dde6b9db-a616-4ece-dd3a-08d978f75654 x-ms-traffictypediagnostic: HE1PR0701MB2267: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NTHmD8bo4SUji70Eq7L5j84paoIJaUeqFIB7tFp2ifwS60783hWP205uxWtoHEYqzKCGSFAZkR8KnKLFOKUbiu5MMxlJ5XRZv0jzrSr9isNPPV5gEnhPYOEB+eGx+gSMkjN1RtnEPEbi1lC4OHfbgcyCpNx4fGpQI0sIYuAoIgSHY1YKtyC2pSCqeMXGpM8bBF9XOI3E2roKH64Du2MtkfKEzCkYER8xZfjqi7zY+mkssw0+Bakg3VtMP4NqU/SMIX0svyNMFgKW2g5Sr8HpTJYVMOfqbGaM5BiffJq7MrdwJTjuMgAoVKy3kEjPxRF6WKXwP711n/87dyXLygE4fMTVMDxodBX2iJCWkYsnUQJrQMN72kK1oYB3kv/4Inl8KJeyDIuzO2axRepWe42n2nz/NybJ5fxK07baBcWJLA0v70sWuOXSHuAGZcYCwR7a7gG6Hft+/LcYEMHSd9qr1XwjFp1sSjsgUjbCQ1xlDc/Wok1U1FvKFXJrqzHFW5cW2PZ+jFdnftJUJvThXHDoIdCKJLbtu+GFjdimn5/1TI/pxQkK0qeYO/LWmBjibbdVwRrs3/j2q1oZshcLRMsILZPwmNvEj+SxItBK87icRkbLHcSbAVL1xBRZ4O6AyOFf1qOjfO8zk+97HGkP94oGyNfVaDFCuxMqbKcLqk1bohfF5uDE76Yaw5gFxuwPolbFIC1QWha0Oi4I06rvIUHKAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(366004)(136003)(376002)(66946007)(38070700005)(478600001)(33656002)(66476007)(66446008)(71200400001)(26005)(76116006)(5660300002)(122000001)(38100700002)(64756008)(2906002)(52536014)(9686003)(55016002)(7696005)(8936002)(6916009)(44832011)(6506007)(54906003)(83380400001)(316002)(66574015)(86362001)(186003)(4326008)(8676002)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MDA0NTJha3JqMmROOExMczhVSVd6eGQ1SDZaOGpISzBoMlNzbGkyMjdGUVFq?= =?utf-8?B?eGkvOW5IWGxlUjlSV1hVMmIwdUZpaDRpVmN1eXY0WmxMbEFudEFWTE1XUnJw?= =?utf-8?B?bkZOMnpJQkN0aHJrTFdMRTdhOTNhQlk1dXpERThreVNTa2lwUlVOanJjZTRy?= =?utf-8?B?Q09PTUN1R0doOUNmZm4rT3ZZRFNBaWFDL1RJS1NSU1JOeXQ1ZkVNVElKbkxn?= =?utf-8?B?aldOY3A0blVYU2NYNG1GK3BROTNOTlJzamFwM3JKT09uQXNMNjFWQkRSRDYv?= =?utf-8?B?UlNpeTZKdTZMTDJINHJFcGdROFlqbGVraGZOQU5CNWRqS0phYm4zbmFnYkZV?= =?utf-8?B?alF6bUw1aUNvTk9PT2IzZytIWnZ4NlVUdjBnOVFEZnpmL2cvTUpnQ3g2cmQ3?= =?utf-8?B?S1Zhd1BZRG1YaHpWbHBnQlVpMDROMEhlcFp6MkRKTXo5TlFSWThvWEkzdmlK?= =?utf-8?B?Q0h6OTBDMytTYXpEQjJNN29RNkR6ZGp4L0x5dFVrNUZwdHlCRTVSZ3NIc0Vp?= =?utf-8?B?YmNta044ZlZmbElMenNCYkVHYTRYRC9RYjFaWlVmOGJvUEIzMmdpS1RidVE3?= =?utf-8?B?TmhSR3hLME1kdllka1BRN1JJVUZLTkRGN0VVNmkrVlBJU2FXVWRWUmhUeXl0?= =?utf-8?B?c1JsYUc2TDdscXZYUmM2V2hNOHU2VDQ3MUVOanhTdDR5bDZDL1VFVzNidUt3?= =?utf-8?B?UzJHOCtjT2YvNEswQWlDU0s2YVV4ZXVhM2tTU1NGVU1Sbi8wU08vSk9OTm5s?= =?utf-8?B?MVhVR0VXTzFONEswRVFhWkVvS055TXBMbFZGa2k3T0NkbUphUHduY01jQVVZ?= =?utf-8?B?VmNMNTFFeDk5SWlNWEpXMlE1eWtJc3pFUWtuNS9XRzlydzBFVzNhVzBCbnla?= =?utf-8?B?bTUvZUswd3BOTnBYbkNxbUtuVTY5dzhUYVY3TVVOTkVuTldGeXFRcGlaOGJa?= =?utf-8?B?N01CQXMyZHBLRGI5OHBjV0MrUWJMNnlQbVZ5MDFNalpESEMzZ1hkQVNlUjNt?= =?utf-8?B?ZVRTRG1XQ0NOeHZaSXlScSs1N2VtS2c5UTV6N3pkWlNnNVlJZnJEdWh6NlBy?= =?utf-8?B?OVhGYlBSZlY2ckpJK0FaTy9uK2tIUHBJcUdOWmRYZEhJU01PZEZ4Q0o4bmNt?= =?utf-8?B?VEt3RlhQSmR4SHgzL2c2OUZWSSsvSllsMXdYUDdmQ2Zyb3BBTG1DRFcrN1N5?= =?utf-8?B?eUdnMWtFQ0FiSU1FZmhpZk8zWmVHZldyVFBXakkvcmhhU201bkkrUGhibjNC?= =?utf-8?B?TXVwckZGVVZVcVlGQXdmWHhGemx0NzJhd0VGbVpaMWF2NXhtYWkyUVB3WUho?= =?utf-8?B?ZFpmMUV2SlpnODhHaDRFVkRXdEJLOTRWNzJ4RlcxNTV6TllZMWtzb3loUzRy?= =?utf-8?B?VWFSYWZobXVDUzhkN2lleGVVUG9CK1JPcTdQc0pZa3JJbzdSRWxPTUM4NGI5?= =?utf-8?B?cHl1c2pkakNJSzNBOEtUSXczS25DQnRHSVBUMmlQa0V4Tmh0UnhIV2Yvb25m?= =?utf-8?B?d2RBN0tpSlY1WEttL2VqaHByQVFGNUpHSC8wSVZUS3U1dmFxV0ZXdnlRVzBV?= =?utf-8?B?VE1pWnBXTkJHS0tYdzRRYW15UkUyOUpqSjVqa0tJSzZIeGV0RERTRXNOMXg2?= =?utf-8?B?cTZBOGQ4S0U5dVdwU2FqQXdmWmFEWFZxU3hTaHk0Z05DdjREVG9TdTF0ZDBa?= =?utf-8?B?ZHpObG9tajNLQ1JWc2VVUk4rb1ErbUFCWjlBbTJwbW5MbXZ3UUNUQkJuK2Zv?= =?utf-8?Q?6Wc8bjN9nGXAX9I0MijAmtaRhZdh7YClQtdJEKE?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dde6b9db-a616-4ece-dd3a-08d978f75654 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2021 09:49:54.8794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XkuF0pPIueCdTyqibT5h45vwm+WlGk10ih2NW74BNVEAw1AvXVziGNR1+SxszUP88XSJEgMbvdpDeHw2q/LZGEOA4k3MXHwyDzXEm0xSJvE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2267 Archived-At: Subject: Re: [core] [Last-Call] Genart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 09:50:07 -0000 SGksDQoNCkkgaGF2ZSByZW1vdmVkIHRoZSBpc3N1ZXMgd2hlcmUgSSBhbSBvaywgd2l0aCBubyBm dXJ0aGVyIGNvbW1lbnRzLCB3aXRoIHRoZSByZXBseSB5b3UgZ2F2ZSA6KQ0KDQo+T25lIGludGVy ZXN0aW5nIHNpZGUgbm90ZSBJIGhhdmUgZnJvbSByZWFkaW5nIHRoZSByZXZpZXcgaXM6DQo+VGhl IENvUkUgV0csIHdoaWNoIHByb2R1Y2VkIHRoaXMgc3BlY2lmaWNhdGlvbiwgaXMgcHJvYmFibHkg YmVzdCBrbm93biBmb3IgbWFpbnRhaW5pbmcgdGhlIENvQVAgcHJvdG9jb2wsIGJ1dCBpdCBhbHNv IGhhcyBzb21lIG90aGVyIHNwZWNpZmljYXRpb25zLCBpbiBwYXJ0aWN1bGFyIHdpdGggcmVzcGVj dCB0byBkYXRhIGZvcm1hdHMuDQo+DQo+T25lIGV4YW1wbGUgaXMgdGhlIFJGQyA2NjkwIGxpbmst Zm9ybWF0LCB3aGljaCBpcyB3ZWxsIHRpZWQtaW4gdG8gdGhlIENvQVAgZGlzY292ZXJ5IG1lY2hh bmlzbXMgKFJGQyA3MjUyIC8ud2VsbC1rbm93bi9jb3JlLCBDb1JFIHJlc291cmNlIGRpc2NvdmVy eSkuDQo+DQo+U2VuTUwgaXMgdGhlIG90aGVyIG1ham9yIGRhdGEgZm9ybWF0LCB3aXRoIENvUkFM IGNvbWluZyB1cCDigJQgYm90aCBvZiB0aGVzZSBmb3JtYXRzIGFyZSByZWFsbHkgaW5kZXBlbmRl bnQgb2YgQ29BUCwgYnV0IG9mIGNvdXJzZSBoYXZlIGJlZW4gZGVzaWduZWQgdG8gZml0IHdlbGwg d2l0aCBDb0FQLWJhc2VkIGVudmlyb25tZW50cy4NCg0KU3VyZSwgYW5kIHRoZXJlIGlzIG5vdGhp bmcgd3Jvbmcgd2l0aCBkZXNpZ25pbmcgd2l0aCBzb21lIHNwZWNpZmljIHVzYWdlIGluIG1pbmQu DQoNCkJ1dCwgSSBkb24ndCB0aGluayB0aGUgcmVhZGVyIHNob3VsZCBoYXZlIHRvIGtub3cgQ29B UCBpbiBvcmRlciB0byB1bmRlcnN0YW5kIFNlbk1MLg0KDQotLS0NCg0KPj5XaXRoIHRoYXQgYWRk aXRpb25hbCBjb250ZXh0LCBsZXTigJlzIGRpdmUgaW46DQo+Pg0KPj4gU3VtbWFyeTogSSBoYXZl IHJldmlld2VkIHRoZSBkb2N1bWVudC4gSSBoYXZlIG9uZSB0ZWNobmljYWwgY29tbWVudCwgDQo+ PiBidXQgdGhlIHJlc3QgaXMgbW9zdGx5IGVkaXRvcmlhbC4gUmVsYXRlZCB0byB0aGF0LCBJIGRv IHRoaW5rIHRoZSANCj4+IGRvY3VtZW50IGNvdWxkIHVzZSBzb21lIGVkaXRvcmlhbCBjbGVhbi11 cCwgZS5nLiwgd2hlbiBpdCBjb21lcyB0byANCj4+IGNvbnNpc3RlbnQgdGVybWlub2xvZ3kuIEkg dGhpbmsgaXQgaXMgYWxzbyBnb29kIG5vdCB0byBhc3N1bWUgdGhhdCB0aGUgDQo+PiByZWFkZXIg a25vd3MgQ29BUCwgYW5kIHRvIG1ha2Ugc3VyZSB0aGUgYXBwcm9wcmlhdGUgcmVmZXJlbmNlcy9l eHBsYW5hdGlvbnMgYXJlIHByZXNlbnQgd2hlbiBDb0FQIGlzIHJlZmVycmVkIHRvLg0KPj4gDQo+ PiBNYWpvciBpc3N1ZXM6IE4vQQ0KPj4gDQo+PiBNaW5vciBpc3N1ZXM6DQo+PiANCj4+IFExIChU RUNITklDQUwpOg0KPj4gDQo+PiBXaGF0IGhhcHBlbnMgaWYgdGhlIHJlY2VpdmVyIGRvZXMgbm90 IHN1cHBvcnQgdGhlICJjdCIgdmFsdWU/IElzIGl0IGEgDQo+PiBzZXJ2ZXItZXJyb3I/IElmIHNv LCB3aGF0IHJlc3BvbnNlIGNvZGUgaXMgdXNlZD8gSSB0aGluayB0aGF0IHNob3VsZCANCj4+IGJl IHNwZWNpZmllZC4NCj4NCj4gU2VuTUwgaXMgYSBkYXRhIGZvcm1hdDsgdGhlIHNwZWNpZmljIHBy b3RvY29sIHVzaW5nIHdoaWNoIFNlbk1MIGRhdGEgYXJlIHBhc3NlZCBhcm91bmQgYW5kIGhvdyBy ZWNpcGllbnRzIG9mIFNlbk1MIHdvdWxkIHJlYWN0IGluIHN1Y2ggYSBwcm90b2NvbCB0byBkYXRh IHRoZXkNCj4gY2Fubm90IHByb2Nlc3MgaXMgbm90IHNwZWNpZmllZCBpbiBTZW5NTC4gIEhvd2V2 ZXIsIHdpdGggcmVzcGVjdCB0byB0aGUgZXh0ZW5zaW9uIHBvaW50IG9mIGFkZGluZyBuZXcgZmll bGQgbmFtZXMsIFNlY3Rpb24gNC40IG9mIFJGQyA4NDI4IHNheXM6DQo+DQo+ICBUaGUgU2VuTUwg Zm9ybWF0IGNhbiBiZSBleHRlbmRlZCB3aXRoIGZ1cnRoZXIgY3VzdG9tIGZpZWxkcy4gIFvigKZd ICAgDQo+ICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBpZ25vcmUgZmllbGRzIHRoZXkgZG9uJ3QgcmVj b2duaXplDQo+ICB1bmxlc3MgdGhhdCBmaWVsZCBoYXMgYSBsYWJlbCBuYW1lIHRoYXQgZW5kcyB3 aXRoIHRoZSAiXyIgY2hhcmFjdGVyLA0KPiAgaW4gd2hpY2ggY2FzZSBhbiBlcnJvciBNVVNUIGJl IGdlbmVyYXRlZC4NCj4NCj4gU28sIGFzIGZhciBhcyB0aGlzIGNhbiBnbyB3aGlsZSBzdGF5aW5n IHByb3RvY29sLWFnbm9zdGljLCB0aGUgYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24gaXMgYWxyZWFk eSBmdWxseSBzcGVjaWZpZWQgaW4gdGhlIGJhc2UgU2VuTUwgZG9jdW1lbnQuDQoNClNvLCB0aGF0 IG1lYW5zIHRoYXQgdGhlIHNlbmRlciBvZiAiY3QiLCBhcyB3aXRob3V0ICJjdCIsIGhhcyBubyBr bm93bGVkZ2UgKHVubGVzcyBvYnRhaW5lZCB1c2luZyBzb21lIG91dCBvZiBiYW5kIG1lY2hhbmlz bSkgd2hldGhlciB0aGUgcmVjZWl2ZXIgd2lsbCBiZSBhYmxlIHRvIGludGVycHJldCB0aGUgYXNz b2NpYXRlZCB2YWx1ZSBjb3JyZWN0bHkgb3Igbm90LiBQZXJoYXBzIHRoYXQgd291bGQgYmUgZ29v ZCB0byBwb2ludCBvdXQuDQoNCi0tLQ0KDQo+PiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCj4+ IA0KPj4gUTIgKEVESVRPUklBTCk6DQo+PiANCj4+IFRoZSB0ZXh0IHNob3VsZCB1c2UgY29uc2lz dGVudCB0ZXJtaW5vbG9neS4gU2VlIGJlbG93IGZvciBhIGZldyBleGFtcGxlczoNCj4+IA0KPj4g VGhlIEFic3RyYWN0IHNheXM6DQo+PiANCj4+ICAiVGhlIFNlbnNvciBNZWFzdXJlbWVudCBMaXN0 cyAoU2VuTUwpIG1lZGlhIHR5cGUgc3VwcG9ydHMgbXVsdGlwbGUgIA0KPj4gdHlwZXMgb2YgdmFs dWVzLCBmcm9tIG51bWJlcnMgdG8gdGV4dCBzdHJpbmdzIGFuZCBhcmJpdHJhcnkgYmluYXJ5ICAN Cj4+IGRhdGEgdmFsdWVzLiAgSW4gb3JkZXIgdG8gc2ltcGxpZnkgcHJvY2Vzc2luZyBvZiB0aGUg ZGF0YSB2YWx1ZXMsICANCj4+IHRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdG8gc3BlY2lmeSBhIG5l dyBTZW5NTCBmaWVsZCBmb3IgaW5kaWNhdGluZyAgDQo+PiB0aGUgQ29udGVudC1Gb3JtYXQgb2Yg dGhlIGRhdGEuIg0KPj4gDQo+PiBGaXJzdCB0aGUgdGV4dCB0YWxrcyBhYm91dCB0eXBlcyBvZiB2 YWx1ZXMsIGFuZCB0aGVuIHN1ZGRlbmx5IHRoZSANCj4+IENvbnRlbnQtRm9ybWF0IG9mIHRoZSBk YXRhLg0KPg0KPiBJbmRlZWQsIHRoZSBhYnN0cmFjdCBpcyBhIHJhdGhlciB1bmZvcnR1bmF0ZSBj b250cmFjdGlvbiBvZiB0aGUgdGV4dCBpbiB0aGUgaW50cm9kdWN0aW9uLCB3aGljaCBzdGF0ZXMg ZXhwbGljaXRseSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYWJvdXQganVzdCBvbmUgdHlwZSBvZiBk YXRhLCB0aGUg4oCcdmTigJ0gZmllbGQsIGkuZS4gYmluYXJ5IGRhdGEgKHNlZSBTZWN0aW9uIDQu MiBvZiBSRkMgODQyOCkuDQo+DQo+IFNvIHdlIGZpeGVkIHRoZSBhYnN0cmFjdDoNCj4NCj4gT0xE Og0KPiBJbiBvcmRlciB0byBzaW1wbGlmeSBwcm9jZXNzaW5nIG9mIHRoZSBkYXRhIHZhbHVlcywg dGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byBzcGVjaWZ5IGEgbmV3IFNlbk1MIGZpZWxkIGZvciBp bmRpY2F0aW5nIHRoZSBDb250ZW50LUZvcm1hdCBvZiB0aGUgZGF0YS4NCj4gTkVXOg0KPiBJbiBv cmRlciB0byBmYWNpbGl0YXRlIHByb2Nlc3Npbmcgb2YgYmluYXJ5IGRhdGEgdmFsdWVzLCB0aGlz IGRvY3VtZW50IHNwZWNpZmllcyBhIHBhaXIgb2YgbmV3IFNlbk1MIGZpZWxkcyBmb3IgaW5kaWNh dGluZyB0aGUgQ29udGVudC1Gb3JtYXQgb2YgdGhvc2UgYmluYXJ5IGRhdGEgdmFsdWVzLCBpLmUu LCB0aGVpciBJbnRlcm5ldCBtZWRpYSB0eXBlIGluY2x1ZGluZyBwYXJhbWV0ZXJzIGFzIHdlbGwg YXMgYW55IENvbnRlbnQtQ29kaW5nIGFwcGxpZWQuDQo+DQo+PiBDb250ZW50LUZvcm1hdCBpcyB0 aGUgbmFtZSBvZiB0aGUgbmV3IGZpZWxkIC0gdGhhdCBpcyBub3Qgd2hhdCB5b3UgYXJlIA0KPj4g aW5kaWNhdGluZy4gWW91IGFyZSB1c2luZyB0aGUgbmV3IGZpZWxkIHRvIGluZGljYXRlIHNvbWV0 aGluZy4NCj4NCj5UaGUgbmFtZSBvZiB0aGUgbmV3IGZpZWxkIGlzIOKAnGN04oCdIChvciDigJxi Y3TigJ0gZm9yIHRoZSBjb3JyZXNwb25kaW5nIGJhc2UgZmllbGQpLiAgDQo+SXQgaXMgdXNlZCB0 byBpbmRpY2F0ZSB0aGUgQ29udGVudC1Gb3JtYXQsIGEgcHJlY2lzZSBkZWZpbml0aW9uIG9mIHdo aWNoIGZvciB0aGUgcHVycG9zZXMgb2YgdGhpcyBkb2N1bWVudCBmb2xsb3dzIGluIFNlY3Rpb24g Mi4NCg0KSSBkb24ndCB0aGluayBpdCBpcyB1c2VkIHRvIGluZGljYXRlIHRoZSBDb250ZW50LUZv cm1hdC4gSXQgbWlnaHQgYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgImNvbnRlbnQgZm9ybWF0Iiwg dGhvdWdoLiBObyBjYXBpdGFsIGxldHRlcnMsIGFuZCBubyBkYXNoIDopDQoNClRoZSBzYW1lIGFw cGxpZXMgZm9yIENvbnRlbnQtQ29kaW5nLiBJIHRoaW5rICJjb250ZW50IGNvZGluZyIgd291bGQg YmUgbW9yZSBjb3JyZWN0Lg0KDQotLS0NCg0KPj4gUTMgKEVESVRPUklBTCk6DQo+PiANCj4+IFRo ZSB0ZXh0IHNheXM6DQo+PiANCj4+ICJUaGUgQ29BUCBDb250ZW50LUZvcm1hdCAoU2VjdGlvbiAx Mi4zIG9mIFtSRkM3MjUyXSkgcHJvdmlkZXMganVzdCANCj4+IHRoaXMgaW5mb3JtYXRpb24iDQo+ PiANCj4+IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB3aXRoIGEgbGl0dGxlIGludHJvZHVjdGlv biBvbiBob3cgQ29BUCBpcyANCj4+IHJlbGF0ZWQgdG8gYWxsIHRoaXMuDQo+DQo+VGhlIGFic3Ry YWN0IG9mIFJGQyA4NDI4IHNheXM6DQo+DQo+4oCmICBBIHNpbXBsZSBzZW5zb3IsIHN1Y2ggYXMg YQ0KPiAgdGVtcGVyYXR1cmUgc2Vuc29yLCBjb3VsZCB1c2Ugb25lIG9mIHRoZXNlIG1lZGlhIHR5 cGVzIGluIHByb3RvY29scw0KPiAgc3VjaCBhcyBIVFRQIG9yIHRoZSBDb25zdHJhaW5lZCBBcHBs aWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgdG8NCj4gIHRyYW5zcG9ydCB0aGUgbWVhc3VyZW1lbnRz IG9mIHRoZSBzZW5zb3Igb3IgdG8gYmUgY29uZmlndXJlZC4NCj4NCj4odGFsa2luZyBhYm91dCB0 aGUgU2VuTUwgbWVkaWEgdHlwZXMuKQ0KPg0KPiANCj4+IEFsc28gInByb3ZpZGVzIGp1c3QgdGhp cyBpbmZvcm1hdGlvbiIgcHJvYmFibHkgbmVlZHMgc29tZSByZS13b3JkaW5nLg0KPg0KPiAgVG8g ZmFjaWxpdGF0ZSBhdXRvbWF0aWMgaW50ZXJwcmV0YXRpb24gaXQgaXMgdXNlZnVsIHRvIGJlIGFi bGUgdG8NCj4gIGluZGljYXRlIGFuIEludGVybmV0IG1lZGlhIHR5cGUgYW5kIGNvbnRlbnQtY29k aW5nIHJpZ2h0IGluIHRoZSBTZW5NTA0KPiAgUmVjb3JkLiAgVGhlIENvQVAgQ29udGVudC1Gb3Jt YXQgKFNlY3Rpb24gMTIuMyBvZiBbUkZDNzI1Ml0pIHByb3ZpZGVzDQo+ICBqdXN0IHRoaXMgaW5m b3JtYXRpb247IOKApg0KPg0KPiBPSywgd2UgZXhwYW5kZWQgdGhpcyBhIGJpdCBpbnRvOg0KPg0K PiBPTEQ6DQo+IENvbnRlbnQtRm9ybWF0ICh7e1NlY3Rpb24gMTIuMyBvZiAtY29hcH19KSBwcm92 aWRlcyBqdXN0IHRoaXMgaW5mb3JtYXRpb247IGVuY2xvc2luZyBhIENvbnRlbnQtRm9ybWF0IG51 bWJlciAoaW4gdGhpcyBjYXNlIG51bWJlciA2MCBhcyBkZWZpbmVkIGZvciBjb250ZW50LXR5cGUg DQo+IGFwcGxpY2F0aW9uL2Nib3IgaW4ge3stY2Jvcn19KSBpbiB0aGUgUmVjb3JkIGlzIGlsbHVz dHJhdGVkIGluIHt7ZXgtMn19LiBBbGwgcmVnaXN0ZXJlZCBDb0FQIENvbnRlbnQtRm9ybWF0cyBh cmUgbGlzdGVkDQo+IE5FVzoNCj4gQ29udGVudC1Gb3JtYXQgKHt7U2VjdGlvbiAxMi4zIG9mIC1j b2FwfX0pIHByb3ZpZGVzIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIGZvcm0gb2YgYSBzaW5nbGUg dW5zaWduZWQgaW50ZWdlcjsgZW5jbG9zaW5nIGEgQ29udGVudC1Gb3JtYXQgbnVtYmVyIChpbiB0 aGlzIGNhc2UgbnVtYmVyIDYwIGFzDQo+IGRlZmluZWQgZm9yIGNvbnRlbnQtdHlwZSBhcHBsaWNh dGlvbi9jYm9yIGluIHt7LWNib3J9fSkgaW4gdGhlIFJlY29yZCBpcyBpbGx1c3RyYXRlZCBpbiB7 e2V4LTJ9fS4gQWxsIHJlZ2lzdGVyZWQgQ29BUCBDb250ZW50LUZvcm1hdG4gbnVtYmVycyBhcmUg bGlzdGVkDQoNCkxvb2tzIGJldHRlci4NCg0KV291bGQgaXQgYmUgdXNlZnVsIHRvIHBvaW50IG91 dCB0aGF0IENvQVAgQ29udGVudC1Gb3JtYXQgYXBwbGllcyB0byB0aGUgd2hvbGUgcGF5bG9hZCwg d2hpbGUgImN0IiBvbmx5IGFwcGxpZXMgdG8gdGhlICJ2YiIgZWxlbWVudD8NCg0KLS0tDQoNCj4+ IFE0IChFRElUT1JJQUwpOg0KPj4gDQo+PiBTZWN0aW9uIDYgY29udGFpbnMgdGhlIEFCTkYgZm9y IHRoZSBuZXcgZmllbGRzLg0KPj4gDQo+PiBJcyB0aGVyZSBhIHJlYXNvbiB5b3UgZG9uJ3QgZGVm aW5lIHRoZW0gaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSBiYXNpYyANCj4+IGZpZWxkIGlzIGRlZmlu ZWQgaW4gUkZDIDg0MjggKHRoZXJlIGlzIG5vIEFCTkYpPw0KPg0KPiBZZXMuICBUaGUgZmllbGQg dmFsdWVzIGZvciB0aGUgZmllbGRzIGluIFJGQyA4NDI4IGhhdmUgYSByYXRoZXIgc2ltcGxlIHN0 cnVjdHVyZSAoc2VlIFRhYmxlIDEgaW4gU2VjdGlvbiA0LjMpOyB0aGVyZSB3YXMgbm8gbmVlZCB0 byBwcm92aWRlIEFCTkYuICANCj5BIENvbnRlbnQtRm9ybWF0LVNwZWMgY2FuIGdldCBjb21wbGlj YXRlZDsgdGhlcmUgaXMgbm8gc2luZ2xlIHN0YW5kYXJkIHRoYXQgY2FuIGJlIHVzZWQgdG8gcmVm ZXJlbmNlIHRoZSBBQk5GIGZvciBpdCBmcm9tLg0KPlNvIHdlIGRlZmluZSBpdCBoZXJlLg0KDQpX b3VsZCBpdCBiZSB1c2VmdWwgdG8gcG9pbnQgdGhhdCBvdXQ/DQoNCi0tLQ0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQo= From nobody Fri Sep 17 04:02:07 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE183A13FC for ; Fri, 17 Sep 2021 04:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JazvwzK8orq for ; Fri, 17 Sep 2021 04:02:00 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70053.outbound.protection.outlook.com [40.107.7.53]) (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 A9DD83A13F9 for ; Fri, 17 Sep 2021 04:01:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LYC+auje6s/rzqDcqXJVzCqG2OWoYvQbGyTonl0KcK2aMSw4/mR6jkm250qnOutsZcaN3bVoJKtlwkdLVdRWuS8Ui88hbTuaS61uR4AQN5i++YyFpZAzIHS5ceRIOZ3QRpLrQXfuqmXpdyBUM66TR9uvHHcKvU42teMp7YfComj9KC4WhV17EtnT69HLVl/Z7VlqtdAcU/3ZT1Yv+Lox8mNwM3k4pHYBwwgKtTwZbpZrS7/44OzMUzp3mIr1FsJ3cl6mhv14lCEwHBiuiI3xcWUsW1yyBAvA3G772XJx36zPy6W/BC0NHZnHnl/kn5TWFPls74yoY9YigtBbOZ9H6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kyy6cUCGaClAqmbVGoR+EArc7WtcPMiXKjztTHB2lkw=; b=b2CJv0e1bTAz3iLe0cmc/O59x3bSXTRBabmo2oLqQ4OsCIuUetToVYZL34tlRFYNZbt/XCqSO0/HXtNnUcWD4ckCOY/JzqdOxQpud8gYX/PNCncLxdfuY3bAopgU2/IcnFtUrGos5MkSjd6jsAJKgqvrXSqCJDIG9WaJXc5qf/IMl+Q2GXtKDaJ+lVxH/0wBiGJYL2BMjydDPp2R6NJLt8yuvabn8Df9biYh6QvhEXeAkNY97e1wPyx3/y3SSAx22TEfEcmT/3C0jVXAgpqyCmVLQw/UY6xdwsx9G0l4aXSzjOC7vHiO3MxP71mzC3JTqU+CnQrtFin3GHqpyT1P5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kyy6cUCGaClAqmbVGoR+EArc7WtcPMiXKjztTHB2lkw=; b=bB2d30QS8kKxvRetg3lgE37htPJFNqhObReV9hNAZ3KnI4W/x749bSZof17yjuzIx1Gf3muF67YMXhkMQOUufUEGxu+ZiwPnMrZLBcXKM6fcPAxZG17nEFBB4wxvXQydnmXZDgWCrgDyPphVxW94te+g61S8d+8BcbjPjRFGOKU= Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:28::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.12; Fri, 17 Sep 2021 11:01:52 +0000 Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e%7]) with mapi id 15.20.4544.009; Fri, 17 Sep 2021 11:01:52 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Bradbury, Matthew" , "core@ietf.org" CC: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: Additional use cases for Group OSCORE Thread-Index: AdepPvWBxRUPF0VTRBWaJQfnO46XhAChTjWA Date: Fri, 17 Sep 2021 11:01:52 +0000 Message-ID: <049EF3EB-287C-4CCA-BC81-C27CB915095D@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: lancaster.ac.uk; dkim=none (message not signed) header.d=none;lancaster.ac.uk; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bab318d9-274d-4a75-2983-08d979ca8e03 x-ms-traffictypediagnostic: HE1PR0701MB2139: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lOdeInioMp9NZxTyPbqubrIrhrgYIm+HEgE4om3LVfV6RZQh9XY7SVnepHrNw+uD/3x1otglIGdHEF+Bt0em447KI//tt/eKEzc9HtmmI4z/6FTo12UDL8MYzjbwrh4Z0DOr/ElFCWhPeIqbnduEd3oqrc8cXO7Uxo47DaQxkleQA0RSQ49Qxe3shNEIP1Hj8W9DwdvuF0EaKwawot+QUIlsLYOl2F6K6Wj1GQm/1qjmpvjCNWHv1ASkquQQnb0n4WEYxjBHsgAtT0ZBOKoYcCmMJBvJ2RZU3uafCNojBUog46corJmD5fkWmCDeJaPSsieyk8+StQMSzwIERM3FOkEQZUkV5BdPngQOrQu2WEqJKj1/+Lj9x3rfU+LyOOooxBN3yiJjMkiP+6Ller4NkshuThmXgj+hjiChn40Biq4VHa2teMUI/k8xlAHlFKnNrsvtrlE/EkAXPLlxsPiiiiN4//k2pmu1mrxXC8TRLwNHt0kTO0f7ZqjEebf0Ja8lXXhIzVYU7pAjBfdW7iAED4H+AE0VnBxxmfUE14H1OtgOc5dF3gpmrxfCFR1MXH00uX9nkKuLb0HLxdMc0b7MX1ZEyryTj61ImaQZblOYhKo9ZtobKNbAVV/UbZa6RalDu/I33SqmzFePgz2krjTLNHFEAjrOBCJJjCdZ3DQBJzmhdIXOixkCxWCo5LEgeQY1GqcG2mpO3g4JaCSY53Wt9Bq3oYIdfc4nmbzCDp763UBZ5YJyQ4Bck09Ly4/I3rXW36Z0tOKuGIugr6s8vRsIfZSdPofe9exVvOhXy7VUvhQmM6yZhWUECJD5Sv3Uwo7Y x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(376002)(346002)(396003)(66574015)(36756003)(166002)(316002)(5660300002)(66446008)(8936002)(66556008)(66946007)(6486002)(64756008)(76116006)(110136005)(122000001)(38100700002)(86362001)(4326008)(33656002)(2906002)(26005)(38070700005)(66476007)(966005)(6506007)(8676002)(478600001)(85202003)(6512007)(85182001)(2616005)(53546011)(186003)(71200400001)(83380400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?b3hteTE4bjRxUUtkcVkzVHhaQVcrRWdnSjkvVWdENEF4TGhOOUNZV2ZOcFd3?= =?utf-8?B?RXAzUDd2bGJDYUJWRGtrZ3BBUENkckxQNUIwTkFrdUg3RHFWbzVoTU1qQllT?= =?utf-8?B?bklzN3JsL1daR0JNVks5R0RBSGl2eDlDenpqUmRFR2NpaGpyTjJnRmZTQW9z?= =?utf-8?B?KytraUEyaGZMczh3WjRqY29jYWFrejVrNmdkT0JGRWdZaVJYRmNIMWRjeVBO?= =?utf-8?B?ZG05NlNxMWFza2tZUDlsakVXeEJNSXNBdnRzRjVHVHlvOEdPeDN4MUo5SzdR?= =?utf-8?B?a29yTE5vejh1RFMxT01lazk4SXVWVEY3U3VpNXIvVDZCS3dkLzJLek54TFE0?= =?utf-8?B?cHk5eEZlcHFLbzNKWndDRERqWjI3WEd5V0dkQUQrZ05ORWZvSlJGN3RVVG9B?= =?utf-8?B?K0gwL0lDOEVxUEZad1podnRwMllrMEswc0dtVDVVZ3RNS05zVy9DNkRMQXpB?= =?utf-8?B?cGtYZVdBZmZPM1NNdFFmZlNTRVFmelR5ZUJ5WEV6VTNCdDR0OGozdS9xTXdE?= =?utf-8?B?K2RLczh6ZjA1RmFYRTd2Q1ljcmU1b0NUYWVVYkJaMzZXUGRqQml1NytOMUM3?= =?utf-8?B?dlFlUTBsWDhhVWNFWkdNMzVRS21CQnkrMFFDaHZUclZnNWg4THB2YWc3MlU5?= =?utf-8?B?VjI1cDdqeVlZM2taSUJGUWhNcHl2enl6SFlhZnJrZFRaaFJZQk5CSFZBZkcr?= =?utf-8?B?OEpVOHRJbGtwKzJLelVZNnpjNGtpMDRZQmQ0bXBlWnpscXg1c1FyRit3VU9m?= =?utf-8?B?aktMYXhkMGR0aW1RNHVZWjI3VEwyaGdGN21aelo5UzU3aW1wc0ZvU29ETTB6?= =?utf-8?B?RWEvd2xLejRrcDhValJtYW1xTDVzRzZ3UE1MTjA2aDlpeGY4N1FhSWppV3NM?= =?utf-8?B?ZVZSTHllazNMRDhQaUFEVll2ZVVEOGxxOGVHZWdQaTFqZmdxQjhlTTZpQWNJ?= =?utf-8?B?ZGhLczJSd2FhRkdvWFROMGR2NnU2NnQwWVZ2bU8rTXlOdWRFSFowLzFndmVJ?= =?utf-8?B?OW56bHVja1ViZVR2YWpoMFlqVzhnUlZXaHhLbTJRSk5oQTVKLzZUUk1nNU5o?= =?utf-8?B?enRaSFhtbnRacC9VTm56NVB6MXlMYk9pMGM2UWRpZmkyempoZEtUaU40THVj?= =?utf-8?B?bDJQYVIyUEZCM1BYQ21qSTZVVDVLTzI5VGJ6RkM4cXZFRUNoT1pPWUJMWnpo?= =?utf-8?B?alBXVHEvT1VqNGs0K2UxZUVXSjBWNExSSTJxNHhGSTZubGlmbGh0Y2V6aUdZ?= =?utf-8?B?S0pxamR4YWVnOTd3aXFubnVIWFpZZHZWa0wxZm4xNHh2L3BBTklieW9yRkhr?= =?utf-8?B?UEEzejJlZ0ZIQkd0TThPcHZySTE2ZTFHRWo3NjVjNnMzMFpKT3RxSW1LZVRa?= =?utf-8?B?eCtpcmtiZGNyWWJLZjZLV1RKNXdlWVZ0MWI1UVl1aS9NUnU5aWI1VkRTMzhC?= =?utf-8?B?c0QzakxFaXdOa0ttUXVtcXhtMEcwamxGUXQ3eXcvQ2gzcExTTUpUUlFFWXU2?= =?utf-8?B?RzkyNTAzYXFTTmRsVDRSY3Y1Y2VwUmR5Vy9DS2p1YVlsRWhHcFdRdkNjUGw1?= =?utf-8?B?VkVYeHVSNlJrMGxxT1haaXUxeHVMdTk3ZzZ0UkRwNko4MlRWYjQzT3M0citw?= =?utf-8?B?YzdBSHZQQ0pCampmNTJpRGduOUxDL2hqTzBpZW96d0FDYWhsalNoQjZmZXBw?= =?utf-8?B?VDdNSVliZ1BVVmtwVVREVFp1TzRSQUNKbStqZ2gyYzliVkFMS0E1cEl2bCtX?= =?utf-8?B?cWtkMGN2Nis5SUcwZ3hnbE9uOWNBR3NWZGlFWTVSc0VwaCsrUmpYVVQvcUZa?= =?utf-8?B?SmcrZTdMTUNpYTdVU1U1QT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_049EF3EB287C4CCABC81C27CB915095Dericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bab318d9-274d-4a75-2983-08d979ca8e03 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2021 11:01:52.1563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Bs5QKRyOdVzGFFco8KySgpGI0iD/p3VsbpZst39EQutFzYX5g9rIkeFVZgSOUhW7QpD2jnSgrAt/+aucLEQtxaTYMRJgkHTE5LNjiXHjuq8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2139 Archived-At: Subject: Re: [core] Additional use cases for Group OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2021 11:02:06 -0000 --_000_049EF3EB287C4CCABC81C27CB915095Dericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWF0dGhldywNCg0KVGhhbmtzIGZvciB5b3VyIGlucHV0LiBUaGVzZSBhcmUgaW50ZXJlc3Rp bmcgZXhhbXBsZXMgb2Ygd2hlcmUgc2lnbmVkIHVuZW5jcnlwdGVkIGRhdGEgY291bGQgbWFrZXMg c2Vuc2UuDQoNCkEgcXVlc3Rpb24gYWJvdXQgdGhlIGZpcnN0IGV4YW1wbGUuIERpc3JlZ2FyZGlu ZyB0aGF0IHdlbGwta25vd24gc2VjcmV0IGtleXMgYXJlIG5vdCBtdWNoIGRpZmZlcmVudCBmcm9t IG5vIGVuY3J5cHRpb24sIHdoeSBkb2Vzbid0IHNoYXJpbmcgYSB3ZWxsLWtub3duIGtleSBpbiB0 aGUgZ3JvdXAgb2Ygbm9kZXMgYWRkcmVzcyB0aGUgaXNzdWU/IEkgdW5kZXJzdGFuZCB0aGF0IGlm IG11bHRpcGxlIGtleXMgYXJlIGF2YWlsYmxlIGFuZCBkaWZmZXJlbnQgcmVwdXRhdGlvbnMgbWF5 IGJlIGNhc3Qgd2l0aCBkaWZmZXJlbnQga2V5cyB0aGVuIGNvbnRyYWRpY3RpbmcgcmVwdXRhdGlv bnMgY2FuIGJlIGNhc3QuIEJ1dCB3aHkgZG9lcyB0aGUga2V5IGhhdmUgdG8gYmUgdXNlZCBvbmx5 IG9uY2U/IENvdWxkbid0IHNvbWUgdW5kZXJseWluZyBwYXJhbWV0ZXIgcHJvdmlkZSBmcmVzaG5l c3MsIGxpa2UgdGhlIE9TQ09SRSBQYXJ0aWFsIElWPw0KDQpJbiB0aGUgc2Vjb25kIGV4YW1wbGUg aXQgaXMgY2xlYXIgdGhhdCB0aGUgbWVzc2FnZSBuZWVkcyB0byBiZSBjb21tdW5pY2F0ZWQgZmFz dGVyIHRoYW4ga2V5cyBjYW4gYmUgZXN0YWJsaXNoZWQgd2l0aCB0aGUgcmVjZWl2ZXJzLiAoT3Ig dXNlIHNoYXJlZCB3ZWxsLWtub3duIGtleXMsIGJ1dCB0aGVuIGFnYWluIEkgZG9uJ3Qgc2VlIG11 Y2ggZGlmZmVyZW5jZSBjb21wYXJlZCB0byBubyBlbmNyeXB0aW9uLikNCg0KSXQgd291bGQgYmUg c3RyYWlnaHRmb3J3YXJkIHRvIGRlZmluZSB0aGUgZ3JvdXAgbW9kZSBvZiBPU0NPUkUgd2l0aCBz aWduZWQgdW5lbmNyeXB0ZWQgbWVzc2FnZXMuIEJ1dCBPU0NPUkUgdXNlcyBDT1NFIGFsZ29yaXRo bXMsIGFuZCB0aGVyZSBpcyBubyBOVUxMIGVuY3J5cHRpb24gYWxnb3JpdGhtIGluIENPU0UgKHll dCkuIFRoZSBtYWluIHJlYXNvbiB3aHkgZW5jcnlwdGlvbiBpcyBtYW5kYXRlZCBpcyB0byBhdm9p ZCBwb3RlbnRpYWwgY29uZmxpY3RzIHdpdGggYmVzdCBjdXJyZW50IHByYWN0aWNlcywgaW4gcGFy dGljdWxhciB0byBhdm9pZGluZyBwZXJ2YXNpdmUgbW9uaXRvcmluZyAoUkZDIDcyNTgpLiBCdXQg SSB0aGluayB5b3VyIGV4YW1wbGVzIG1ha2UgY2xlYXIgdGhhdCBpbiB0aG9zZSBjYXNlcyBpdCBp cyBtb3RpdmF0ZWQgdG8gc2hhcmUgdGhpcyBpbmZvcm1hdGlvbiBpbiBwbGFpbiB0ZXh0LiBOb3Qg c2F5aW5nIHRoYXQgd2Ugc2hvdWxkIG1ha2UgdGhpcyBjaGFuZ2Ugbm93LCBidXQgZGVmaW5pdGVs eSBhIHZhbGlkIGlucHV0LiBXaGF0IGRvIG90aGVyIHBlb3BsZSB0aGluaz8NCg0KQmVzdCByZWdh cmRzDQpHw7ZyYW4NCg0KDQoNCkZyb206ICJCcmFkYnVyeSwgTWF0dGhldyIgPG0ucy5icmFkYnVy eUBsYW5jYXN0ZXIuYWMudWs+DQpEYXRlOiBUdWVzZGF5LCAxNCBTZXB0ZW1iZXIgMjAyMSBhdCAx MDoxMQ0KVG86ICJjb3JlQGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4NCkNjOiBHw7ZyYW4gU2Vs YW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4sIENocmlzdGlhbiBBbXPDvHNzIDxj aHJpc3RpYW5AYW1zdWVzcy5jb20+DQpTdWJqZWN0OiBBZGRpdGlvbmFsIHVzZSBjYXNlcyBmb3Ig R3JvdXAgT1NDT1JFDQoNCkhlbGxvIGFsbCwNCg0KSSByZWNlbnRseSB3YXRjaGVkIGEgdGFsayBi eSBDaHJpc3RpYW4gQW1zw7xzcyBbMV0gd2hpY2ggaW5jbHVkZWQgYW4gaW50cm9kdWN0aW9uIHRv IHRoZSBDb1JFIGVjb3N5c3RlbSwgaW5jbHVkaW5nIE9TQ09SRSwgd2hlcmUgSSBhc2tlZCBpZiBH cm91cCBPU0NPUkUgc3VwcG9ydHMgbXVsdGljYXN0aW5nIHVuZW5jcnlwdGVkIGRpZ2l0YWxseSBz aWduZWQgbWVzc2FnZXMuIEJlbG93IGFyZSBzb21lIGRldGFpbHMgb2YgbXkgdXNlIGNhc2UgZm9y IHRoaXMgY2FwYWJpbGl0eSwgYW5kIGFsc28gYW5vdGhlciB1c2UgY2FzZSBmcm9tIGNvbm5lY3Rl ZCB2ZWhpY2xlcyB0aGF0IG1heSBiZSBhcHBsaWNhYmxlLg0KDQpJIGhhdmUgcmVjZW50bHkgYmVl biB1c2luZyBPU0NPUkUgaW4gYSBwcm9qZWN0IGxvb2tpbmcgYXQgdGFzayBvZmZsb2FkaW5nIGZy b20gSW9UIGRldmljZXMgdG8gZWRnZSBub2RlcyBbMl0uIEFzIHBhcnQgb2YgdGhpcyBwcm9qZWN0 LCBhIHRydXN0IG1vZGVsIHdhcyB1c2VkIHRvIGFzc2VzcyB0cnVzdCBpbiBlZGdlIG5vZGUgYmVo YXZpb3VyLiBXZSB3YW50ZWQgdG8gaW5jb3Jwb3JhdGUgcmVwdXRhdGlvbiBiZWxpZWZzIGZyb20g b3RoZXIgSW9UIG5vZGVzLiBBcyBhbiBpbmNlbnRpdmUgdG8gbm90IGxpZSBhYm91dCByZXB1dGF0 aW9uIGJlbGllZnMgb3IgdG8gdGVsbCBkaWZmZXJlbnQgYWdlbnRzIGFib3V0IGRpZmZlcmVudCBi ZWxpZWYgdmFsdWVzLCB3ZSBoYXZlIHRob3NlIGJlbGllZnMgc2VudCBpbiB0aGUgY2xlYXIgd2l0 aCBhIGRpZ2l0YWwgc2lnbmF0dXJlIGZvciBpbnRlZ3JpdHksIGF1dGhlbnRpY2F0aW9uLCBhbmQg bm9uLXJlcHVkaWF0aW9uLiBJdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgcmVwdXRhdGlvbiBtZXNz YWdlIGlzIG5vdCBzZW50IG11bHRpcGxlIHRpbWVzIGFuZCBlbmNyeXB0ZWQgd2l0aCBhIGRpZmZl cmVudCBrZXkgZWFjaCB0aW1lLCBhcyB0aGlzIHBvdGVudGlhbGx5IGFsbG93cyBkZXZpY2VzIHRv IGxpZSBhYm91dCByZXB1dGF0aW9uLg0KDQpNeSBpbnRlbnQgd2FzIHRvIHVzZSBHcm91cCBPU0NP UkUgdG8gbXVsdGljYXN0IGFuIHVuZW5jcnlwdGVkIGFuZCBkaWdpdGFsbHkgc2lnbmVkIG1lc3Nh Z2UgY29udGFpbmluZyByZXB1dGF0aW9uLCBidXQgZHVlIHRvIGxhY2sgb2Ygc3VwcG9ydCBoYXZl IGluc3RlYWQgYXR0YWNoZWQgYSBkaWdpdGFsIHNpZ25hdHVyZSBpbnNpZGUgdGhlIENvQVAgcGF5 bG9hZC4gQW4gYWx0ZXJuYXRpdmUgdG8gbXVsdGljYXN0aW5nIHVuZW5jcnlwdGVkIGRpZ2l0YWxs eSBzaWduZWQgbWVzc2FnZXMgdGhhdCB3b3VsZCBiZSBhY2NlcHRhYmxlLCBpcyBlbmNyeXB0aW5n IHRoZSBtZXNzYWdlIHdpdGggYSBzaGFyZWQgc2VjcmV0IHRoYXQgYWxsIGRldmljZXMgYXJlIGF3 YXJlIG9mIGFuZCB0aGVuIG9ubHkgc2VuZGluZyB0aGlzIG1lc3NhZ2UgY29udGFpbmluZyByZXB1 dGF0aW9uIGluZm9ybWF0aW9uIG9uY2UuDQoNCg0KDQpJIGFtIGFsc28gYXdhcmUgb2YgYSBzaW1p bGFyIHJlcXVpcmVtZW50IGluIGNvbm5lY3RlZCB2ZWhpY2xlcywgd2hlcmUgQ0FNIChzYWZldHkp IGFuZCBERU5NIChldmVudCkgbWVzc2FnZXMgYXJlIGJyb2FkY2FzdGVkIHdoZXJlIHRoZSBjb250 ZW50IGlzIHVuZW5jcnlwdGVkIGJ1dCBkaWdpdGFsbHkgc2lnbmVkLiBNZXNzYWdlcyBhcmUgdW5l bmNyeXB0ZWQgdG8gYXZvaWQgdGhlIHRpbWUgY29zdCBvZiBzZXR0aW5nIHVwIHNoYXJlZCBzZWNy ZXRzIGZvciBlbmNyeXB0aW9uIHdoaWNoIG1heSBpbXBhY3Qgb24gdGhlIHNhZmV0eSBvZiB0aGUg c2VuZGluZyB2ZWhpY2xlIGFuZCBzdXJyb3VuZGluZyB2ZWhpY2xlcy4gVGhlcmUgaXMgc29tZSBt b3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgYXQgWzNdLg0KDQpbMV0gaHR0cHM6Ly9jaHJpc3RpYW4u YW1zdWVzcy5jb20vcHJlc2VudGF0aW9ucy8yMDIxL3N1bW1pdC1jb3JlLzxodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTlhODUyY2ZmLWM1MWUxNWZhLTlhODU2YzY0LTg2OTU5 ZTQ3MjI0My1lMTY4MjlkZDM2YjQwN2UwJnE9MSZlPWI4ZTk1Njk2LWIxZDAtNGQ1MS04MGUzLWM0 NzM2YzljYjBkYyZ1PWh0dHBzJTNBJTJGJTJGY2hyaXN0aWFuLmFtc3Vlc3MuY29tJTJGcHJlc2Vu dGF0aW9ucyUyRjIwMjElMkZzdW1taXQtY29yZSUyRj4NClsyXSBodHRwczovL3Jhdy5naXRodWJ1 c2VyY29udGVudC5jb20vTUJyYWRidXJ5L3B1YmxpY2F0aW9ucy9tYXN0ZXIvcGFwZXJzL1NBQy1E QURTMjAyMS5wZGY8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1jMDhhYjE2 Zi05ZjExODg2YS1jMDhhZjFmNC04Njk1OWU0NzIyNDMtZjBkYjhiM2RkMTBjYzQ4NyZxPTEmZT1i OGU5NTY5Ni1iMWQwLTRkNTEtODBlMy1jNDczNmM5Y2IwZGMmdT1odHRwcyUzQSUyRiUyRnJhdy5n aXRodWJ1c2VyY29udGVudC5jb20lMkZNQnJhZGJ1cnklMkZwdWJsaWNhdGlvbnMlMkZtYXN0ZXIl MkZwYXBlcnMlMkZTQUMtREFEUzIwMjEucGRmPg0KWzNdIGh0dHBzOi8vd3d3LmV0c2kub3JnL2Rl bGl2ZXIvZXRzaV9lbi8zMDI2MDBfMzAyNjk5LzMwMjYzNzAyLzAxLjA0LjAxXzYwL2VuXzMwMjYz NzAydjAxMDQwMXAucGRmPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9YzY5 ZGY3NDYtOTkwNmNlNDMtYzY5ZGI3ZGQtODY5NTllNDcyMjQzLWM5OWNlOTBkOGUzMWIzYzcmcT0x JmU9YjhlOTU2OTYtYjFkMC00ZDUxLTgwZTMtYzQ3MzZjOWNiMGRjJnU9aHR0cHMlM0ElMkYlMkZ3 d3cuZXRzaS5vcmclMkZkZWxpdmVyJTJGZXRzaV9lbiUyRjMwMjYwMF8zMDI2OTklMkYzMDI2Mzcw MiUyRjAxLjA0LjAxXzYwJTJGZW5fMzAyNjM3MDJ2MDEwNDAxcC5wZGY+DQoNCk1hbnkgdGhhbmtz LA0KDQpNYXR0aGV3IEJyYWRidXJ5IHwgTGVjdHVyZXIgaW4gQ3liZXIgU2VjdXJpdHkNClNjaG9v bCBvZiBDb21wdXRpbmcgYW5kIENvbW11bmljYXRpb25zIHwgTGFuY2FzdGVyIFVuaXZlcnNpdHkN Cg0K --_000_049EF3EB287C4CCABC81C27CB915095Dericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLVNFIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGkgTWF0dGhldyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBmb3IgeW91 ciBpbnB1dC4gVGhlc2UgYXJlIGludGVyZXN0aW5nIGV4YW1wbGVzIG9mIHdoZXJlIHNpZ25lZCB1 bmVuY3J5cHRlZCBkYXRhIGNvdWxkIG1ha2VzIHNlbnNlLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5B IHF1ZXN0aW9uIGFib3V0IHRoZSBmaXJzdCBleGFtcGxlLiBEaXNyZWdhcmRpbmcgdGhhdCB3ZWxs LWtub3duIHNlY3JldCBrZXlzIGFyZSBub3QgbXVjaCBkaWZmZXJlbnQgZnJvbSBubyBlbmNyeXB0 aW9uLCB3aHkgZG9lc24ndCBzaGFyaW5nIGEgd2VsbC1rbm93biBrZXkgaW4gdGhlIGdyb3VwIG9m IG5vZGVzIGFkZHJlc3MgdGhlIGlzc3VlPyBJIHVuZGVyc3RhbmQgdGhhdCBpZg0KIG11bHRpcGxl IGtleXMgYXJlIGF2YWlsYmxlIGFuZCBkaWZmZXJlbnQgcmVwdXRhdGlvbnMgbWF5IGJlIGNhc3Qg d2l0aCBkaWZmZXJlbnQga2V5cyB0aGVuIGNvbnRyYWRpY3RpbmcgcmVwdXRhdGlvbnMgY2FuIGJl IGNhc3QuIEJ1dCB3aHkgZG9lcyB0aGUga2V5IGhhdmUgdG8gYmUgdXNlZCBvbmx5IG9uY2U/IENv dWxkbid0IHNvbWUgdW5kZXJseWluZyBwYXJhbWV0ZXIgcHJvdmlkZSBmcmVzaG5lc3MsIGxpa2Ug dGhlIE9TQ09SRSBQYXJ0aWFsIElWPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIHNlY29uZCBl eGFtcGxlIGl0IGlzIGNsZWFyIHRoYXQgdGhlIG1lc3NhZ2UgbmVlZHMgdG8gYmUgY29tbXVuaWNh dGVkIGZhc3RlciB0aGFuIGtleXMgY2FuIGJlIGVzdGFibGlzaGVkIHdpdGggdGhlIHJlY2VpdmVy cy4gKE9yIHVzZSBzaGFyZWQgd2VsbC1rbm93biBrZXlzLCBidXQgdGhlbiBhZ2FpbiBJIGRvbid0 IHNlZSBtdWNoIGRpZmZlcmVuY2UgY29tcGFyZWQgdG8NCiBubyBlbmNyeXB0aW9uLik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkl0IHdvdWxkIGJlIHN0cmFpZ2h0Zm9yd2FyZCB0byBkZWZpbmUgdGhlIGdy b3VwIG1vZGUgb2YgT1NDT1JFIHdpdGggc2lnbmVkIHVuZW5jcnlwdGVkIG1lc3NhZ2VzLiBCdXQg T1NDT1JFIHVzZXMgQ09TRSBhbGdvcml0aG1zLCBhbmQgdGhlcmUgaXMgbm8gTlVMTCBlbmNyeXB0 aW9uIGFsZ29yaXRobSBpbiBDT1NFICh5ZXQpLiBUaGUgbWFpbiByZWFzb24gd2h5IGVuY3J5cHRp b24NCiBpcyBtYW5kYXRlZCBpcyB0byBhdm9pZCBwb3RlbnRpYWwgY29uZmxpY3RzIHdpdGggYmVz dCBjdXJyZW50IHByYWN0aWNlcywgaW4gcGFydGljdWxhciB0byBhdm9pZGluZyBwZXJ2YXNpdmUg bW9uaXRvcmluZyAoUkZDIDcyNTgpLiBCdXQgSSB0aGluayB5b3VyIGV4YW1wbGVzIG1ha2UgY2xl YXIgdGhhdCBpbiB0aG9zZSBjYXNlcyBpdCBpcyBtb3RpdmF0ZWQgdG8gc2hhcmUgdGhpcyBpbmZv cm1hdGlvbiBpbiBwbGFpbiB0ZXh0LiBOb3Qgc2F5aW5nDQogdGhhdCB3ZSBzaG91bGQgbWFrZSB0 aGlzIGNoYW5nZSBub3csIGJ1dCBkZWZpbml0ZWx5IGEgdmFsaWQgaW5wdXQuIFdoYXQgZG8gb3Ro ZXIgcGVvcGxlIHRoaW5rPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCByZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkfD tnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+JnF1b3Q7QnJh ZGJ1cnksIE1hdHRoZXcmcXVvdDsgJmx0O20ucy5icmFkYnVyeUBsYW5jYXN0ZXIuYWMudWsmZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDE0IFNlcHRlbWJlciAyMDIxIGF0IDEwOjExPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDtjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtjb3JlQGlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOiA8L2I+R8O2cmFuIFNlbGFuZGVyICZsdDtnb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb20mZ3Q7LCBDaHJpc3RpYW4gQW1zw7xzcyAmbHQ7Y2hyaXN0aWFuQGFtc3Vlc3Mu Y29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5BZGRpdGlvbmFsIHVzZSBjYXNlcyBmb3IgR3Jv dXAgT1NDT1JFPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SGVsbG8gYWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+SSByZWNlbnRseSB3YXRjaGVkIGEgdGFsayBieSBDaHJpc3RpYW4gQW1zw7xzcyBbMV0gd2hp Y2ggaW5jbHVkZWQgYW4gaW50cm9kdWN0aW9uIHRvIHRoZSBDb1JFIGVjb3N5c3RlbSwgaW5jbHVk aW5nIE9TQ09SRSwgd2hlcmUgSSBhc2tlZCBpZiBHcm91cCBPU0NPUkUgc3VwcG9ydHMgbXVsdGlj YXN0aW5nIHVuZW5jcnlwdGVkIGRpZ2l0YWxseSBzaWduZWQgbWVzc2FnZXMuIEJlbG93DQogYXJl IHNvbWUgZGV0YWlscyBvZiBteSB1c2UgY2FzZSBmb3IgdGhpcyBjYXBhYmlsaXR5LCBhbmQgYWxz byBhbm90aGVyIHVzZSBjYXNlIGZyb20gY29ubmVjdGVkIHZlaGljbGVzIHRoYXQgbWF5IGJlIGFw cGxpY2FibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGhhdmUgcmVjZW50bHkgYmVlbiB1c2luZyBP U0NPUkUgaW4gYSBwcm9qZWN0IGxvb2tpbmcgYXQgdGFzayBvZmZsb2FkaW5nIGZyb20gSW9UIGRl dmljZXMgdG8gZWRnZSBub2RlcyBbMl0uIEFzIHBhcnQgb2YgdGhpcyBwcm9qZWN0LCBhIHRydXN0 IG1vZGVsIHdhcyB1c2VkIHRvIGFzc2VzcyB0cnVzdCBpbiBlZGdlIG5vZGUgYmVoYXZpb3VyLiBX ZSB3YW50ZWQgdG8gaW5jb3Jwb3JhdGUNCiByZXB1dGF0aW9uIGJlbGllZnMgZnJvbSBvdGhlciBJ b1Qgbm9kZXMuIEFzIGFuIGluY2VudGl2ZSB0byBub3QgbGllIGFib3V0IHJlcHV0YXRpb24gYmVs aWVmcyBvciB0byB0ZWxsIGRpZmZlcmVudCBhZ2VudHMgYWJvdXQgZGlmZmVyZW50IGJlbGllZiB2 YWx1ZXMsIHdlIGhhdmUgdGhvc2UgYmVsaWVmcyBzZW50IGluIHRoZSBjbGVhciB3aXRoIGEgZGln aXRhbCBzaWduYXR1cmUgZm9yIGludGVncml0eSwgYXV0aGVudGljYXRpb24sIGFuZCBub24tcmVw dWRpYXRpb24uDQogSXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHJlcHV0YXRpb24gbWVzc2FnZSBp cyBub3Qgc2VudCBtdWx0aXBsZSB0aW1lcyBhbmQgZW5jcnlwdGVkIHdpdGggYSBkaWZmZXJlbnQg a2V5IGVhY2ggdGltZSwgYXMgdGhpcyBwb3RlbnRpYWxseSBhbGxvd3MgZGV2aWNlcyB0byBsaWUg YWJvdXQgcmVwdXRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPk15IGludGVudCB3YXMgdG8gdXNl IEdyb3VwIE9TQ09SRSB0byBtdWx0aWNhc3QgYW4gdW5lbmNyeXB0ZWQgYW5kIGRpZ2l0YWxseSBz aWduZWQgbWVzc2FnZSBjb250YWluaW5nIHJlcHV0YXRpb24sIGJ1dCBkdWUgdG8gbGFjayBvZiBz dXBwb3J0IGhhdmUgaW5zdGVhZCBhdHRhY2hlZCBhIGRpZ2l0YWwgc2lnbmF0dXJlIGluc2lkZSB0 aGUgQ29BUCBwYXlsb2FkLiBBbiBhbHRlcm5hdGl2ZQ0KIHRvIG11bHRpY2FzdGluZyB1bmVuY3J5 cHRlZCBkaWdpdGFsbHkgc2lnbmVkIG1lc3NhZ2VzIHRoYXQgd291bGQgYmUgYWNjZXB0YWJsZSwg aXMgZW5jcnlwdGluZyB0aGUgbWVzc2FnZSB3aXRoIGEgc2hhcmVkIHNlY3JldCB0aGF0IGFsbCBk ZXZpY2VzIGFyZSBhd2FyZSBvZiBhbmQgdGhlbiBvbmx5IHNlbmRpbmcgdGhpcyBtZXNzYWdlIGNv bnRhaW5pbmcgcmVwdXRhdGlvbiBpbmZvcm1hdGlvbiBvbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1HQiI+SSBhbSBhbHNvIGF3YXJlIG9mIGEgc2ltaWxhciByZXF1aXJlbWVudCBpbiBjb25uZWN0 ZWQgdmVoaWNsZXMsIHdoZXJlIENBTSAoc2FmZXR5KSBhbmQgREVOTSAoZXZlbnQpIG1lc3NhZ2Vz IGFyZSBicm9hZGNhc3RlZCB3aGVyZSB0aGUgY29udGVudCBpcyB1bmVuY3J5cHRlZCBidXQgZGln aXRhbGx5IHNpZ25lZC4gTWVzc2FnZXMgYXJlIHVuZW5jcnlwdGVkIHRvIGF2b2lkDQogdGhlIHRp bWUgY29zdCBvZiBzZXR0aW5nIHVwIHNoYXJlZCBzZWNyZXRzIGZvciBlbmNyeXB0aW9uIHdoaWNo IG1heSBpbXBhY3Qgb24gdGhlIHNhZmV0eSBvZiB0aGUgc2VuZGluZyB2ZWhpY2xlIGFuZCBzdXJy b3VuZGluZyB2ZWhpY2xlcy4gVGhlcmUgaXMgc29tZSBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMg YXQgWzNdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIu ZmlyZWV5ZS5jb20vdjEvdXJsP2s9OWE4NTJjZmYtYzUxZTE1ZmEtOWE4NTZjNjQtODY5NTllNDcy MjQzLWUxNjgyOWRkMzZiNDA3ZTAmYW1wO3E9MSZhbXA7ZT1iOGU5NTY5Ni1iMWQwLTRkNTEtODBl My1jNDczNmM5Y2IwZGMmYW1wO3U9aHR0cHMlM0ElMkYlMkZjaHJpc3RpYW4uYW1zdWVzcy5jb20l MkZwcmVzZW50YXRpb25zJTJGMjAyMSUyRnN1bW1pdC1jb3JlJTJGIj4NCmh0dHBzOi8vY2hyaXN0 aWFuLmFtc3Vlc3MuY29tL3ByZXNlbnRhdGlvbnMvMjAyMS9zdW1taXQtY29yZS88L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PlsyXSA8YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPWMwOGFi MTZmLTlmMTE4ODZhLWMwOGFmMWY0LTg2OTU5ZTQ3MjI0My1mMGRiOGIzZGQxMGNjNDg3JmFtcDtx PTEmYW1wO2U9YjhlOTU2OTYtYjFkMC00ZDUxLTgwZTMtYzQ3MzZjOWNiMGRjJmFtcDt1PWh0dHBz JTNBJTJGJTJGcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSUyRk1CcmFkYnVyeSUyRnB1YmxpY2F0 aW9ucyUyRm1hc3RlciUyRnBhcGVycyUyRlNBQy1EQURTMjAyMS5wZGYiPg0KaHR0cHM6Ly9yYXcu Z2l0aHVidXNlcmNvbnRlbnQuY29tL01CcmFkYnVyeS9wdWJsaWNhdGlvbnMvbWFzdGVyL3BhcGVy cy9TQUMtREFEUzIwMjEucGRmPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5bM10gPGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0 Mi5maXJlZXllLmNvbS92MS91cmw/az1jNjlkZjc0Ni05OTA2Y2U0My1jNjlkYjdkZC04Njk1OWU0 NzIyNDMtYzk5Y2U5MGQ4ZTMxYjNjNyZhbXA7cT0xJmFtcDtlPWI4ZTk1Njk2LWIxZDAtNGQ1MS04 MGUzLWM0NzM2YzljYjBkYyZhbXA7dT1odHRwcyUzQSUyRiUyRnd3dy5ldHNpLm9yZyUyRmRlbGl2 ZXIlMkZldHNpX2VuJTJGMzAyNjAwXzMwMjY5OSUyRjMwMjYzNzAyJTJGMDEuMDQuMDFfNjAlMkZl bl8zMDI2MzcwMnYwMTA0MDFwLnBkZiI+DQpodHRwczovL3d3dy5ldHNpLm9yZy9kZWxpdmVyL2V0 c2lfZW4vMzAyNjAwXzMwMjY5OS8zMDI2MzcwMi8wMS4wNC4wMV82MC9lbl8zMDI2MzcwMnYwMTA0 MDFwLnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPk1hbnkgdGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5NYXR0aGV3IEJyYWRi dXJ5IHwgTGVjdHVyZXIgaW4gQ3liZXIgU2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+U2Nob29sIG9mIENvbXB1dGluZyBhbmQgQ29tbXVuaWNhdGlv bnMgfCBMYW5jYXN0ZXIgVW5pdmVyc2l0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_049EF3EB287C4CCABC81C27CB915095Dericssoncom_-- From nobody Sat Sep 18 12:15:15 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E763A0B10; Sat, 18 Sep 2021 12:15:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez , jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <163199251278.32143.9125277138231739491@ietfa.amsl.com> Date: Sat, 18 Sep 2021 12:15:12 -0700 Archived-At: Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2021 19:15:13 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-senml-data-ct-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is there any generic guidance to provide on expected error handling behavior if: -- ct (or bct) contains a number outside of the 0-65535 range, or an unregistered value per the CoAP Content-Formats? -- ct (or bct) contains a text value that is not a registered Content-Format-String? -- ct (or bct) contains a valid Content-Format-String, but an unregistered Content-Format? Or is this application specific? From nobody Sun Sep 19 13:15:49 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743C23A3BDE for ; Sun, 19 Sep 2021 13:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxUV-RNI288l for ; Sun, 19 Sep 2021 13:15:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C003A3BDC for ; Sun, 19 Sep 2021 13:15:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A8FB0187C9 for ; Sun, 19 Sep 2021 16:22:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qxFZ92p5vqEF for ; Sun, 19 Sep 2021 16:22:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 98D0B187BF for ; Sun, 19 Sep 2021 16:22:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4B48F15B for ; Sun, 19 Sep 2021 16:15:33 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] CoAP option for Well-Known Uri-Path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2021 20:15:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Has anyone considered a CoAP-Option that would compress well-known prefixes? So, instead of: Uri-Path ".well-known" Uri-Path "brski" Uri-Path "sen" one could have: Well-Known-Uri-Path [CBOR-int from to be created .well-known Registry c= olumn] Uri-Path "sen" Takes some coordination to get it deployed, but in some greenfields we could do this now. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFHmmUACgkQgItw+93Q 3WW08wgAwdbHPH8JJAOnLxUUkZKrNgZ5wyq0jodMtE1fwbQ5CmRsCWbDdJTHGpl5 4h9s1dXLbrLX5r89YSwezQpuILQXywIW+nvsc4Wu0eaGkMdHUeH6AxAXXmrNwEmn 6Je1q1gnxodOPlEjwegD5AXNocQGsDHZimVkV37xarq3J911a4o1XI+vvsYlYFrM UK8gvrioC7az+7siByr/lLKzOcpWF1egZ7wGyl0hYYXohdzJ+NEbotzIo3tjddBu /t3ib2phR0vnLiaPR3SFtvejVlI5F6DiKduHoQ+NiHGYkUU9Cc2NsYw4g3A2gdQS +u25bo9l39/iNAxBjH/BDX/CAiVc2w== =bZQk -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 19 13:53:28 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351373A3E00 for ; Sun, 19 Sep 2021 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=0.941] 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 NPk0XLpdI9p5 for ; Sun, 19 Sep 2021 13:53:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2093A3DFF for ; Sun, 19 Sep 2021 13:53:21 -0700 (PDT) Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id C6D691F448; Sun, 19 Sep 2021 20:53:17 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 496FA1A0529; Sun, 19 Sep 2021 16:53:16 -0400 (EDT) From: Michael Richardson To: core@ietf.org cc: "Murray S. Kucherawy" X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sun, 19 Sep 2021 16:53:16 -0400 Message-ID: <106211.1632084796@dooku> Archived-At: Subject: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2021 20:53:26 -0000 --=-=-= Content-Type: text/plain Hi, in Murray's review, he asks about why we have two ways to encode keys for YANG-CBOR. This review comment is captured at: https://github.com/core-wg/yang-cbor/issues/54 A generic comment about the operational issue of supporting TWO ways to encode a data node: either normal string or the SID. This means that either there is a 2-way negotiation mechanism or that all CORE nodes must support both encoding and have agreed on a common SID mappings. Section 7 only briefly touches this issue with "Content-Type" but not with "Accept". -- Section 4.2.1 & 4.4.1 -- BTW, I like the idea of encoding a container with sequential SID and the delta CBOR encoding ;-) I also wonder about this. I think that the SID concept is advanced enough that we can just rely upon it. Murray's comment is that if we support two things, then an encoder needs to pick one, and it's likely wrong. Since this is often data at rest, there is no possible negotiation either. I propose to remove section 4.1.2: 4.1.2. Using names in keys CBOR diagnostic notation: { "ietf-system:hostname" : "myhost.example.com" } CBOR encoding: A1 # map(1) 74 # text(20) 696574662D73797374656D3A686F73746E616D65 72 # text(18) 6D79686F73742E6578616D706C652E636F6D -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmFHozsACgkQlUzhVv38 QpAEqAgAm/xdCahA28NVx8Hkki73c1VS+VYaSVhWj9jaVdrYLB/upi3bVvk7ECIy p404v+sbP24hx5U6lWX/XdMajfoT/ctyCgEYBJMQFtzuwrN+949cKKsGqNBmiy1m +KKFpZYir4oHfkMY+bcZZa6tdM0nGuxeIEPubIgomLhW1HI7pS0Uu357D9rh7lQ3 v3YJFIQkUVpkDlUff2nDB6wwR9dGOZgGUDn+rF3XUbUOOg+6MW1No+sCmMqMthTI FjWUDb8ESyocgtaD55288mjTjAS7vvn8XTCnHoilX9ECcYmBVBSjmj6tHp6lBt+9 R+FUp+4Czz+xL8Xgkt4A0lU7n5WYiw== =NMf2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 19 23:10:21 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C016F3A100F for ; Sun, 19 Sep 2021 23:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=0.941] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsDISI_yq0Yq for ; Sun, 19 Sep 2021 23:10:14 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 3BB033A100D for ; Sun, 19 Sep 2021 23:10:14 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id k10so15446551vsp.12 for ; Sun, 19 Sep 2021 23:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IWvpU2L9LjmVQQPI8zyOFe4Of6eRJFqlS4EaVvHU3jY=; b=k30jE3R/LKhr5wsgOnXaN8Uti3b4FeP5xhfZdh1C4x3x7kJoJaWKIY10Lz1RITn47N pneS98GCKI7yRnneb6AH9sfATvcf8J/2Cd8Rm6pLI1PzXxXcJJups9gCLmDn7B6NiGez 6z2YCsmH5hVBJOUyxS+pTTX/qVtt226ncpTeMNixZQNaztKRg1ZLfGgIMSVQWPOSwEhv QYbFShAl1qZWt4ZoSUOKYUAaEn1xEwL/6UQ83QZfjp9z/4inQ8kccaVWpGReCfiORQo/ 8RcP73XD5BBLN/1Ndz6TKAyMh3tK3f7kDzL/gR/0BvHQd3i9Md5Ta1XS05e6B/oEU2u1 m8Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IWvpU2L9LjmVQQPI8zyOFe4Of6eRJFqlS4EaVvHU3jY=; b=eafeIy6Qc3OUY2jlpCbpbAt9d3psYT653fW/tO8lc+n6MHPvXPw3qQkQbkkyd9NuBv pcYR1qCfULbbcYDk9UfVUFrs6a69ADe5P0p9eF+hBSfozql4QJdP4Dcfe38hyzgXywKH +cCgX5y/gsRZ/wCZNj3yDi78irafXtDW1V9vJ3nDSRsljEvVpg1IxqnbUbkqh2NY0Au8 Y+UlCfBjFHEmUmkHErccJHetmZ4oxMQeXxs/2hn76ag3Zh07HlrUobNW+xs0dhDi/FTP Q2OTOamOIpnOEOPsoA7UzCiX56dVQLi8VPkUwEMXx3ccpQSQFCYCqjsnsM8PlFfP8jBi s3TQ== X-Gm-Message-State: AOAM531VpMz4EnPmn/HPhnqzWBNNKMKpJmJLVsMDmphRqimlzVjP1vei JGc8VFmM85/uROxAKZ8KzySZw/19PeiV1eX4lr+bKCxKsBg= X-Google-Smtp-Source: ABdhPJxY2ZbP+/NjOizPKzejwa6xMroiIsLyaNTyFcoaeVxCYNc0LMUQrIraMo1lHSs0zSA4s4qSIhOts7TBrmRrYh4= X-Received: by 2002:a67:b005:: with SMTP id z5mr14548293vse.13.1632118212877; Sun, 19 Sep 2021 23:10:12 -0700 (PDT) MIME-Version: 1.0 References: <106211.1632084796@dooku> In-Reply-To: <106211.1632084796@dooku> From: "Murray S. Kucherawy" Date: Sun, 19 Sep 2021 23:10:01 -0700 Message-ID: To: Michael Richardson Cc: core@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f635705cc672234" Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 06:10:19 -0000 --0000000000004f635705cc672234 Content-Type: text/plain; charset="UTF-8" I'm happy to take credit for a keen observation such as this, but this was actually Eric Vyncke. -MSK On Sun, Sep 19, 2021 at 1:53 PM Michael Richardson wrote: > > Hi, in Murray's review, he asks about why we have two ways to encode keys > for > YANG-CBOR. This review comment is captured at: > > https://github.com/core-wg/yang-cbor/issues/54 > > A generic comment about the operational issue of supporting TWO ways to > encode a data node: either normal string or the SID. This means that > either there is a 2-way negotiation mechanism or that all CORE nodes > must > support both encoding and have agreed on a common SID mappings. Section > 7 > only briefly touches this issue with "Content-Type" but not with > "Accept". > > -- Section 4.2.1 & 4.4.1 -- > BTW, I like the idea of encoding a container with sequential SID and > the delta CBOR encoding ;-) > > I also wonder about this. > I think that the SID concept is advanced enough that we can just rely upon > it. Murray's comment is that if we support two things, then an encoder > needs > to pick one, and it's likely wrong. Since this is often data at rest, > there > is no possible negotiation either. > > I propose to remove section 4.1.2: > > > 4.1.2. Using names in keys > CBOR diagnostic notation: > { > "ietf-system:hostname" : "myhost.example.com" > } > > CBOR encoding: > A1 # map(1) > 74 # text(20) > 696574662D73797374656D3A686F73746E616D65 > 72 # text(18) > 6D79686F73742E6578616D706C652E636F6D > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --0000000000004f635705cc672234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy to take credit for a keen observation s= uch as this, but this was actually Eric Vyncke.

-M= SK

On Sun, Sep 19, 2021 at 1:53 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Hi, in Murray's review, he asks about why we have two ways to encode ke= ys for
YANG-CBOR.=C2=A0 This review comment is captured at:

https://github.com/core-wg/yang-cbor/issues/54

=C2=A0 =C2=A0A generic comment about the operational issue of supporting TW= O ways to
=C2=A0 =C2=A0encode a data node: either normal string or the SID. This mean= s that
=C2=A0 =C2=A0either there is a 2-way negotiation mechanism or that all CORE= nodes must
=C2=A0 =C2=A0support both encoding and have agreed on a common SID mappings= . Section 7
=C2=A0 =C2=A0only briefly touches this issue with "Content-Type" = but not with
=C2=A0 =C2=A0"Accept".

=C2=A0 =C2=A0-- Section 4.2.1 & 4.4.1 --
=C2=A0 =C2=A0BTW, I like the idea of encoding a container with sequential S= ID and the delta CBOR encoding ;-)

I also wonder about this.
I think that the SID concept is advanced enough that we can just rely upon<= br> it.=C2=A0 Murray's comment is that if we support two things, then an en= coder needs
to pick one, and it's likely wrong.=C2=A0 Since this is often data at r= est, there
is no possible negotiation either.

I propose to remove section 4.1.2:


=C2=A0 4.1.2.=C2=A0 Using names in keys
=C2=A0 =C2=A0 =C2=A0CBOR diagnostic notation:
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"ietf-system:hostname" : "myhost.= example.com"
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0CBOR encoding:
=C2=A0 =C2=A0 =C2=A0A1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0# map(1)
=C2=A0 =C2=A0 =C2=A0 =C2=A074=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 # text(20)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 696574662D73797374656D3A686F73746E616D65=
=C2=A0 =C2=A0 =C2=A0 =C2=A072=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 # text(18)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6D79686F73742E6578616D706C652E636F6D

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--0000000000004f635705cc672234-- From nobody Sun Sep 19 23:22:31 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E78A3A1152 for ; Sun, 19 Sep 2021 23:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL3tpNYHoYBF for ; Sun, 19 Sep 2021 23:22:25 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.88]) (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 C82D13A114F for ; Sun, 19 Sep 2021 23:22:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KnZnAnb5qHa8KitFw8PAOHgRWyvABA/TQiPmfH1FQ5YvVAw5/es2+ibDKeIZfd/CQHXpwJt3nX8d0cls3vclzks89XiJNByjlCo2c8OOrF96A8hkKhNBB6Q2X7TMKhJaWE7R7k+FNG9eEG7rd3Tvk/yl1zsuvd4bKdSM7/NHOQMLOCP2mDFkpthxZdKDRiAqr/n8eNz8XqTsdLhUxpCxhdf90x+x9hUbtVEjClMagAxMdL31vFzTDCwbOdCvrZHP7WQJvjTXDWwz5mM+eINI1oTugiJy4nzRjEqbSkBzSoRuY+h52aCofH4g0Sa5Fa6GeppL3TXW/UJbKQ4QHAanCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l64jrpO1RNUKpP2kRUbkbNXbyJpHyPY0GU4xURuV5f4=; b=FKiSSO0TvWYjYAlWD2BAiS3/BZp/VATRhhKZdP1XvBIm9D3nnJ10lAur49Z4LRmsbyh17CgXfjZsavBD1Por4m7H+hpr5yZhfxGmBbUyNCrE8Mu4dErf3an963hFy46y1pyeUks75vg9KBNPia3ZZOG/M59/tFwVXV9MJCaSZtdHzHwH8JEK7XIV0kap4wEtV1e98Y7Xo79LYubhH2XIDW7fng9maaI2Qwl2ng7cR0d5HW9ncpXMRGmVzRT0V7i46MLOryhNWRtHMZJZZcuZ45BvgesLXlgqGFI//yGjDMvj61B1b8mw+wjEePHv1Kk4RSyPXZVu2sKqG8yl1mYJmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l64jrpO1RNUKpP2kRUbkbNXbyJpHyPY0GU4xURuV5f4=; b=aaHcc9UY6K1W7nGjK78y3MxnnCFdWDN3VNaOsdXyltULA0rNkHhyfGZb7mmiVxvLkqR5g4OVJ+tEvSsh+05jDrth2DKyUsg985VPkCHAlMPedm6hKdmy7R90UxzbESA3lapHwbmrWgqHI5CYXfu6o2bOdExGULr5LM3kY/sqdA8= Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0701MB2089.eurprd07.prod.outlook.com (2603:10a6:3:2a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.11; Mon, 20 Sep 2021 06:22:15 +0000 Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e%7]) with mapi id 15.20.4544.013; Mon, 20 Sep 2021 06:22:15 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Michael Richardson , "core@ietf.org" Thread-Topic: [core] CoAP option for Well-Known Uri-Path Thread-Index: AQHXrZMvMjXb/CxI90ikc9qDkp9hRauslhUA Date: Mon, 20 Sep 2021 06:22:15 +0000 Message-ID: References: <19899.1632082533@localhost> In-Reply-To: <19899.1632082533@localhost> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2cc55615-ba44-4a1e-7db7-08d97bfefd7c x-ms-traffictypediagnostic: HE1PR0701MB2089: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c3+kPVeuCMhv32QssIdIjDBNtgjx6F/siE4DyPgmriVOQi2mZ8GfeiCG7FCiHgKlKQ1nrn935bzoUkngRkLSNvtkck0XsBu78GiGyKfzv9dVSeCn9sxT81QmT95ikblAannodF3zrOh5BNCppVbf07F5ZVnB13f9CTk2/s2YyKOm31nrNA4IAKgEipyNHEj2b7txUZXMi+8sjn9Fw6XODuTZi6mfHIuodM5Y2aLtB4URJVgt7GIoMzQtRsxgxmLXo85x7GrddjygP+qfLIDrk4XEKtmr/ewNlTcv6jSd+iuC2vpYpjoC5DvWxxpQ1wHlhaBK9R3uz+qkx1kVFfk/6XHac3VS/+PjW/YpkL0BSyjRls39nQfhDA09gRYM4ZRUJfR+auLKd47vzcjOXWq/yLdRoXw/3ZW1QvJVLiqCmDR3tdl3wIisdFReGB7w2fCUOodF42U2+cKz+Eg5BWx8u6QBDOn61CZqF8jZhcgMMyjvN1lybUzFmutOA4yd113IELqkvZj8a1TlHpiVCVGXsEzBEYgA9DygAxRZd/+xKG2mEPYfXzzvgSU136n7ZBlmH2haC0cfnrhCGeObIbdP6Jj8KFo4tn77Wx3EZ4Xvnkz+BZavmvdMCCz58UCm9p3K5Q6pVBMea+TPalveUruwJMCKz7RlOM/AiysWFmUTNbjDDlMTf6i/FzQqruTa8u6MOvCaczSf/N6uC49TuudT3GivTf0F1MdFbi7Onpbs2ojVspATLF8Bwa7/g/0BA3deKZa6rbnYsqS3pTKfEc5IyAydbb0EIVPSal+/NflKc+D5WHCCbIjYZaeQeQm20wd1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(110136005)(2906002)(38100700002)(4744005)(76116006)(71200400001)(66946007)(33656002)(122000001)(66476007)(66556008)(64756008)(85182001)(66446008)(85202003)(6512007)(5660300002)(6486002)(316002)(478600001)(2616005)(8676002)(36756003)(186003)(8936002)(6506007)(26005)(86362001)(966005)(38070700005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SkI2VHNKRlc5TG50M3lDVG44OUFqQ09mQ1RKQ1NpanJHOG82VkVxeEt4RC9s?= =?utf-8?B?M1hVcFRWNW1id0dzaDlSOXFNc21mQzZKYUM3anFFY1o4UG5VTmJGVjY3MFBB?= =?utf-8?B?ZlpTS1NRaCtzUnJ1MUMrLzB5RVZBSWNHcmhxcERQcVVSaGVBeGVoWG5yTHlo?= =?utf-8?B?eXBLVXZmcU1UanQwb1JhNk1HMjd6RjNqU08vL1U2aG1WYXU2Qy9NcGFIcDU1?= =?utf-8?B?QjhPcm9wWWZRaStFRXdVTlE2YVVOd1hFcHkvdkFyaGhNL0Fab2Z0VVJhMzhZ?= =?utf-8?B?aTJnSUtnVURSVCtnNVozTjhYbVB3RGJSRE5LV0xiYng0OFZ4MEtxU3E4OUNs?= =?utf-8?B?Rk9FZnVOQUN6RnE4ZXV2KzRDRkp6ajFyVVgzcnBqQk5CMGpwRzM0MGhydHdG?= =?utf-8?B?L1dJNCsxNkQrT1pibHd4R0tqaFloWlV2ZjJvUUcwLzgzRVdCV01VcXJHbUlL?= =?utf-8?B?Sk1yamF1QlNTaCtHWWpJZlRpb3luc1B1cjJuRWxHUlF2c2ZreE1uVFovUU5U?= =?utf-8?B?ODdQSDBBR3BXTEIzeGdpVWJ1bFFHdXdiME5PTER2N2FDRHdUY25qb2Z3Zm1y?= =?utf-8?B?Q3A0NHExTDAyeXhLSXNyS0U0VldhTEZPR1ozYytDTnpGQksxU0ZERGVTRGNG?= =?utf-8?B?TER4YnZzT1duaS9tWGFiVlZVTnk1TGw2SzZLR0greUtaMGJxNW41MTF3L2Z1?= =?utf-8?B?UjBJVmVYMFpQNllyVStSYWRURzN3WkJjaHB3cWNLcVdOK0RFQXZkbE1NUWk1?= =?utf-8?B?Q0lTcmR1c1JyWmpLQnVMR1JHTnVUVlF0SHFLWStWVUdXazNWUnA1cEtKNnFR?= =?utf-8?B?cXdJYXdRUnV1YXByK1ZRTTM3YW1sNDhoSCtpYm1xcDRMajBjd3B2YWhzdWFa?= =?utf-8?B?OTRiY1d5K2dtRzFEcmt0QUl4NlYweENPS2pLaFdWUVR6aTJYd0xsN25GS2Zk?= =?utf-8?B?OUhzNFZQa3BCc3BrTVgrdWJIWWFQSUJYS041bVVIT1lhM2xUUmVxRHUzL2o1?= =?utf-8?B?dUF6RlJXbUVrTnd2aGJhN3J4YkovejFyRUI2ejQySHVjS0NYWEIvajhxVUJa?= =?utf-8?B?cSs2UDE4MXhRWVFTRG1sOTF5ZFpGT3RiNVZnbWxmaWxjc3dwa3doYmdNa3dr?= =?utf-8?B?MlFtQnVlN0lodUdMQTdLKzY0QXNDSldidmhINm5uT0JDNXB4a3BWSEE4Ymwz?= =?utf-8?B?VjZ6OTJlUHFIVWkrT1lKWkJkVFFSZlBvOVU2azJMZmxEbkg1aFlKSy82S3Ra?= =?utf-8?B?M3NRdGlNb05qeDZXUm9mbmw2bG5mNHh5Rm5MMzd0NlFnb09LZFJ2OEN4a2Jh?= =?utf-8?B?TXkzanNxb0I2d0J6Tk9IdWh1TG1aVWFnbUlOSmRvNDBUOFAzbXhYcWZ4RVBQ?= =?utf-8?B?ZHJRN0hkVUpHRXZ6ZmdQZm1md0h6SUk4bWExZjBuQTU5enZDWEpyUEFQaSti?= =?utf-8?B?R3dzK2lnUmRVaHJPVmtaSzl2cjNqUFRpTXdKUEs1L1VEVnlyRjVzRmxJdTlE?= =?utf-8?B?eGNtTGlsSGpJQlNBSFpld3A2cllxeUNDZWVJeDFLZDhUYWY2L0hiU2E0enV5?= =?utf-8?B?NG93aGU0bWpLMGVIb2V3d3dSQzdlemw3cURPNTJpcGxZalhCVFVFVE1HT0dz?= =?utf-8?B?ejdkaXNRVzliN1NGTGVHZnc5TTBXdGlYVkNBMnh5Zmo4cEhYUnVZeko2ajNT?= =?utf-8?B?WHFtN0paeEhhdzJ3RS9VaVhVTGtLSjJRVnlzc0h4QXZpMS9oM1dJUWV5Q3JZ?= =?utf-8?B?ZHZFOVZxNXFaajRkcWxhNFQwV0V0eklpQ0p5UXc5TGdTc015RjB0aGtEQXBO?= =?utf-8?B?Smg4eGtXWHdRUXdsNVhFQT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3FA9BC4896ABFD4BA7BCB4523AFF2258@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2cc55615-ba44-4a1e-7db7-08d97bfefd7c X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2021 06:22:15.2650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6md7fG3YOwClf6PqfrHwjpZcGwc+GhTtOioJ1EHtfFPPBzJsiHgS6KJaesOWdYUZswV0qeklz/kjSULOwSiXAK5w8eNZ6CbjOBWitMz7dzs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2089 Archived-At: Subject: Re: [core] CoAP option for Well-Known Uri-Path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 06:22:30 -0000 DQpIaSBNaWNoYWVsLA0KDQpEbyB5b3UgbWVhbiBzb21ldGhpbmcgbGlrZSB0aGlzOg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMS1jb3JlLTA1L21hdGVy aWFscy9zbGlkZXMtaW50ZXJpbS0yMDIxLWNvcmUtMDUtc2Vzc2EtY29yZS1vcHRpb24tZm9yLXdl bGwta25vd24tcmVzb3VyY2VzLTAwLnBkZg0KDQpHw7ZyYW4NCg0K77u/T24gMjAyMS0wOS0xOSwg MjI6MTYsICJjb3JlIG9uIGJlaGFsZiBvZiBNaWNoYWVsIFJpY2hhcmRzb24iIDxjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQoN Cg0KICAgIEhhcyBhbnlvbmUgY29uc2lkZXJlZCBhIENvQVAtT3B0aW9uIHRoYXQgd291bGQgY29t cHJlc3Mgd2VsbC1rbm93biBwcmVmaXhlcz8NCiAgICBTbywgaW5zdGVhZCBvZjoNCiAgICAgICAg VXJpLVBhdGggIi53ZWxsLWtub3duIg0KICAgICAgICBVcmktUGF0aCAiYnJza2kiDQogICAgICAg IFVyaS1QYXRoICJzZW4iDQoNCiAgICBvbmUgY291bGQgaGF2ZToNCiAgICAgICAgV2VsbC1Lbm93 bi1VcmktUGF0aCBbQ0JPUi1pbnQgZnJvbSB0byBiZSBjcmVhdGVkIC53ZWxsLWtub3duIFJlZ2lz dHJ5IGNvbHVtbl0NCiAgICAgICAgVXJpLVBhdGggInNlbiINCg0KICAgIFRha2VzIHNvbWUgY29v cmRpbmF0aW9uIHRvIGdldCBpdCBkZXBsb3llZCwgYnV0IGluIHNvbWUgZ3JlZW5maWVsZHMgd2Ug Y291bGQNCiAgICBkbyB0aGlzIG5vdy4NCg0KICAgIC0tDQogICAgTWljaGFlbCBSaWNoYXJkc29u IDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyAp DQogICAgICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5k IFdvcmxkd2lkZQ0KDQoNCg0KDQoNCg== From nobody Sun Sep 19 23:30:06 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB793A11DF for ; Sun, 19 Sep 2021 23:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAjRly5zIlrM for ; Sun, 19 Sep 2021 23:29:58 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069853A11DD for ; Sun, 19 Sep 2021 23:29:55 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B94C4400AD; Mon, 20 Sep 2021 08:29:51 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 491CFD7; Mon, 20 Sep 2021 08:29:50 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:d6f8:77c2:2f6a:14e7]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AF4E010A; Mon, 20 Sep 2021 08:29:49 +0200 (CEST) Received: (nullmailer pid 297219 invoked by uid 1000); Mon, 20 Sep 2021 06:29:48 -0000 Date: Mon, 20 Sep 2021 08:29:48 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Richardson Cc: core@ietf.org Message-ID: References: <19899.1632082533@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UVhvXOejyegZ0wd1" Content-Disposition: inline In-Reply-To: <19899.1632082533@localhost> Archived-At: Subject: Re: [core] CoAP option for Well-Known Uri-Path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 06:30:03 -0000 --UVhvXOejyegZ0wd1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 19, 2021 at 04:15:33PM -0400, Michael Richardson wrote: > Has anyone considered a CoAP-Option that would compress well-known prefix= es? > So, instead of: > Uri-Path ".well-known" > Uri-Path "brski" > Uri-Path "sen" >=20 > one could have: > Well-Known-Uri-Path [CBOR-int from to be created .well-known Registry= column] > Uri-Path "sen" >=20 > Takes some coordination to get it deployed, but in some greenfields we co= uld > do this now. I have a rough sketch, presented at [1]. In its minimal form it'd only be a replacement for Uri-Path (ie. .well-known/brski/sen would need a point just as any other brski path), but "prepend to actual path" semantics are feasible at slightly increased processing effort for those who use it. Main stopper for further work since May was that I'd like to build it on SCHC semantically, but if urgency comes to it, the option could just as well be defined, and the SCHC semantics retconned into it. BR c [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --UVhvXOejyegZ0wd1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmFIKlgACgkQOY0REtOk veEDAg/8CyV1JnTUcIAtDA1yC2zwShz3BuwrNXEwhQZdn3s+m1dH9usi/9npNcUK 3AHuXsaxl2YmB7vCrIQvilXVVL3uvE8SjEi4uG9LMjjkrQEJtqp4DhjUf3IqK5sF Ekv4COt1xkjZZaruFqILWfw1+GMswCOF4bqC/EMo/ZtX+ZVFJE4fGN2cL4To0T0b KoVCOvybshjktMDxZq3nmlHPHhJ0UpwLn9Yyemk7hE8vaE4eB5k7TmPeLJ8AbWz9 JMLl9/7aZnxDEDAGnEiYEMFXg0CtgsHJdyTbhXfPHsRioXcWZgVOC54uSIvMHmnQ PddUJssmA7+eunh0XPcdl8sqRZWQRihQgu6r83AZGuLc1UTrkbb5Os8fQeAbZya+ FqQVC3o26n8GpAvEHjQ736d+jsV0LvL2JiDM+LhlFi9PebVjs5wLt5OrJ24cS1wR KbCqg1OFvWXXR2NNfP1auGeYggwiH0a47JB7tsyyuJNh0cii6mA1YUkceKSjbcwg +nCeTNk3/AzpZy19CM/Qc8VP8WEt0KKX47e+pjtWYh00gvLCPBxsX5kbI0sQzhKD rU3+l7TTWMLZ+9s4kk/Vs4BHD+HA/6YpiAh3XzrJPDMrg5GuHMi5EeGxs660geIG MddoRT1CdAHmpufWQr/Fu8cI89ALbhm5C/XSbPWYP6KWW97KSuA= =Y9+Z -----END PGP SIGNATURE----- --UVhvXOejyegZ0wd1-- From nobody Mon Sep 20 01:45:15 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEE53A1A7C for ; Mon, 20 Sep 2021 01:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTlwv1AlG88L for ; Mon, 20 Sep 2021 01:45:09 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647703A1A7B for ; Mon, 20 Sep 2021 01:45:08 -0700 (PDT) Received: from smtpclient.apple (ip-109-43-50-15.web.vodafone.de [109.43.50.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HCdRN6lybz2xJx; Mon, 20 Sep 2021 10:45:04 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-6F9E16A9-3F24-4E34-AE0E-0A9EDAC0CAB2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: <19899.1632082533@localhost> Date: Mon, 20 Sep 2021 10:43:16 +0200 Cc: core@ietf.org Message-Id: References: <19899.1632082533@localhost> To: Michael Richardson X-Mailer: iPhone Mail (18H17) Archived-At: Subject: Re: [core] CoAP option for Well-Known Uri-Path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 08:45:14 -0000 --Apple-Mail-6F9E16A9-3F24-4E34-AE0E-0A9EDAC0CAB2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the main reason that we didn=E2=80=99t do this right away was that t= he original Usage (. Well known core) was relatively rare and implied even l= arger data. But with other protocols using wk it may start making more sense= . Unfortunately, there is no option position left that would keep the correc= t order in the Uri. Oh well.=20 Sent from mobile, sorry for terse > On 19. Sep 2021, at 22:16, Michael Richardson wrot= e: >=20 > =EF=BB=BF > Has anyone considered a CoAP-Option that would compress well-known prefixe= s? > So, instead of: > Uri-Path ".well-known" > Uri-Path "brski" > Uri-Path "sen" >=20 > one could have: > Well-Known-Uri-Path [CBOR-int from to be created .well-known Registry c= olumn] > Uri-Path "sen" >=20 > Takes some coordination to get it deployed, but in some greenfields we cou= ld > do this now. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consult= ing ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail-6F9E16A9-3F24-4E34-AE0E-0A9EDAC0CAB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the main reason that we didn=E2=80=99= t do this right away was that the original Usage (. Well known core) was rel= atively rare and implied even larger data. But with other protocols using wk= it may start making more sense. Unfortunately, there is no option position l= eft that would keep the correct order in the Uri. Oh well. 

Sent from mobile, sorry f= or terse

On 19. S= ep 2021, at 22:16, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
=EF=BB=BF=
Has anyone considered a CoAP-Option that would compre= ss well-known prefixes?
So, instead of:
&nb= sp;  Uri-Path ".well-known"
   Uri= -Path "brski"
   Uri-Path "sen"

one could have:
   Well= -Known-Uri-Path [CBOR-int from to be created .well-known Registry column]
   Uri-Path "sen"

<= span>Takes some coordination to get it deployed, but in some greenfields we c= ould
do this now.

--=
Michael Richardson <mcr+IETF@sandelman.ca>   . o O= ( IPv6 I=C3=B8T consulting )
     = ;     Sandelman Software Works Inc, Ottawa and Worl= dwide




_______________________________________________
core mailing list
core@ietf.org
https://ww= w.ietf.org/mailman/listinfo/core
= --Apple-Mail-6F9E16A9-3F24-4E34-AE0E-0A9EDAC0CAB2-- From nobody Mon Sep 20 05:09:54 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C72F23A1092; Mon, 20 Sep 2021 05:09:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez , jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <163213978178.15913.12022697613892578284@ietfa.amsl.com> Date: Mon, 20 Sep 2021 05:09:41 -0700 Archived-At: Subject: [core] Lars Eggert's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 12:09:42 -0000 Lars Eggert has entered the following ballot position for draft-ietf-core-senml-data-ct-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The references to IANA registries could be informative, since RFC7252 is already normatively cited. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 4. , paragraph 2, nit: > t" fields (explanation/comments in parenthesis): * "60" (CoAP Content-Format > ^^^^^^^^^^^^^^ Did you mean "in parentheses"? "parenthesis" is the singular. These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/senml * http://www.iana.org/assignments/core-parameters * http://www.iana.org/assignments/http-parameters * http://www.iana.org/assignments/media-types From nobody Mon Sep 20 05:10:03 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823713A10BC; Mon, 20 Sep 2021 05:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5qKtO0DEm1L; Mon, 20 Sep 2021 05:09:47 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 9931D3A10C0; Mon, 20 Sep 2021 05:09:46 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:e984:671f:78cf:fcd1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1A3B9600639; Mon, 20 Sep 2021 15:09:34 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1632139774; bh=v0lkOIEp/Mhx2DVr1mjrBbCAFZjcsgAyCAeSXD74mKI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=az8ec7lrgLyPnv9dFk6nyrLg2rka/5qM3Nke32wIiyabbB+q9W6vvsv/nbb4NqTfp YJSdMz4xI/Tm9FOvNkLLFRZiyEWT7ItBXabPO/n8215UaVywE/LQXTjaL5sHymKDwT A+ikALTTmEvMnMvH47rwJ857S2KmAyRZCAF+TkkI= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AD1292A5-2DC5-4AED-B336-897B55A5CF83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 20 Sep 2021 15:09:33 +0300 In-Reply-To: <163092350360.5169.1299765677300317336@ietfa.amsl.com> Cc: General Area Review Team , last-call@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, core@ietf.org To: Christer Holmberg References: <163092350360.5169.1299765677300317336@ietfa.amsl.com> X-MailScanner-ID: 1A3B9600639.A629F X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 12:09:58 -0000 --Apple-Mail=_AD1292A5-2DC5-4AED-B336-897B55A5CF83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Christer, thank you for your review. I have entered a No Objection = ballot for this document. Lars > On 2021-9-6, at 13:18, Christer Holmberg via Datatracker = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-senml-data-ct-04 > Reviewer: Christer Holmberg > Review Date: 2021-09-06 > IETF LC End Date: 2021-09-06 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: I have reviewed the document. I have one technical comment, = but the > rest is mostly editorial. Related to that, I do think the document = could use > some editorial clean-up, e.g., when it comes to consistent = terminology. I think > it is also good not to assume that the reader knows CoAP, and to make = sure the > appropriate references/explanations are present when CoAP is referred = to. >=20 > Major issues: N/A >=20 > Minor issues: >=20 > Q1 (TECHNICAL): >=20 > What happens if the receiver does not support the "ct" value? Is it a > server-error? If so, what response code is used? I think that should = be > specified. >=20 > Nits/editorial comments: >=20 > Q2 (EDITORIAL): >=20 > The text should use consistent terminology. See below for a few = examples: >=20 > The Abstract says: >=20 > "The Sensor Measurement Lists (SenML) media type supports multiple > types of values, from numbers to text strings and arbitrary binary > data values. In order to simplify processing of the data values, > this document proposes to specify a new SenML field for indicating > the Content-Format of the data." >=20 > First the text talks about types of values, and then suddenly the > Content-Format of the data. >=20 > Content-Format is the name of the new field - that is not what you are > indicating. You are using the new field to indicate something. >=20 > Also, "Content-Format" is also used by CoAP, so please check that it = is clear > what is referred to whenever mentioned. >=20 > The text in Section 1 says: >=20 > "To facilitate automatic interpretation it is useful to be able to > indicate an Internet media type and content-coding right in the = SenML > Record." >=20 > ...and, the test in Section 7 says: >=20 > "The indication of a media type in the data does not exempt a = consuming > application from properly checking its inputs." >=20 > Now the text suddenly talks about "an Internet media type and = content-coding", > when it earlier (in the Abstract) talked about value of type. >=20 > Q3 (EDITORIAL): >=20 > The text says: >=20 > "The CoAP Content-Format (Section 12.3 of [RFC7252]) provides just = this > information" >=20 > I think it would be good with a little introduction on how CoAP is = related to > all this. >=20 > Also "provides just this information" probably needs some re-wording. >=20 > Q4 (EDITORIAL): >=20 > Section 6 contains the ABNF for the new fields. >=20 > Is there a reason you don't define them in the same way as the basic = field is > defined in RFC 8428 (there is no ABNF)? >=20 > Q5 (EDITORIAL): >=20 > The text in Section 7 says: >=20 > "The indication of a media type in the data does not exempt a = consuming > application from properly checking its inputs." >=20 > I assume that by "its inputs" you refer to "received SenML data". >=20 > Shouldn't properly checking inputs be a generic CoAP security = consideration? >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_AD1292A5-2DC5-4AED-B336-897B55A5CF83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmFIef0ACgkQVLXDCb9w wVfKGw//fX5UvXQ/mpTzdTLSkKNa161h5nTgMC2y2ehHnSAEPf5s1J4cbH7LJyIr A1vMihc8wQnpO7+EI7PgOcUIng3793w4mqUIvYq3Cl1EN/Ux4EH0V1omBoVllOCV hLHHsrd3AqT29T7Ce4uTtqdYtzYarbJFtdQBxQKboYw734GDPRgBZF76iyl+nGt8 oa9SEgPLfoFRiwAqmNyVepZmk0+taunzJl9vv1nrcygKXxYWzGWsFohJsHR2Or1Q p/h+WWjiY4kgp1EeVf2cFDOQMt7wqIpX57kzyeiqe0jdD7Bq97JxpjVvR+8X4LCd BON7EFXUTHTiD3dacd9kx2aLSNbFc0aUQwL0RIjKx8ZxAXi9YP+HpevKe70ab9+r YQvtLdn2dmJW/tM1HP5faU1kBHKhvQ0MyBzDgQsQ1rcJb5wBTbdI5p+RXQUHNYTz mlUntITaD7mrjywFSeDHMeNOCMDiqsoOKF0ZBvUwws6TKV7VzyOL7c9Oa0uo5DtY 3TWBs249KMI7co/ACTojyMofFNLKpvir7UTG2JlWgrrdt49Efnk4R/7bUFV4BjuM rf9RXTLVvKBdo1oC7e+Hl6adDSBt2KTc50rtkJiaD2eVLn/goTMyQmvDf++CXCHO ddrj9FYyu2VUzIaVroA/DNEN9ms40BJ80lHl6Z0Qp72e1Qb963E= =U73Y -----END PGP SIGNATURE----- --Apple-Mail=_AD1292A5-2DC5-4AED-B336-897B55A5CF83-- From nobody Mon Sep 20 05:17:59 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD33A003C for ; Mon, 20 Sep 2021 05:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffHHQbWhVXVX for ; Mon, 20 Sep 2021 05:17:52 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10117.outbound.protection.outlook.com [40.107.1.117]) (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 3D8703A0100 for ; Mon, 20 Sep 2021 05:17:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cJpeF48UUNXjX/g1i/Xb0X2MGUWvJdvDimvwxwrR787ljHRqMMz/xHCFnykZN63rR9V2iWMfdl1l7qIqEVREgYf1nb8iBwUVfwpbMHpOMw+7tk/g2rejKQbTqRQaJKxxXWHV9/8mH+wH2HP0jD6XfIiWVK0mKCERafPs7cHTNj0uVTv3yh0KggY2AaF9dbFL0sW9pPuE6vC5nPckCiI55nirzKVhAVZkiauv/1Laz8ol73cA9YWs2Wi1ofRD2XckhlY9GwE/OVHBUs6BMLP/Xt10X3GdJzeHuK1teVi2WHgWrjpLziqF+CJut9N/vD6AaTaG4GNKjVu1gpGTuor4Kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EFqUpFkvPQdV4r9XdQszBgf1ek54JSpzw5Ve7umwfjo=; b=NEOn/FV6qeY2XY26MnwDDZIwPixSPvKw+lCaTSQayqpUdcm+iXH3VeXBXnaRKfaGJP7UO4gDUF91/e47pZL9uPVmf0l8OsuNxhgTwuPQDJA244csKucAm6VH8iQ/PygUHTzy4XZfsDrwSEU5MroDOFhkiR0i1f0UZ0p78VXJx+aNKvS9DDzG0L97VQaK/XCSRYmh36prweyMbac5s9aopEFhadgjQtRdnK0qSRFffb+MwVHwLQL29JlURRtVf3GTBrvGMr4Ou7XRvtj/A1bIz0Szm2tUwmxwqj9n7XBsQN946tYVQ66T65HEvIxLbYzeKWDNUvoqCxKq46m2zar+Rw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EFqUpFkvPQdV4r9XdQszBgf1ek54JSpzw5Ve7umwfjo=; b=AQADlshS8kj9rj3FJpKkZLnkLhr7z0iok4/1uS0P0XWCE1QQUUer7I6gMVkqfe6HI7GJRfEJQSIx6FKel8ZBYilF1qSwRBKTa5Klsq9z8yuIUHPQ3XWaOnJ+5g9526zQtrku0OMei5y6iTCK+FHxRSjaq9oaYNh64WHlR9F2wSY= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1331.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Mon, 20 Sep 2021 12:17:41 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::5562:f74d:728a:1a3e]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::5562:f74d:728a:1a3e%9]) with mapi id 15.20.4523.018; Mon, 20 Sep 2021 12:17:41 +0000 From: Esko Dijk To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] CoRE rechartering: proposed text Thread-Index: AQHXpNfagGpfIj1TS0+ge6ARHExAyqumTXkAgAabYiA= Date: Mon, 20 Sep 2021 12:17:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc6d2830-645e-4003-24a9-08d97c30a4f8 x-ms-traffictypediagnostic: AM9P190MB1331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: awHIGUfWgHFnMxbyE6oESpGPgUQImCdQV3h6dDvxTRrMbg/l494CIysodxBp63Tm7aiV7QWgqaTLHAr4dFgmCF+KVricIJZasVTqAkAnP5IPHakV5qnkOWFAqk7ylLjeMEIv4D9RSQUnDfKj6Mv0inBjccsEo5y6pWgJlDWvEFPx/T/DW55yotzYxyuMg9Xh3M0JpH1d6w/Mf59zwZzeWDLiTcy3eOKCYJ6mQvj35qWeQvzQk/smKcWjkqwRbUWmjN3pyx1W5WEoMjsG2+DywoN11gBamgW3d8u2FlVfsPjZ/OwrNm1s2GD3mHjE0p2QV9+I6jIuLLEVqqoC0yfmdE8+EfAszZuKwWzct8LJKUY5c7H5LTSUGUTspdVMx9dibUEu0I0kn/Alr/2EkUNZ7r4x7CRy74H4QaNSzCpOV5hn6+TahHo1VoD3vqJdulAR4U3iZ29LzjvYOvspOdegpTll1UuZVLUF3yLna9cqAA0C3yEvaOE0OoNQ2sYMB8gwx4MfcUfTt2mBJeOTtBfoh4h8HPzYoPeTCK6y59zUQ/OIBspNAFQCUVXFo9OC5KePvQ17zmdVUhTX+/3btAPFSwhjKPIbHNTCFUHnrIS+OcyLJHR0J4coJ208liYpkoRVUdI3h1E3OY1XFAJy3LcAp0wJnBmdm3nVg3HTTL1UXo7DcE90cbJsl34ozSbb3hh3Jz5X4uu/6iFIGhkskAlhuDmeZFuVDdQKLbVI5jNwbuv6nGbecx/zZpv+fPGi7HlNwrHeQnx8c/SSVk5/oX7iAYlkfm3zwbPLvcWE+jOPyQI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(396003)(39830400003)(376002)(346002)(136003)(316002)(66574015)(110136005)(66446008)(66556008)(8676002)(9686003)(122000001)(966005)(186003)(6506007)(33656002)(5660300002)(30864003)(44832011)(66946007)(66476007)(64756008)(71200400001)(86362001)(8936002)(76116006)(7696005)(38100700002)(55016002)(2906002)(478600001)(38070700005)(83380400001)(53546011)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SmtxaGlwTzdzdWM5VFAwUlZTOWg1UXU2VWFzUG9kbTN0Y09OcjBTWnE4MzRD?= =?utf-8?B?SE5idDFQS3NrWkZtUE9TOHhEblozWWpxeVc3dVlnNnZGLysxK0toQ0tPWFdS?= =?utf-8?B?TTBsV2EvNmR3UWJzOVptcGlDVjlHbnR4TFh6aU54VFFoWU9SN2ZGSUVHNU94?= =?utf-8?B?UVdDeU51MFZ6WVJkQkdDNVFTS0oreUR5Q3RFK1lBLytjbmhCODBYUERaQkQv?= =?utf-8?B?RGNGdWxIQU5CbTVpRWQ2eU4zOThjTFRPYk1mNXkyK0czVS9VUlpwSGMweVdX?= =?utf-8?B?TkZydVFLN0l5U21OWkNVd21QZjZndmh3TFZ5SGlaaHlaZUJXNXZ4c0hCNHpx?= =?utf-8?B?cU9ONXAzWjEyZ1c4alk3UXRMdGl4QjZpK1JlSm0wRzc1Qmttampnc2ZzbDRp?= =?utf-8?B?dWFDNW53blgzUk5Zb1FVcXJldmhlZGRpdzBOMlNPOWxqQ1R6anNpQTk5M09s?= =?utf-8?B?S2RPbVQ4UE80b3hHSUtlWk1nZjdpQ0V4b1N6ZS96bDg5ZTVPM0hZNkp6Nmp3?= =?utf-8?B?b01GK2Z0c2dyRCtUSUY0REM0SGR3THZ5NnhUeUU3R3djSTFxUUh3Q2VUZ1VY?= =?utf-8?B?QTNPM1MwQ3Ryek1lSVQ3SHZHZ0lpcXJnNHYxNDFieWFZdmc0STV1aEtzTXNW?= =?utf-8?B?Y0dpeC9YOWNKMThBZEw5ZERBSmlJRWRIcFFBZWJVZDJjMFhLenhuaTVLMWFG?= =?utf-8?B?bDBzMi9sSHJSOGlLTzVmWW9BbG9Nb3hra2lwNXBaemMvSUovZTZsSEFuWmpC?= =?utf-8?B?U1NDOFBCZkxQU0c4RitUTUJmM3lrTFp3cHZHZkphSjAyZVN5MDdGWFdzZkR6?= =?utf-8?B?d3JmUlYyeFk1T0NoaXNxVjk5SG9wQWI5WEV3VjdnS0tQRi9raElyam11Tk83?= =?utf-8?B?b0ZzU3g1b3dwbjBNTklmL2UzUHJGdDYzd0gyQUpIMlloRWdmSzZrM1AyUHlq?= =?utf-8?B?TkpnNkRhSzlpVEFjMWZRL1QweVNpSk1pelhtYXBzVmFaSCtMckw1UFNUS3ZH?= =?utf-8?B?QytlNm5lMFp6NEpSWVJCblp3WTdUQnRaN3dGN09vZGI3Tm5FRzJod1Ewd2RV?= =?utf-8?B?S3hRb3gwcnE2a0VkVmpVUTBUTWdSTldvSHJPaGZyZ2VBbnNhZXBGMDk4anpJ?= =?utf-8?B?THUvWmV2cVo0VkdyclZTNTYwYTFjR1VvT1huamlSOGFIWVNkR3RYeGE2N25U?= =?utf-8?B?d01hVnBzN2txUkdyMERHY1RmbkhxUGtwRVVlTkg2NVJYL3BFT1lWMVZzZ1R1?= =?utf-8?B?eXFwR1JWTXhGYzNZSWtiMnFNM2tBSDlJdW8wdzVYcTZodm0xZWR4TjRDc2VT?= =?utf-8?B?VG02UFdFYTA4ZnZMTFAzNkFoYWNxbGE3OGR3M1J1U2d2N1pXZ1h6eUE4SFNC?= =?utf-8?B?S2lDVm1tZHVmeDk0MnZaVHk3ampiU1pld3plSFo3cUFNalJuSmZlcmQySGNB?= =?utf-8?B?aGJLK3dvS091Q2pPYVdNRFd6bVV0bXI1UTZlWmd2WWNoWUorTlBleGtQUEFw?= =?utf-8?B?akRIbEhRMlNGQ0VKb0ZzS29aMVRQWTExc2w1WnhDVU50ZHlncVVpajBtVjZV?= =?utf-8?B?NEtTandPNStnV3ZzS0ZxY2hORldYOUlaOVFXc09pRTBNeGh0THJSV25FZVRC?= =?utf-8?B?M3h0Wmw0R0J5UGU4T2l3dkZUUjlHbkpmdDI3eU04U2Y3QlA3c0FCa3N2RGhn?= =?utf-8?B?Y25WZWRPK1ZPa1YrTjdHQVY0YUtqSGxTcEJnL2FndWVkWjJSVEJzdUQydno4?= =?utf-8?B?VktjdHJBbVhqOFBFUS9IYUxHY28xK1NjNHA4ZkhyVVNEUGNsR1lpZTVsaDE3?= =?utf-8?B?Ry9YMGxTZkJReDJEQUhzc1VMR3FHd3FsK2lzUHFzZDlMbE9FRUlTOEVzM2o2?= =?utf-8?Q?FEgZNj5w2XEmO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: bc6d2830-645e-4003-24a9-08d97c30a4f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2021 12:17:41.6132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hl/I92YqmDvvyMFElepzucVQvmlv5G/FAs0i22404+gTLzLvuVAJBlFMRRMjYjfIfb5rraHuT3heGb5JjHfsFYz9f7av18YwWatMZr0J4vw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1331 Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 12:17:57 -0000 SGVsbG8sDQoNCkN1cnJlbnQgdGV4dCBsb29rcyBnb29kIHRvIG1lLiBJdCBpcyBhIHF1aXRlIGRl dGFpbGVkIGNoYXJ0ZXI7IGdvb2QgdG8gaGF2ZSBpdCB1cGRhdGVkIG5vdyB0byByZWZsZWN0IHJl Y2VudCBwcm9ncmVzcy4gQWxzbyBpdCBpcyBnb29kIGFzIGFuIGludHJvZHVjdGlvbiB0byBDb1JF LCBvciBhcyBvdmVydmlldyBvZiB0aGUgbGF0ZXN0IHN0YXR1cyAmIHdvcmsuDQpQb3NzaWJsZSBk b3duc2lkZSBvZiBhIGRldGFpbGVkIGNoYXJ0ZXIgaXMgdGhhdCBpdCBuZWVkcyB0byBiZSB1cGRh dGVkIG1vcmUgb2Z0ZW4hDQoNClJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1h cmNvIFRpbG9jYQ0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxNiwgMjAyMSAwOToyMg0KVG86 IGNvcmVAaWV0Zi5vcmcgV0cgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtjb3JlXSBDb1JFIHJlY2hhcnRlcmluZzogcHJvcG9zZWQgdGV4dA0KDQpIaSBhbGws DQoNCkR1cmluZyB0aGUgMjAyMS0wOS0xNSBpbnRlcmltIG1lZXRpbmcgWzFdLCB3ZSBoYWQgYSBn b29kIGZpcnN0IA0KZGlzY3Vzc2lvbiBvbiB0aGUgcHJvcG9zZWQgbmV3IHRleHQgZm9yIHRoZSBw b3NzaWJsZSB1cGRhdGVkIGNoYXJ0ZXIuDQoNCkFzIG1lbnRpb25lZCBhdCB0aGUgbWVldGluZywg cGxlYXNlIHRha2Ugc29tZSB0aW1lIHRvIHJldmlldyB0aGUgbmV3IA0KdGV4dCBhbmQgcG9zc2li bHkgcHJvdmlkZSBpbnB1dC9jb21tZW50cy4gRXZlbiBpbiBjYXNlIHlvdSBhcmUganVzdCBmaW5l IA0Kd2l0aCB0aGUgdGV4dCAiYXMgaXMiLCBpdCBpcyB2YWx1YWJsZSBmZWVkYmFjayB0byBzYXkg c28uDQoNCg0KUGxlYXNlLCBwcm92aWRlIHlvdXIgY29tbWVudHMgYW5kIHByb3Bvc2VkIGNoYW5n ZXM6DQoNCi0gSW4gdGhpcyBtYWlsIHRocmVhZCwgd2hlcmUgdGhlIGZpcnN0IG1lc3NhZ2UgWzJd IGFsc28gaW5jbHVkZXMgdGhlIG5ldyANCnByb3Bvc2VkIGNoYXJ0ZXIgdGV4dDsNCg0KYW5kL29y DQoNCi0gSW4gdGhpcyBDb2RpTUQgZG9jdW1lbnQgWzNdLCB3aGVyZSBlZGl0aW5nIHJlcXVpcmVz IHRvIGJlIGxvZ2dlZCBpbiANCndpdGggeW91ciBEYXRhdHJhY2tlciBhY2NvdW50Lg0KDQoNClRo ZSBuZXcgY2hhcnRlciB0ZXh0IGlzIGFsc28gYXZhaWxhYmxlIG9uIG91ciBHaXRodWIgYXQgWzRd LCB0b2dldGhlciANCndpdGggYSBkaWZmIGZyb20gdGhlIHByZXNlbnQgY2hhcnRlciB0ZXh0IGF0 IFs1XS4NCg0KVGhhbmtzLA0KTWFyY28gYW5kIEphaW1lDQoNCg0KWzFdIA0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy1pbnRlcmltLTIwMjEtY29yZS0xMC0yMDIxMDkx NTE2MDAvDQoNClsyXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2NvcmUv aGFCdG5pbk84NVVqc3lxQVNlZU8wRkZyX1dvLw0KDQpbM10gaHR0cHM6Ly9ub3Rlcy5pZXRmLm9y Zy9Ca3BRLWd0dFNSdVZLbEVneGhvNWd3P2JvdGgNCg0KWzRdIA0KaHR0cHM6Ly9naXRodWIuY29t L2NvcmUtd2cvY29yZS13Zy5naXRodWIuaW8vYmxvYi9tYXN0ZXIvY29yZS1jaGFydGVyLnR4dA0K DQpbNV0gDQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb3JlLXdnLmdpdGh1Yi5pby9jb21t aXQvMTMzODYxYTkyZWY2MmEyMTMwNDI3NTIxNDU1ZmI1OGJjZTIzYWEzZT9icmFuY2g9MTMzODYx YTkyZWY2MmEyMTMwNDI3NTIxNDU1ZmI1OGJjZTIzYWEzZSZkaWZmPXNwbGl0DQoNCg0KT24gMjAy MS0wOS0wOCAxOTozNCwgTWFyY28gVGlsb2NhIHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IER1cmlu ZyB0aGUgQ29SRSBzZXNzaW9uIGF0IElFVEYgMTExIFsxXVsyXSwgaXQgd2FzIHByb3Bvc2VkIHRv IHVwZGF0ZSANCj4gb3VyIGNoYXJ0ZXIsIGZvciBiZXR0ZXIgcmVmbGVjdGluZyB0aGUgY3VycmVu dCBzdGF0dXMgb2Ygb3VyIHdvcmsuIA0KPiBUaGlzIGlzIGFsc28gaGVscGZ1bCBmb3IgdGhlIElF U0cgcmV2aWV3IHByb2Nlc3NpbmcgYW5kIGZvciBuZXdjb21lcnMgDQo+IHRvIG1vcmUgZWFzaWx5 IHVuZGVyc3RhbmQgdGhlIFdHIHNjb3BlIGFuZCBkaXJlY3Rpb24uDQo+DQo+IEFzIHByb21pc2Vk LCB0aGUgQ2hhaXJzIGhhdmUgcHJlcGFyZWQgYW4gaW5pdGlhbCBwcm9wb3NlZCB0ZXh0IGZvciB0 aGUgDQo+IFdHIHRvIGNvbnNpZGVyLiBQbGVhc2UsIGZpbmQgdGhlIHByb3Bvc2VkIHRleHQgYXQg dGhlIGVuZCBvZiB0aGlzIG1haWwgDQo+IGFzIHdlbGwgYXMgaW4gdGhlIENvZGlNRCBhdCBbM10u DQo+DQo+IFdpdGggdGhhdCBhcyBzdGFydGluZyBwb2ludCwgdGhpcyBtYWlsIHN0YXJ0cyBhIGRp c2N1c3Npb24gb24gdGhlIG5ldyANCj4gY2hhcnRlciB0ZXh0LiBQbGVhc2UsIHByb3ZpZGUgeW91 ciBjb21tZW50cyBhbmQgcHJvcG9zZWQgY2hhbmdlcyBoZXJlIA0KPiBvbiB0aGUgbWFpbGluZyBs aXN0IG9yIGluIHRoZSBDb2RpTUQgYXQgWzNdIChlZGl0aW5nIHJlcXVpcmVzIHRvIGJlIA0KPiBs b2dnZWQgaW4pLg0KPg0KPiBCZXN0LA0KPiBNYXJjbyBhbmQgSmFpbWUNCj4NCj4NCj4gWzFdIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTExLWNvcmUvDQo+DQo+IFsy XSANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzExMS9tYXRlcmlhbHMv c2xpZGVzLTExMS1jb3JlLWNoYWlycy1zbGlkZXMtMDAucGRmDQo+DQo+IFszXSBodHRwczovL25v dGVzLmlldGYub3JnL0JrcFEtZ3R0U1J1VktsRWd4aG81Z3c/Ym90aA0KPg0KPg0KPiA9PT09PT09 PT09PT09PT09PT09PT09PQ0KPg0KPiBUaGUgQ29SRSBXb3JraW5nIEdyb3VwIChXRykgcHJvdmlk ZXMgYSBmcmFtZXdvcmsgZm9yIHJlc291cmNlLW9yaWVudGVkIA0KPiBhcHBsaWNhdGlvbnMgaW50 ZW5kZWQgdG8gcnVuIG9uIGNvbnN0cmFpbmVkIElQIG5ldHdvcmtzLiBBIGNvbnN0cmFpbmVkIA0K PiBJUCBuZXR3b3JrIGhhcyBsaW1pdGVkIHBhY2tldCBzaXplcywgbWF5IGV4aGliaXQgYSBoaWdo IGRlZ3JlZSBvZiANCj4gcGFja2V0IGxvc3MsIGFuZCBtYXkgaGF2ZSBhIHN1YnN0YW50aWFsIG51 bWJlciBvZiBkZXZpY2VzIHRoYXQgbWF5IGJlIA0KPiBwb3dlcmVkIG9mZiBhdCBhbnkgcG9pbnQg aW4gdGltZSBidXQgcGVyaW9kaWNhbGx5ICJ3YWtlIHVwIiBmb3IgYnJpZWYgDQo+IHBlcmlvZHMg b2YgdGltZS4gVGhlc2UgbmV0d29ya3MgYW5kIHRoZSBub2RlcyB3aXRoaW4gdGhlbSBhcmUgDQo+ IGNoYXJhY3Rlcml6ZWQgYnkgc2V2ZXJlIGxpbWl0cyBvbiB0aHJvdWdocHV0LCBhdmFpbGFibGUg cG93ZXIsIGFuZCANCj4gcGFydGljdWxhcmx5IG9uIHRoZSBjb21wbGV4aXR5IHRoYXQgY2FuIGJl IHN1cHBvcnRlZCB3aXRoIGxpbWl0ZWQgY29kZSANCj4gc2l6ZSBhbmQgbGltaXRlZCBSQU0gcGVy IG5vZGUgW1JGQyA3MjI4XS4gTW9yZSBnZW5lcmFsbHksIHdlIHNwZWFrIG9mIA0KPiBjb25zdHJh aW5lZCBub2RlIG5ldHdvcmtzIHdoZW5ldmVyIGF0IGxlYXN0IHNvbWUgb2YgdGhlIG5vZGVzIGFu ZCANCj4gbmV0d29ya3MgaW52b2x2ZWQgZXhoaWJpdCB0aGVzZSBjaGFyYWN0ZXJpc3RpY3MuIExv dy1Qb3dlciBXaXJlbGVzcyANCj4gUGVyc29uYWwgQXJlYSBOZXR3b3JrcyAoTG9XUEFOcykgYXJl IGFuIGV4YW1wbGUgb2YgdGhpcyB0eXBlIG9mIA0KPiBuZXR3b3JrLiBDb25zdHJhaW5lZCBuZXR3 b3JrcyBjYW4gb2NjdXIgYXMgcGFydCBvZiBob21lIGFuZCBidWlsZGluZyANCj4gYXV0b21hdGlv biwgZW5lcmd5IG1hbmFnZW1lbnQsIGFuZCB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzLg0KPg0KPiBU aGUgQ29SRSBXRyB3aWxsIGRlZmluZSBhIGZyYW1ld29yayBmb3IgYSBsaW1pdGVkIGNsYXNzIG9m IA0KPiBhcHBsaWNhdGlvbnM6IHRob3NlIHRoYXQgZGVhbCB3aXRoIHRoZSBtYW5pcHVsYXRpb24g b2Ygc2ltcGxlIA0KPiByZXNvdXJjZXMgb24gY29uc3RyYWluZWQgbmV0d29ya3MuIFRoaXMgaW5j bHVkZXMgYXBwbGljYXRpb25zIHRvIA0KPiBtb25pdG9yIHNpbXBsZSBzZW5zb3JzIChlLmcuLCB0 ZW1wZXJhdHVyZSBzZW5zb3JzLCBsaWdodCBzZW5zb3JzLCBhbmQgDQo+IHBvd2VyIG1ldGVycyks IHRvIGNvbnRyb2wgYWN0dWF0b3JzIChlLmcuLCBsaWdodCBzd2l0Y2hlcywgaGVhdGluZyANCj4g Y29udHJvbGxlcnMsIGFuZCBkb29yIGxvY2tzKSwgYW5kIHRvIG1hbmFnZSBkZXZpY2VzLg0KPg0K PiBUaGUgZ2VuZXJhbCBhcmNoaXRlY3R1cmUgdGFyZ2V0ZWQgYnkgdGhlIENvUkUgV0cgZnJhbWV3 b3JrIGNvbnNpc3RzIG9mIA0KPiBub2RlcyBvbiB0aGUgY29uc3RyYWluZWQgbmV0d29yaywgY2Fs bGVkIERldmljZXMsIHRoYXQgYXJlIHJlc3BvbnNpYmxlIA0KPiBmb3Igb25lIG9yIG1vcmUgUmVz b3VyY2VzIHRoYXQgbWF5IHJlcHJlc2VudCBzZW5zb3JzLCBhY3R1YXRvcnMsIA0KPiBjb21iaW5h dGlvbnMgb2YgdmFsdWVzLCBhbmQvb3Igb3RoZXIgaW5mb3JtYXRpb24uIERldmljZXMgc2VuZCAN Cj4gbWVzc2FnZXMgdG8gY2hhbmdlIGFuZCBxdWVyeSByZXNvdXJjZXMgb24gb3RoZXIgRGV2aWNl cy4gQSBEZXZpY2UgY2FuIA0KPiBzZW5kIG5vdGlmaWNhdGlvbnMgYWJvdXQgY2hhbmdlZCByZXNv dXJjZSB2YWx1ZXMgdG8gRGV2aWNlcyB0aGF0IGhhdmUgDQo+IGV4cHJlc3NlZCB0aGVpciBpbnRl cmVzdCB0byByZWNlaXZlIG5vdGlmaWNhdGlvbiBhYm91dCBjaGFuZ2VzLiBBIA0KPiBEZXZpY2Ug Y2FuIGFsc28gcHVibGlzaCBvciBiZSBxdWVyaWVkIGFib3V0IGl0cyByZXNvdXJjZXMuIFR5cGlj YWxseSwgDQo+IGEgc2luZ2xlIHBoeXNpY2FsIGhvc3Qgb24gdGhlIG5ldHdvcmsgd291bGQgaGF2 ZSBqdXN0IG9uZSBEZXZpY2UgYnV0IGEgDQo+IGhvc3QgbWlnaHQgcmVwcmVzZW50IG11bHRpcGxl IGxvZ2ljYWwgRGV2aWNlcy4gVGhlIHNwZWNpZmljIA0KPiB0ZXJtaW5vbG9neSB0byBiZSB1c2Vk IGhlcmUgaXMgdG8gYmUgZGVjaWRlZCBieSB0aGUgd29ya2luZyBncm91cC4NCj4NCj4gQXMgcGFy dCBvZiB0aGUgZnJhbWV3b3JrIGZvciBidWlsZGluZyB0aGVzZSBhcHBsaWNhdGlvbnMsIHRoZSBD b1JFIFdHIA0KPiBoYXMgZGVmaW5lZCB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9j b2wgKENvQVApIGZvciB0aGUgDQo+IG1hbmlwdWxhdGlvbiBvZiBSZXNvdXJjZXMgb24gYSBEZXZp Y2UuIENvQVAgaXMgZGVzaWduZWQgZm9yIHVzZSANCj4gYmV0d2VlbiBEZXZpY2VzIG9uIHRoZSBz YW1lIGNvbnN0cmFpbmVkIG5ldHdvcmssIGJldHdlZW4gRGV2aWNlcyBhbmQgDQo+IGdlbmVyYWwg bm9kZXMgb24gdGhlIEludGVybmV0LCBhbmQgYmV0d2VlbiBEZXZpY2VzIG9uIGRpZmZlcmVudCAN Cj4gY29uc3RyYWluZWQgbmV0d29ya3MgYm90aCBqb2luZWQgYnkgYW4gaW50ZXJuZXQuIENvQVAg aXMgYWxzbyBiZWluZyANCj4gdXNlZCB2aWEgb3RoZXIgbWVjaGFuaXNtcywgc3VjaCBhcyBTTVMg b24gbW9iaWxlIGNvbW11bmljYXRpb24gDQo+IG5ldHdvcmtzLiBDb0FQIHRhcmdldHMgdGhlIHR5 cGUgb2Ygb3BlcmF0aW5nIGVudmlyb25tZW50cyBkZWZpbmVkIGluIA0KPiB0aGUgUk9MTCBhbmQg NkxvIFdHcywgd2hpY2ggaGF2ZSBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIGNvbXBhcmVkIHRvIA0K PiBub3JtYWwgSVAgbmV0d29ya3MuIE5ldmVydGhlbGVzcywgdGhlIENvQVAgcHJvdG9jb2wgYWxz byBvcGVyYXRlcyBvdmVyIA0KPiB0cmFkaXRpb25hbCBJUCBuZXR3b3Jrcy4NCj4NCj4gVGhlcmUg YWxzbyBtYXkgYmUgaW50ZXJtZWRpYXJ5IG5vZGVzIGFjdGluZyBhcyBwcm94aWVzIHRoYXQgcG9z c2libHkgDQo+IGFsc28gaW50ZXJjb25uZWN0IGJldHdlZW4gb3RoZXIgSW50ZXJuZXQgcHJvdG9j b2xzIGFuZCB0aGUgRGV2aWNlcyANCj4gdXNpbmcgdGhlIENvQVAgcHJvdG9jb2wuIEl0IGlzIHdv cnRoIG5vdGluZyB0aGF0IGEgcHJveHkgZG9lcyBub3QgaGF2ZSANCj4gdG8gb2NjdXIgYXQgdGhl IGJvdW5kYXJ5IGJldHdlZW4gdGhlIGNvbnN0cmFpbmVkIG5ldHdvcmsgYW5kIHRoZSBtb3JlIA0K PiBnZW5lcmFsIG5ldHdvcmssIGJ1dCBjYW4gYmUgZGVwbG95ZWQgYXQgdmFyaW91cyBsb2NhdGlv bnMgaW4gdGhlIA0KPiBsZXNzLWNvbnN0cmFpbmVkIG5ldHdvcmsuIFRoZSBDb1JFIFdHIHdpbGwg Y29udGludWUgdG8gZXZvbHZlIHRoZSANCj4gc3VwcG9ydCBvZiBwcm94aWVzIGZvciBDb0FQIHRv IGluY3JlYXNlIHRoZWlyIHByYWN0aWNhbCBhcHBsaWNhYmlsaXR5Lg0KPg0KPiBDb0FQIHN1cHBv cnRzIHZhcmlvdXMgZm9ybXMgb2YgImNhY2hpbmciLiBCZXlvbmQgdGhlIGJlbmVmaXRzIG9mIA0K PiBjYWNoaW5nIGFscmVhZHkgd2VsbCBrbm93biBmcm9tIFJFU1QsIGNhY2hpbmcgY2FuIGJlIHVz ZWQgdG8gaW5jcmVhc2UgDQo+IGVuZXJneSBzYXZpbmdzIG9mIGxvdy1wb3dlciBub2RlcyBieSBh bGxvd2luZyB0aGVtIHRvIGJlIG5vcm1hbGx5LW9mZiANCj4gW1JGQyA3MjI4XS4gRm9yIGV4YW1w bGUsIGEgdGVtcGVyYXR1cmUgc2Vuc29yIG1pZ2h0IHdha2UgdXAgZXZlcnkgZml2ZSANCj4gbWlu dXRlcyBhbmQgc2VuZCB0aGUgY3VycmVudCB0ZW1wZXJhdHVyZSB0byBhIHByb3h5IHRoYXQgaGFz IGV4cHJlc3NlZCANCj4gaW50ZXJlc3QgaW4gbm90aWZpY2F0aW9ucy4gV2hlbiB0aGUgcHJveHkg cmVjZWl2ZXMgYSByZXF1ZXN0IG92ZXIgQ29BUCANCj4gb3IgSFRUUCBmb3IgdGhhdCB0ZW1wZXJh dHVyZSByZXNvdXJjZSwgaXQgY2FuIHJlc3BvbmQgd2l0aCB0aGUgbGFzdCANCj4gbm90aWZpZWQg dmFsdWUsIGluc3RlYWQgb2YgdHJ5aW5nIHRvIHF1ZXJ5IHRoZSBEZXZpY2Ugd2hpY2ggbWF5IG5v dCBiZSANCj4gcmVhY2hhYmxlIGF0IHRoaXMgdGltZS4gVGhlIENvUkUgV0cgd2lsbCBjb250aW51 ZSB0byBldm9sdmUgdGhpcyBtb2RlbCANCj4gdG8gaW5jcmVhc2UgaXRzIHByYWN0aWNhbCBhcHBs aWNhYmlsaXR5Lg0KPg0KPiBUaGUgQ29SRSBXRyB3aWxsIHBlcmZvcm0gbWFpbnRlbmFuY2UgYXMg d2VsbCBhcyBwb3NzaWJsZSB1cGRhdGluZyBhbmQgDQo+IGNvbXBsZW1lbnRpbmcgb24gaXRzIGZp cnN0IGZvdXIgc3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb25zIGFzIA0KPiByZXF1aXJlZDoN Cj4NCj4gLSBSRkMgNjY5MA0KPiAtIFJGQyA3MjUyDQo+IC0gUkZDIDc2NDENCj4gLSBSRkMgNzk1 OQ0KPg0KPiBUaGUgQ29SRSBXRyB3aWxsIGNvbnRpbnVlIHRvIGV2b2x2ZSB0aGUgc3VwcG9ydCBm b3IgQ29BUCBncm91cCANCj4gY29tbXVuaWNhdGlvbiBvcmlnaW5hbGx5IGRldmVsb3BlZCBpbiB0 aGUgRXhwZXJpbWVudGFsIFJGQyA3MzkwLiBUaGUgDQo+IENvUkUgV0cgd2lsbCBub3QgZGV2ZWxv cCBhIHNvbHV0aW9uIGZvciByZWxpYWJsZSBtdWx0aWNhc3QgZGVsaXZlcnkgb2YgDQo+IENvQVAg bWVzc2FnZXMsIHdoaWNoIHdpbGwgcmVtYWluIE5vbi1Db25maXJtYWJsZSB3aGVuIHNlbnQgb3Zl ciANCj4gbXVsdGljYXN0Lg0KPg0KPiBSRkMgNzI1MiBkZWZpbmVzIGEgYmFzaWMgSFRUUCBtYXBw aW5nIGZvciBDb0FQLCB3aGljaCB3YXMgZnVydGhlciANCj4gZWxhYm9yYXRlZCBpbiBSRkMgODA3 NS4gVGhpcyBtYXBwaW5nIHdpbGwgYmUgZXZvbHZlZCBhbmQgc3VwcG9ydGVkIGJ5IA0KPiBmdXJ0 aGVyIGRvY3VtZW50cyBhcyByZXF1aXJlZC4NCj4NCj4gQ29BUCB3YXMgaW5pdGlhbGx5IGRlc2ln bmVkIHRvIHdvcmsgb3ZlciBVRFAgYW5kIERUTFMuIExhdGVyIG9uLCANCj4gbWFwcGluZyB3ZXJl IGRlZmluZWQgYmV0d2VlbiBDb0FQIGFuZCBJUC1iYXNlZCB0cmFuc3BvcnRzLCBlc3BlY2lhbGx5 IA0KPiBUQ1AgYW5kIFdlYlNvY2tldHMgaW5jbHVkaW5nIGEgc2VjdXJlIHZlcnNpb24gb3ZlciBU TFMgKFJGQyA4MzIzKS4gVGhlIA0KPiBDb1JFIFdHIHdpbGwgY29udGludWUgZGVmaW5pbmcgdHJh bnNwb3J0IG1hcHBpbmdzIGZvciBhbHRlcm5hdGl2ZSANCj4gdHJhbnNwb3J0cyBhcyByZXF1aXJl ZCwgYm90aCBJUC1iYXNlZCBhbmQgbm9uIElQLWJhc2VkIChlLmcuLCBTTVMgYW5kIA0KPiBCbHVl dG9vdGgpLCB3b3JraW5nIHdpdGggdGhlIFNlY3VyaXR5IEFyZWEgb24gcG90ZW50aWFsbHkgYWRk cmVzc2luZyANCj4gdGhlIHNlY3VyaXR5IGdhcC4gVGhpcyBpbmNsdWRlcyBkZWZpbmluZyBhcHBy b3ByaWF0ZSBVUkkgc2NoZW1lcy4gDQo+IENvbnRpbnVlZCBjb21wYXRpYmlsaXR5IHdpdGggQ29B UCBvdmVyIFNNUyBhcyBkZWZpbmVkIGluIE9NQSANCj4gTGlnaHR3ZWlnaHQgTWFjaGluZS10by1N YWNoaW5lIChMd00yTSkgd2lsbCBiZSBjb25zaWRlcmVkLiANCj4gRnVydGhlcm1vcmUsIHRoZSBD b1JFIFdHIHdpbGwgd29yayBvbiBzb2x1dGlvbnMgdG8gZmFjaWxpdGF0ZSB0aGUgDQo+IHNpZ25h bGluZyBvZiB0cmFuc3BvcnRzIGF2YWlsYWJsZSB0byBhIERldmljZS4NCj4NCj4gVGhlIENvUkUg V0cgd2lsbCBjb250aW51ZSBhbmQgY29tcGxldGUgaXRzIHdvcmsgb24gdGhlIENvUkUgUmVzb3Vy Y2UgDQo+IERpcmVjdG9yeSAoZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeSksIGFz IGFscmVhZHkgcGFydGlhbGx5IA0KPiBhZG9wdGVkIGJ5IE9NQSBMd00yTSwgYW5kIHdpbGwgcGVy Zm9ybSBtYWludGVuYW5jZSBhcyB3ZWxsIGFzIHBvc3NpYmxlIA0KPiB1cGRhdGluZywgY29tcGxl bWVudGluZyBhbmQgc3BlY2lmaWNhdGlvbiBvZiByZWxldmFudCB1c2VzIGFzIA0KPiByZXF1aXJl ZC4gQSBwcmltYXJ5IHJlbGF0ZWQgY29uc2lkZXJhdGlvbiBpcyB0aGUgaW50ZXJvcGVyYWJpbGl0 eSB3aXRoIA0KPiBETlMtU0QgYW5kIHRoZSB3b3JrIG9mIHRoZSBkbnNzZCBXRy4gVGhlIHVzZSBv ZiBDb0FQIHRvIHRyYW5zcG9ydCBETlMgDQo+IHF1ZXJpZXMgYW5kIHJlc3BvbnNlcyB3aWxsIGFs c28gYmUgaW52ZXN0aWdhdGVkLiBGdXJ0aGVybW9yZSwgdGhlIENvUkUgDQo+IFdHIHdpbGwgYWxz byBjb250aW51ZSBhbmQgY29tcGxldGUgaXRzIHdvcmsgb24gZW5hYmxpbmcgYnJva2VyLWJhc2Vk IA0KPiBwdWJsaXNoLXN1YnNjcmliZS1zdHlsZSBjb21tdW5pY2F0aW9uIG92ZXIgQ29BUCANCj4g KGRyYWZ0LWlldGYtY29yZS1jb2FwLXB1YnN1YikuDQo+DQo+IFRoZSBDb1JFIFdHIHdpbGwgd29y ayBvbiByZWxhdGVkIGRhdGEgZm9ybWF0cywgc3VjaCBhcyBhbHRlcm5hdGl2ZSANCj4gcmVwcmVz ZW50YXRpb25zIG9mIFJGQyA2NjkwIGxpbmsgZm9ybWF0IGFuZCBSRkMgNzM5MCBncm91cCANCj4g Y29tbXVuaWNhdGlvbiBpbmZvcm1hdGlvbi4gQWxzbywgdGhlIENvUkUgV0cgd2lsbCBjb21wbGV0 ZSBpdHMgd29yayBvbiANCj4gQ29uc3RyYWluZWQgUmVzb3VyY2UgSWRlbnRpZmllcnMgZm9yIHNl cmlhbGl6aW5nIFVSSSBjb21wb25lbnRzIGluIA0KPiBDQk9SIChkcmFmdC1pZXRmLWNvcmUtaHJl ZikuIEZ1cnRoZXJtb3JlLCB0aGUgQ29SRSBXRyB3aWxsIGRldmVsb3AgDQo+IENvUkFMIChkcmFm dC1pZXRmLWNvcmUtY29yYWwpLCBhIGNvbnN0cmFpbmVkIFJFU1RmdWwgYXBwbGljYXRpb24gDQo+ IGxhbmd1YWdlIHN1aXRhYmxlIGFsc28gZm9yIGNvbnN0cmFpbmVkIG5vZGUgbmV0d29ya3MsIHdo aWNoIGNvbXByaXNlcyANCj4gYW4gaW5mb3JtYXRpb24gbW9kZWwgYW5kIGFuIGludGVyYWN0aW9u IG1vZGVsLCBhbmQgaXMgaW50ZW5kZWQgZm9yIA0KPiBkcml2aW5nIGF1dG9tYXRlZCBzb2Z0d2Fy ZSBhZ2VudHMgdGhhdCBuYXZpZ2F0ZSBhIFdlYiBhcHBsaWNhdGlvbi4gVGhlIA0KPiBDb1JFIFdH IHdpbGwgY29tcGxldGUgdGhlIFNlbnNvciBNZWFzdXJlbWVudCBMaXN0cyAoU2VuTUwpIHNldCBv ZiANCj4gc3BlY2lmaWNhdGlvbnMsIGFnYWluIHdpdGggY29uc2lkZXJhdGlvbiB0byBpdHMgYWRv cHRpb24gaW4gT01BIEx3TTJNLg0KPg0KPiBCZXNpZGVzIGNvbnRpbnVpbmcgdG8gZXhhbWluZSBv cGVyYXRpb25hbCBhbmQgbWFuYWdlYWJpbGl0eSBhc3BlY3RzIG9mIA0KPiB0aGUgQ29BUCBwcm90 b2NvbCBpdHNlbGYsIHRoZSBDb1JFIFdHIHdpbGwgYWxzbyBjb21wbGV0ZSB0aGUgd29yayBvbiAN Cj4gUkVTVENPTkYtc3R5bGUgbWFuYWdlbWVudCBmdW5jdGlvbnMgYXZhaWxhYmxlIHZpYSBDb0FQ IHRoYXQgYXJlIA0KPiBhcHByb3ByaWF0ZSBmb3IgY29uc3RyYWluZWQgbm9kZSBuZXR3b3JrcyAo ZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvciwgDQo+IGRyYWZ0LWlldGYtY29yZS1zaWQsIGRyYWZ0 LWlldGYtY29yZS1jb21pLCANCj4gZHJhZnQtaWV0Zi1jb3JlLXlhbmctbGlicmFyeSkuIFRoaXMg cmVxdWlyZXMgdmVyeSBjbG9zZSBjb29yZGluYXRpb24gDQo+IHdpdGggTkVUQ09ORiBhbmQgb3Ro ZXIgb3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudCBXR3MuIFlBTkcgZGF0YSBtb2RlbHMgDQo+IGFy ZSB1c2VkIGZvciBtYW5hZ2VhYmlsaXR5LiBOb3RlIHRoYXQgdGhlIFlBTkcgbW9kZWxpbmcgbGFu Z3VhZ2UgaXMgDQo+IG5vdCBhIHRhcmdldCBmb3IgY2hhbmdlIGluIHRoaXMgcHJvY2VzcywgYWx0 aG91Z2ggYWRkaXRpb25hbCANCj4gbWVjaGFuaXNtcyB0aGF0IHN1cHBvcnQgWUFORyBtb2R1bGVz IG1heSBiZSBlbXBsb3llZCBpbiBzcGVjaWZpYyBjYXNlcyANCj4gd2hlcmUgc2lnbmlmaWNhbnQg cGVyZm9ybWFuY2UgZ2FpbnMgYXJlIGJvdGggYXR0YWluYWJsZSBhbmQgcmVxdWlyZWQuIA0KPiBU aGUgQ29SRSBXRyB3aWxsIGNvbnRpbnVlIHRvIGNvbnNpZGVyIHRoZSBPTUEgTHdNMk0gbWFuYWdl bWVudCANCj4gZnVuY3Rpb25zIGFzIGEgd2VsbC1hY2NlcHRlZCBhbHRlcm5hdGl2ZSBmb3JtIG9m IG1hbmFnZW1lbnQgYW5kIA0KPiBwcm92aWRlIHN1cHBvcnQgYXQgdGhlIENvQVAgcHJvdG9jb2wg bGV2ZWwgd2hlcmUgcmVxdWlyZWQuDQo+DQo+IFRoZSBDb1JFIFdHIG9yaWdpbmFsbHkgc2VsZWN0 ZWQgRFRMUyBhcyB0aGUgYmFzaXMgZm9yIHRoZSANCj4gY29tbXVuaWNhdGlvbiBzZWN1cml0eSBp biBDb0FQLiBUaGUgQ29SRSBXRyB3aWxsIHdvcmsgd2l0aCB0aGUgVExTIFdHIA0KPiBvbiB0aGUg ZWZmaWNpZW5jeSBvZiB0aGlzIHNvbHV0aW9uLiBUaGUgcHJlZmVycmVkIGNpcGhlciBzdWl0ZXMg d2lsbCANCj4gZXZvbHZlIGluIGNvb3BlcmF0aW9uIHdpdGggdGhlIFRMUyBXRyBhbmQgQ0ZSRy4N Cj4NCj4gVGhlIENvUkUgV0cgY29uc2lkZXJlZCBvYmplY3Qgc2VjdXJpdHkgYXMgb3JpZ2luYWxs eSBkZWZpbmVkIGluIEpPU0UgDQo+IGFuZCBsYXRlciBhZGFwdGVkIHRvIHRoZSBjb25zdHJhaW5l ZCBub2RlIG5ldHdvcmsgcmVxdWlyZW1lbnRzIGluIA0KPiBDT1NFLiBCdWlsZGluZyBvbiB0aGF0 LCB0aGUgQ29SRSBXRyBoYXMgZGVmaW5lZCB0aGUgT2JqZWN0IFNlY3VyaXR5IA0KPiBmb3IgQ29u c3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMgKE9TQ09SRSkgcHJvdG9jb2wgKFJGQyA4NjEz KSBmb3IgDQo+IHByb3RlY3RpbmcgQ29BUCBtZXNzYWdlcyBhdCB0aGUgYXBwbGljYXRpb24gbGF5 ZXIgdXNpbmcgQ09TRS4gVGhlIENvUkUgDQo+IFdHIHdpbGwgY29tcGxldGUgdGhlIHdvcmsgb24g dGhlIEdyb3VwIE9TQ09SRSBwcm90b2NvbCANCj4gKGRyYWZ0LWlldGYtY29yZS1vc2NvcmUtZ3Jv dXBjb21tKSB0aGF0IGVuYWJsZXMgT1NDT1JFLXByb3RlY3Rpb24gb2YgDQo+IENvQVAgbWVzc2Fn ZXMgaW4gZ3JvdXAgY29tbXVuaWNhdGlvbiBlbnZpcm9ubWVudHMuIEFsc28sIHRoZSBDb1JFIFdH IA0KPiB3aWxsIGNvbXBsZXRlIGFuIG9wdGltaXphdGlvbi1vcmllbnRlZCBwcm9maWxpbmcgb2Yg dGhlIEVESE9DIHByb3RvY29sIA0KPiBkZXZlbG9wZWQgaW4gdGhlIExBS0UgV0csIHdoZW4gdGhp cyBpcyB1c2VkIHRvIGVzdGFibGlzaCBzZWN1cml0eSANCj4gbWF0ZXJpYWwgZm9yIE9TQ09SRSAo ZHJhZnQtaWV0Zi1jb3JlLW9zY29yZS1lZGhvYykuIEZ1cnRoZXJtb3JlLCB0aGUgDQo+IENvUkUg V0cgd2lsbCBwZXJmb3JtIG1haW50ZW5hbmNlIGFzIHdlbGwgYXMgcG9zc2libGUgdXBkYXRpbmcg YW5kIA0KPiBjb21wbGVtZW50aW5nIG9mIHRoZSAoR3JvdXApIE9TQ09SRSBkb2N1bWVudHMgYWJv dmUgYXMgcmVxdWlyZWQuDQo+DQo+IFRoZSBBQ0UgV0cgaXMgZXhwZWN0ZWQgdG8gcHJvdmlkZSBz b2x1dGlvbnMgb24gYXV0aGVudGljYXRpb24gYW5kIA0KPiBhdXRob3JpemF0aW9uIHRoYXQgbWF5 IG5lZWQgY29tcGxlbWVudGFyeSBlbGVtZW50cyBvbiB0aGUgQ29SRSBzaWRlLg0KPg0KPiBUaGUg Q29SRSBXRyB3aWxsIGNvb3JkaW5hdGUgb24gcmVxdWlyZW1lbnRzIGZyb20gbWFueSBvcmdhbml6 YXRpb25zIA0KPiBhbmQgU0RPcy4gVGhlIENvUkUgV0cgd2lsbCBjbG9zZWx5IGNvb3JkaW5hdGUg d2l0aCBvdGhlciBJRVRGIFdHcywgDQo+IHBhcnRpY3VsYXJseSBvZiB0aGUgY29uc3RyYWluZWQg bm9kZSBuZXR3b3JrcyBjbHVzdGVyICg2TG8sIDZUaVNDSCwgDQo+IExXSUcsIFJPTEwsIEFDRSwg Q0JPUiwgQ09TRSwgSU9UT1BTLCBMQUtFLCBTVUlUKSwgYW5kIHdpdGggZnVydGhlciANCj4gYXBw cm9wcmlhdGUgZ3JvdXBzIGluIHRoZSBJRVRGIE9QUyBhbmQgU2VjdXJpdHkgQXJlYXMuIFdvcmsg b24gdGhlc2UgDQo+IHN1YmplY3RzLCBhcyB3ZWxsIGFzIG9uIGRhdGEvaW50ZXJhY3Rpb24gbW9k ZWxzIGFuZCBkZXNpZ24gcGF0dGVybnMgDQo+IChpbmNsdWRpbmcgZm9sbG93LXVwIHdvcmsgYXJv dW5kIHRoZSBDb1JFIEludGVyZmFjZXMgZHJhZnQpIHdpbGwgDQo+IGFkZGl0aW9uYWxseSBiZW5l Zml0IGZyb20gY2xvc2UgY29vcGVyYXRpb24gd2l0aCB0aGUgVGhpbmctdG8tVGhpbmcgDQo+IFJl c2VhcmNoIEdyb3VwLg0KPg0KPiA9PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPg0KDQotLSAN Ck1hcmNvIFRpbG9jYQ0KUGguRC4sIFNlbmlvciBSZXNlYXJjaGVyDQoNCkRpdmlzaW9uOiBEaWdp dGFsIFN5c3RlbQ0KRGVwYXJ0bWVudDogQ29tcHV0ZXIgU2NpZW5jZQ0KVW5pdDogQ3liZXJzZWN1 cml0eQ0KDQpSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQpodHRwczovL3d3dy5y aS5zZQ0KDQpQaG9uZTogKzQ2ICgwKTcwIDYwIDQ2IDUwMQ0KSXNhZmpvcmRzZ2F0YW4gMjIgLyBL aXN0YWfDpW5nZW4gMTYNClNFLTE2NCA0MCBLaXN0YSAoU3dlZGVuKQ0KDQoNCg== From nobody Mon Sep 20 09:22:24 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5563A00C4 for ; Mon, 20 Sep 2021 09:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXwZZRO78fDB for ; Mon, 20 Sep 2021 09:22:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3C43A0063 for ; Mon, 20 Sep 2021 09:22:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E7301889A; Mon, 20 Sep 2021 12:29:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G5alxjSup1iC; Mon, 20 Sep 2021 12:29:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 60F5218899; Mon, 20 Sep 2021 12:29:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 17FDB15B; Mon, 20 Sep 2021 12:22:08 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FB=3FR8O2cmFuIFNlbGFuZGVy=3F=3D?= cc: "core\@ietf.org" In-Reply-To: References: <19899.1632082533@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] CoAP option for Well-Known Uri-Path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 16:22:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable G=C3=B6ran Selander wrote: > Do you mean something like this: > https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/s= lides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00.pdf I knew that someone had thought about this before. Carsten Bormann wrote: > I think the main reason that we didn=E2=80=99t do this right away was= that the > original Usage (. Well known core) was relatively rare and implied ev= en > larger data. But with other protocols using wk it may start making mo= re > sense. Unfortunately, there is no option position left that would keep > the correct order in the Uri. Oh well. Oh, in terms of options being always incrementing. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFItS8ACgkQgItw+93Q 3WWasQf/eKdNAWAhSQR2b6UsS72F2NKBpn8Liun2op0o96Gvi0efhvBLD5lxK7J6 hAd8+uFrpdNh71emMvz0nzhJpJGIoyT+AdpVSQuMvo/+yrQom2IR9m67Vg258IpI UsSfeBUIwkFzaHOO0S+WAfAQmZhKCGctooWDesK1FKuw6+3OEBdlNq/2JJ8QPI6b 5+GXMyvdtKNJrY7FzUeJyv8E/jiwxzLAHqwO5VO3rZ/c4sMylWUl5tq9865G0kys Clw2QHnLw2QdvbmOyWVn83IMzaisfWB+o+XCU4HaKN/p6bUwUMB8rDXEWAYyu4jW 8rB5VGQsD1Jkq072JHf+VWqglegDQg== =y5Ba -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 21 01:39:19 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 317DE3A1206; Tue, 21 Sep 2021 01:38:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez , jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <163221352718.31036.11922703653380735485@ietfa.amsl.com> Date: Tue, 21 Sep 2021 01:38:47 -0700 Archived-At: Subject: [core] Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2021 08:38:48 -0000 Robert Wilton has entered the following ballot position for draft-ietf-core-senml-data-ct-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I have to confess that I am less convinced of the need to have two ways to represent this information, i.e., to also support Content-Format-Strings as opposed to always requiring a entry in the CoAP Content-Formats registry. The CoAP Content-Formats registry seems to be of reasonable size and have a lot of space available for FCFS allocations which would mean that it should be quite easy to extend if required. However, I'm willing to defer to the authors & CORE WG expertise here supporting both ways are needed/useful. Regards, Rob From nobody Wed Sep 22 10:40:08 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBD13A2A9B; Wed, 22 Sep 2021 10:40:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez , jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163233240502.20840.5498014177264082102@ietfa.amsl.com> Date: Wed, 22 Sep 2021 10:40:05 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2021 17:40:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-senml-data-ct-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple points for discussion, essentially relating to how much we're diverging from HTTP and to what extent the specifics of the divergence should be specifically mentioned in the document. (1) I'd like to dig a little more into the analogy with HTTP and whether we are artificially limiting ourselves: currently we only allow 0 or 1 content-codings to be specified, but per https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-content-encoding the HTTP ecosystem permits multiple codings to be applied in turn to the same representation. While the sensor data values are likely to be relatively small and applying multiple content-codings is not likely to be useful in such a scenario, this seems like something where we should only consciously diverge from HTTP, rather than inadvertently doing so. (2) Let's also discuss whether we want to reuse ABNF rule names from HTTP while having the rule content diverge, without specific enumeration of the divergence. So far I found instances where this document does not allow HTAB or obs-text in places that draft-ietf-httpbis-semantics does, which may well be the right way to spell the rule, but seems to merit a little discussion. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do we want to comment anywhere about the situation where an implementation receives a message using an IANA-registered numeric content-format that is "too new" for that implementation to know about? It also feels a little weird that we have to end up using the text-string encoding of a decimal number for the Content-Format, even for the CBOR representation of SenML structures, but I guess that's what RFC 8428 intended and not worth trying to change. Abstract I'm somewhat sympathetic to the gen-art reviewer's contention that the new field is not indicating the "Content-Format" of the binary data values (since Content-Format is a defined term in CoAP and SenML is claimed to not be limited to CoAP usage). Perhaps we could switch around the order of description, i.e., "for indicating the Internet media type (including parameters) of these binary data values (i.e., the CoAP Content-Format that would apply when CoAp is used), as well as any content-coding that is applied"? Section 3 * a CoAP Content-Format identifier in decimal form with no leading zeros (except for the value "0" itself). This value represents an unsigned integer in the range of 0-65535, similar to the CoRE Link Format [RFC6690] "ct" attribute). Should we also reference https://datatracker.ietf.org/doc/html/rfc7252#section-7.2.1 which is where the "ct" link attribute is actually defined? I spent a bit of time looking for it in 6690 itself only to discover that it was removed in draft-ietf-core-link-format-07 with remark "Moved [...] to the base CoAP specification". The CoAP Content-Format number provides a simple and efficient way to indicate the type of the data. [...] If we're limited to string representation, is it really "efficient" in a CBOR context? Section 6 ; Cleaned up from RFC 7231: (per the DISCUSS,) I'm a bit anti-enthused about saying "cleaned up" without saying what changed (i.e., whether it's just refactoring, or actual changes to the rule like requiring specifically *SP instead of OWS that allows HTAB as well). Section 7 These security considerations are well-thought-out and nicely written. Thank you! I think there are some (rare) situations where individual media-type (specifications) have their own security considerations, but I'm not really convinced that we need to mention that/incorporate them by reference, here. NITS Section 1 The receiver is expected to know how to interpret the data in the "vd" field based on the context, e.g., name of the data source and out-of-band knowledge of the application. However, this context may not always be easily available to entities processing the SenML pack. I'd consider adding ", especially if the pack is propagated to multiple entities". Section 2 Content-Coding: A name registered in the HTTP Content Coding registry [IANA.http-parameters] as specified by Section 8.5 of [RFC7230], indicating an encoding transformation with semantics further specified in Section 3.1.2.1 of [RFC7231]. [...] (I expect that the RFC Editor will be able to replace the references to point to draft-ietf-httpb-semantics if it has been published before this document.) Section 4 up to the end of the pack otherwise. Resolution (Section 4.6 of [RFC8428]) of this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field. The conjugation "resolution" does not actually appear in RFC 8428 itself, just discussion of "resolved records" and "to resolve the records". It might be helpful to tweak things so that we don't rely on the reader knowing the irregular conjugation (but I don't have any good ideas off the top of my head)... From nobody Wed Sep 22 14:53:59 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611E63A0E18 for ; Wed, 22 Sep 2021 14:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh1OYkxAqc5P for ; Wed, 22 Sep 2021 14:53:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6F23A0E13 for ; Wed, 22 Sep 2021 14:53:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 89E9C18101; Wed, 22 Sep 2021 18:01:06 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HMePwD6U0-PC; Wed, 22 Sep 2021 18:01:02 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 35F611809D; Wed, 22 Sep 2021 18:01:02 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9222A40; Wed, 22 Sep 2021 17:53:44 -0400 (EDT) From: Michael Richardson To: "Murray S. Kucherawy" , core@ietf.org In-Reply-To: References: <106211.1632084796@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2021 21:53:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Murray S. Kucherawy wrote: > I'm happy to take credit for a keen observation such as this, but this > was actually Eric Vyncke. sorry, if I screwed that attribution up when creating the issues. >> I also wonder about this. I think that the SID concept is advanced >> enough that we can just rely upon it. Murray's comment is that if we >> support two things, then an encoder needs to pick one, and it's like= ly >> wrong. Since this is often data at rest, there is no possible >> negotiation either. >> >> I propose to remove section 4.1.2: There are also other parts of the document which refer to names as well. I have no use for names. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFLpegACgkQgItw+93Q 3WUDuAf/cLUlcaBsZlxl07Ndcnxl2BB3bGocGWFWhae67nuEhdAKjS1ALPNOekVf aFtngR7FuO/EqkAwZ9rnWK8PnxPDfbsmAtmfgZOfch7TM5WgQv1weDtXlu2etm5b cg6kJqpa+U5XZo3BhyZ3gzKgqIpRHy1pGdP6bTobhOubVptLkmRaM2fpEU+WUgoR ovTSh3jpyMX8vNYzwxt0y9u1+FimlRMBSAHlmAAiX/4/xxjJ8NbMPSZwuY2b4DWm SMgzZmZggQ0EYvk4kpgZ0qaRKEX1O6cOVNbxs/vvE90bdKmp7ZL+4BO3WjNYnNGT rV9U75z21gamV4KN9/Dz/UIo8cYhZA== =a2sT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 22 16:01:56 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33F23A08B1 for ; Wed, 22 Sep 2021 16:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.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 qXmJFggIosRN for ; Wed, 22 Sep 2021 16:01:45 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 08DDB3A089B for ; Wed, 22 Sep 2021 16:01:44 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id t10so18490521lfd.8 for ; Wed, 22 Sep 2021 16:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wE/jRxl3iSS85uCs2fxYM36BeAHOCg5jAD31YsJbM0Q=; b=QodwStkC1H65EeklHOQxIEQXZuujVMWiJu7tsX36PG+F0ge2xJu4Ko1lW406YdYC5r HuNLS4XL6rlluN5kJsejZEH5HLNpmyKyHUhfJOe3iem+3wgXNSJjn/wwpwnSHFPNhXjV fUOMKsp+aAif5g4Kkoai06mn+akvTNqQaHrtmav8v5q+bRgxgKoETB3Bqm6x/nY40FtY t2E5HZwSOQkse4MB1gXGwtxN38jsOphqD8D4d196otvAiVdxVml33n4zXGeLYrNLolhl SsabaWkxhqOVk1Ae68pEZrcuMrOMwUHz4pz+exeJ0pIEM299gXtnrq1ZRns3v5YQpDul FhKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wE/jRxl3iSS85uCs2fxYM36BeAHOCg5jAD31YsJbM0Q=; b=brSWTtTJY/BKO6010gjPATgmVPqkwsaA+AM0AUIHhE5X1HXB8m7Iiw+jn8LUUb5bnS IBg4o/8mK0iS3a/4ww1I4iVbH6NVPSIj+18wGiTpRg/FWo3mcu7HJnwtnrwnY/9qUEtu 2svaRN1un78bb41h2q65FUtyl5TOlOIUNc1Xuv7ilAbnsYTNWsr0OoJc4E3WfvXQgRYe QGEJQ1SCGyvwj83dOKj1oxD5UT1VEste9R7I/c5k3qyjKozHynroic3xiL4gCrD9lA1D ZGH1Zyjgu5HaMfmM0vpmnZu+AWlQ5ReVgubFpLWakmT88OrILL/N4AY7VpUC+uKOzi7z 2PgA== X-Gm-Message-State: AOAM531RKng+q0GKbNG+37EIEI67GqW/pBdgKl2kHRs16k2YZqOo25r/ Yea4s6zBpwo1xMrdlMqBngsvqpoJ63Pwob4+5EZxYL8onrc= X-Google-Smtp-Source: ABdhPJyiHXEsod1bMXzKeys6rsMUgezR6CvBny6nFtEFnnd48G21jl+5XBazayzRXL8z4bkAHUO6azPRMjJRk6Beqt0= X-Received: by 2002:a2e:804c:: with SMTP id p12mr1953222ljg.344.1632351702919; Wed, 22 Sep 2021 16:01:42 -0700 (PDT) MIME-Version: 1.0 References: <106211.1632084796@dooku> <3892.1632347624@localhost> In-Reply-To: <3892.1632347624@localhost> From: Andy Bierman Date: Wed, 22 Sep 2021 16:01:32 -0700 Message-ID: To: Michael Richardson Cc: "Murray S. Kucherawy" , Core Content-Type: multipart/alternative; boundary="00000000000066bd7d05cc9d7f40" Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2021 23:01:53 -0000 --00000000000066bd7d05cc9d7f40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson wrote: > > Murray S. Kucherawy wrote: > > I'm happy to take credit for a keen observation such as this, but > this > > was actually Eric Vyncke. > > sorry, if I screwed that attribution up when creating the issues. > > >> I also wonder about this. I think that the SID concept is advance= d > >> enough that we can just rely upon it. Murray's comment is that if > we > >> support two things, then an encoder needs to pick one, and it's > likely > >> wrong. Since this is often data at rest, there is no possible > >> negotiation either. > >> > >> I propose to remove section 4.1.2: > > There are also other parts of the document which refer to names as well. > I have no use for names. > > I agree it is better to remove the string name variant and only support SIDs as names. It will be important for the client to be able to obtain the SID File URL list representing all SIDs used by the server. This is needed before the client can use any data from the server (including the CORECONF YANG library). The client will have to be hard-wired with the SIDs or capable of consuming SID files in JSON format. > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > Andy > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000066bd7d05cc9d7f40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 22, 2021 at 2:54 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
=C2=A0 =C2=A0 > I'm happy to take credit for a keen observation such= as this, but this
=C2=A0 =C2=A0 > was actually Eric Vyncke.

sorry, if I screwed that attribution up when creating the issues.

=C2=A0 =C2=A0 >> I also wonder about this.=C2=A0 I think that the SID= concept is advanced
=C2=A0 =C2=A0 >> enough that we can just rely upon it.=C2=A0 Murray&#= 39;s comment is that if we
=C2=A0 =C2=A0 >> support two things, then an encoder needs to pick on= e, and it's likely
=C2=A0 =C2=A0 >> wrong.=C2=A0 Since this is often data at rest, there= is no possible
=C2=A0 =C2=A0 >> negotiation either.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I propose to remove section 4.1.2:

There are also other parts of the document which refer to names as well. I have no use for names.


I agree it is better to remove the str= ing name variant and only support SIDs as names.
It will be impor= tant for the client to be able to obtain the SID File URL list
re= presenting all SIDs used by the server. This is needed before the client ca= n
use any data from the server (including the CORECONF YANG libra= ry).

The client will have to be hard-wired with th= e SIDs or capable of consuming SID files in JSON format.



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




Andy
=C2=A0


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000066bd7d05cc9d7f40-- From nobody Wed Sep 22 21:35:55 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4FF3A1DDC for ; Wed, 22 Sep 2021 21:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNIUCjV073ye for ; Wed, 22 Sep 2021 21:35:48 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795533A1DDB for ; Wed, 22 Sep 2021 21:35:47 -0700 (PDT) Received: from smtpclient.apple (unknown [194.156.182.213]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HFMmH26JMz2xLL; Thu, 23 Sep 2021 06:35:43 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-61FF55D3-1425-48AF-858F-B262D41F983A Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: Date: Thu, 23 Sep 2021 06:35:41 +0200 Cc: Michael Richardson , "Murray S. Kucherawy" , Core Message-Id: References: To: Andy Bierman X-Mailer: iPhone Mail (18H17) Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 04:35:54 -0000 --Apple-Mail-61FF55D3-1425-48AF-858F-B262D41F983A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Clearly, SIDs are the major innovation here and they are the normal way to u= se Yang-cbor.=20 I don=E2=80=99t agree the string variant should be removed. This takes Yang-= cbor out of the game for =E2=80=9Cbig-web=E2=80=9D applications.=20 Instead, we should make sure to explain that strings are a special option th= at you chose wholesale when you need it, not something you switch to from SI= Ds randomly.=20 Sent from mobile, sorry for terse > On 23. Sep 2021, at 01:02, Andy Bierman wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson wrote: >>=20 >> Murray S. Kucherawy wrote: >> > I'm happy to take credit for a keen observation such as this, but t= his >> > was actually Eric Vyncke. >>=20 >> sorry, if I screwed that attribution up when creating the issues. >>=20 >> >> I also wonder about this. I think that the SID concept is advance= d >> >> enough that we can just rely upon it. Murray's comment is that if= we >> >> support two things, then an encoder needs to pick one, and it's li= kely >> >> wrong. Since this is often data at rest, there is no possible >> >> negotiation either. >> >> >> >> I propose to remove section 4.1.2: >>=20 >> There are also other parts of the document which refer to names as well. >> I have no use for names. >>=20 >=20 > I agree it is better to remove the string name variant and only support SI= Ds as names. > It will be important for the client to be able to obtain the SID File URL l= ist > representing all SIDs used by the server. This is needed before the client= can > use any data from the server (including the CORECONF YANG library). >=20 > The client will have to be hard-wired with the SIDs or capable of consumin= g SID files in JSON format. >=20 >=20 >>=20 >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >>=20 >>=20 >=20 >=20 > Andy > =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 --Apple-Mail-61FF55D3-1425-48AF-858F-B262D41F983A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Clearly, SIDs are the major innovation here= and they are the normal way to use Yang-cbor. 

I do= n=E2=80=99t agree the string variant should be removed. This takes Yang-cbor= out of the game for =E2=80=9Cbig-web=E2=80=9D applications. 

Instead, we should make sure to explain that strings are a s= pecial option that you chose wholesale when you need it, not something you s= witch to from SIDs randomly. 

Sent from mobile, sorry for terse

On 23. Sep 2021, at 01:02, Andy Bierman &= lt;andy@yumaworks.com> wrote:

=EF=BB=BF


On Wed= , Sep 22, 2021 at 2:54 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
    > I'm happy to take credit for a keen observation such as t= his, but this
    > was actually Eric Vyncke.

sorry, if I screwed that attribution up when creating the issues.

    >> I also wonder about this.  I think that the SID c= oncept is advanced
    >> enough that we can just rely upon it.  Murray's c= omment is that if we
    >> support two things, then an encoder needs to pick one= , and it's likely
    >> wrong.  Since this is often data at rest, there i= s no possible
    >> negotiation either.
    >>
    >> I propose to remove section 4.1.2:

There are also other parts of the document which refer to names as well.
= I have no use for names.


I agree it is better to remove the stri= ng name variant and only support SIDs as names.
It will be importa= nt for the client to be able to obtain the SID File URL list
repre= senting all SIDs used by the server. This is needed before the client can
use any data from the server (including the CORECONF YANG library).<= /div>

The client will have to be hard-wired with the SIDs= or capable of consuming SID files in JSON format.

=

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T cons= ulting )
           Sandelman Software Works Inc, Ottaw= a and Worldwide




Andy
 


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core m= ailing list
core@ietf.org
https://www.ietf.o= rg/mailman/listinfo/core
= --Apple-Mail-61FF55D3-1425-48AF-858F-B262D41F983A-- From nobody Wed Sep 22 22:02:54 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 782D03A1F05; Wed, 22 Sep 2021 22:02:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <163237337180.27394.12786590683382878123@ietfa.amsl.com> Date: Wed, 22 Sep 2021 22:02:52 -0700 Archived-At: Subject: [core] Murray Kucherawy's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 05:02:53 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-senml-data-ct-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be easy to resolve: The SenML Labels registry specifies a column called "EXT ID" (or actually just "EI" in RFC 8428) that is absent from the registrations in Section 8. If that column should be empty for these new registrations, that should be explicit rather than implicit. From nobody Thu Sep 23 06:25:27 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F12C3A205D; Thu, 23 Sep 2021 06:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LDNJxwav5Zp; Thu, 23 Sep 2021 06:25:07 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70072.outbound.protection.outlook.com [40.107.7.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27D43A1DB1; Thu, 23 Sep 2021 06:25:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jnzhxxe1L6B8fyr8m6+YWS99O6fjveS2KoDHSJmdj/zhMHKRyEiAWKd5fZ7XmhzeY9CQj7egMRr7tAo2XL6PVWU2SfhJKBxag0DFEeGx0FBcHHlNHNHhdS+34eu3KHKrxwGl0uP3gbbT8FUCryhSA+mNX8nZwjYEjB2RBxrd7DOFhCqspxdYs8pW9t4qGxrF96TC9aIlkoZQoTe2J/flkPbhjAAh/gcxxubzm4AD+XmcOivpWpjSp6VJ9LQd2By/dmSlYqABfnDGTZbYu2IxIbioHoBWTmd0evUKczfBaRzg1y899Z9ptBhgcqswNOXW3hf61x6CfC41a4hXb7BjUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=48d6wrDlP1CF8jI3CuLDUEI7/Y/rqM4stN0NAq5UQNw=; b=ME4sIloEsij4ufknc6oea4VYjKVFxAlTV5MXJ6ZgXrfYLadfO3t6PYPQtFqE8wXYsx+V074lswJTPNWX00fROvTj2wMchJ7FcLOlowkmWjbBGPghX18dHCqtKc56tu4TYIYm4nZMdQb2fGHsShu7S50p+TpH2HNgehSDkFv0KqGQpO89uKeDkZNK18EV1ZKIlWb+qYAtVYWdFiYWduBp+HmFG1EL/+ApE/TmDzDdAnfh98Bp0XWZlNPcTbkJ5CQO9nyX8jUSPL76nRRh7P6DePu3pzh0DWUTdb+8jzmKWUMQafadL9JX07mcjZATpIKh/JiM+B3vq9Zs9maipu3PYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=48d6wrDlP1CF8jI3CuLDUEI7/Y/rqM4stN0NAq5UQNw=; b=ZvZpvKR5yOZjpMbY4JLK5b+JtsGsuQwwn8gLuYe8un8hQI8sJKUKFCyPnLrY2DzGARFgAHE032+kvHmcjI9UZ1BcDbff2SsO2V9A8nhTd+2zazXwCmayFeNDbpV75OIG+R2+3TQLbB6xFIERbuO39B5yXyjJyj2MGyeNgMaRnfk= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB4219.eurprd07.prod.outlook.com (2603:10a6:7:9f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.9; Thu, 23 Sep 2021 13:24:58 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875%5]) with mapi id 15.20.4544.013; Thu, 23 Sep 2021 13:24:58 +0000 From: Francesca Palombini To: Murray Kucherawy , The IESG CC: "draft-ietf-core-senml-data-ct@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: [core] Murray Kucherawy's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS) Thread-Index: AQHXsDhPvgxbsXecTkGjgKVYAGFJqquxmrBj Date: Thu, 23 Sep 2021 13:24:58 +0000 Message-ID: References: <163237337180.27394.12786590683382878123@ietfa.amsl.com> In-Reply-To: <163237337180.27394.12786590683382878123@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f96e431-6820-4067-6c99-08d97e958a47 x-ms-traffictypediagnostic: HE1PR07MB4219: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /I8AB1Y4h5YtAj0PsnhYxT5TrZ8FmDInNT0TBJk0Tupjtnc3LTIipxwSV88OzlQ5vYMVvkWv2sPE0f9AY2WSQ45JsTQEM2vm4wllQSs5IuHtSEu5EU/rl/hDCcSi0AFBesQV06ERpBt+OCDmvkwmA4LNVkptmWG4Yl0R/vQDiyrkvviCdQCvBfi99l93cxY601FB0R6dpU6dYTWcuVorHDRS5s0HRT7cGRRLi/TJzA/Vi10d7lSs1jZSmcjopDXfP2Jr6vSHT4fb9xEAQmOaVOoLG2pzqFWnbsGWJxiHBkhdP/zLJHguNldxXFhvwPg1aTtiPBLbzWkWgDXbCyrrSgj9apoJNFoSAXTBTHI2cyo5jI1MlfGpOmKIl/MShTu31o8NHv5bXfEYMqYrn7merlRZr1ODtW13a1UC2MGjMPgSY6ejnNB3XV0xoOn0hurLskAAF1rP89aUg7jffspMLtFIEj0QP7SVgyYxjE3nEwWe0heqX+oHrXKCxwJCRFrdjTyrnU9fV5FPd587co85BqVhots7BFY6hndbSHcxOmSVZSkIQ1JbNvXQ9/h846yI0r3WhV40Y2lXyddqjIkYhHmLfbjvIsM2F610008f522hQ2sRm2hSpQxECeywGa+SEYSkFU7ER1IU0uZZ75GAl5bgYMR8CmVdPtBBGsXz7JnJF4+5TTZMfW4FlEG6VJk2L9jase0Ey9IpExC8fv3j5H13jfs3rnlGqfqrSc1pt6Si4XU4Y6ptjAkzC2xYI8XrlXZGCXzotSlu5oU3baDlL+dqvilHnAJctOhKnxxiRTE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(55016002)(53546011)(6506007)(66556008)(186003)(9686003)(4326008)(166002)(110136005)(71200400001)(316002)(64756008)(5660300002)(38070700005)(38100700002)(122000001)(52536014)(508600001)(66446008)(76116006)(54906003)(44832011)(8676002)(9326002)(2906002)(966005)(33656002)(7696005)(8936002)(66946007)(86362001)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?MPdDFX8zpja+RlXzIgSMYfa8LHAN2STkuXYypT8ryAB/kGSX3eRokK1a?= =?Windows-1252?Q?VXI6j9A7WSdxV2f2bilL6kdfAr81qNcoe5mNErxWXaQz8ZXEKw0gEh7C?= =?Windows-1252?Q?lE28uUKVM0iAYimQtZP+QduGSYEEn7CP2XmIXGD9YWnJvVl/EKszlY1v?= =?Windows-1252?Q?XGWS7Z5ka3rDv0ME4lQi+bhGUja32Sj109sEXBuuLFdQtffAP25erzBr?= =?Windows-1252?Q?QQY/whsPiQiYfX4C4rfx1KqOO06Hr2QV9ybRITZyp8moEZE4/43shSRB?= =?Windows-1252?Q?LdKhwkQXzdnmiF40Lydk00hvCUBqqwKORNVLUBy7NBzG/xNRWBOKIxqK?= =?Windows-1252?Q?3Q8XCHwAuUpHhaoMNVMzxrAuxBs+Xm1DYHN4rcH3jHOleEiEsjgh4V6D?= =?Windows-1252?Q?n7Hzxu99/rmYdHEWKpsXjiPDr14Nx2GFX8qy5fra0VVaoHa5DfE8bPz2?= =?Windows-1252?Q?giI/QsvjFZ4jYauO0l2S+DWxt73sTYiBRXX/YnEmv8dMEM04hhQi+EHn?= =?Windows-1252?Q?I7PbQ/Wcp+SHBYiF5+5tuKEtyF+ONoLOyFZKHS+jFbc60l8JlytDwV0f?= =?Windows-1252?Q?0VwfY4rlojYQMY7EOZrqlHzk/J8Gip+hUG4F83SCaGdwmYGcTvPIeBfK?= =?Windows-1252?Q?GCn4tcmVqh3YDc1rPfyiEvMMVz587t1rTMUlrZ42liNio+9QW4kgNW9e?= =?Windows-1252?Q?e+LixqvXymOLmSK6N73paCD3uI5elK84z8Ax13gCR5aadh0+UJrWVeJD?= =?Windows-1252?Q?a/D15V/tTvLsMhz9IfvXJnac2g84hkrINkWmsgOogAdR+FmjXIT4XHVE?= =?Windows-1252?Q?FaX/Zu3+/jfTwpghBxEp3ZcmsKI3i+CliuEAEpySDCa9j9pMJvDKHktt?= =?Windows-1252?Q?zx07mW+8dKLVXeQuqIzarnuQc/HFKQ1uwL5Z/S0pGQbesTNGjEwukHrl?= =?Windows-1252?Q?1jVOeFfap0VE1OBYz4ms6yNhQMbXh5owfVAAMEH8Gx0teA6YoSFGVo1K?= =?Windows-1252?Q?DZvwG3EmkiLfYcGvKh8yLnlKW1voJ6d8Cq/xZZE4z5eskH1qMpAyk5Va?= =?Windows-1252?Q?SzIXjW40fhCmXOSq69QbJFI31cBO5NlaB8TEq2xjBt9Om+GahqzMfVoB?= =?Windows-1252?Q?kBpG0zRRuwyp5Mj/N74Me3enNkgKzQ45HXmWDjMPykRUu5IAhijJtK+v?= =?Windows-1252?Q?v/MQnhrgDMeD21cme1Z8KFeSJe61RNzx0Um8SVgfZzuTXYrzwD9PSCUI?= =?Windows-1252?Q?WwbgijGCdOGMmXIIj+9X/Ke63pTPpnv4xH06lWq7BfbHy26v6VDybRRw?= =?Windows-1252?Q?ED4faeKTi4RLdTjsUxNsjEkZWJ8DYHnu6cIVbtxpGERDpMiBA0++nAel?= =?Windows-1252?Q?J/bSttXoAjmKqfNjed2bcQL+0PjRfdU/z120EUIfmfsRzdzJd6kWOXd+?= =?Windows-1252?Q?YcMyDUP1wq89moFuJsw3SDBX6yR1Z1ydSe1b3bl218oSVD6zfYaEoSaZ?= =?Windows-1252?Q?3XvJ9Hg8XjYxoPE7m4sokwv6O9ZH/g=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB421731626A0D3CFF5C1E503F98A39HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f96e431-6820-4067-6c99-08d97e958a47 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2021 13:24:58.3680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oC9mFK5dKXQ+352Gm+FSOVTBEnz7KtIVDluH04Kx6APSRASfRiKEzS8xVlX4kRktuJeWTppoqlzcwt1LiYgouh/FIHWlFU8HClopqOYvEFBXrWsMIQ3FDnsY8OVasKE+ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4219 Archived-At: Subject: Re: [core] Murray Kucherawy's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 13:25:13 -0000 --_000_HE1PR07MB421731626A0D3CFF5C1E503F98A39HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Murray, That column should indeed be left empty (I got clarifications about it duri= ng my AD review): > 9. ----- > > FP: In Section 8, several columns for the registration of SenML labels ar= e missing: CBOR label, exi ID. As they should be: RFC8428 12.2: [=85] the CBOR labels SHOULD be left empty as CBOR will use the string encoding for any new labels. The EI column contains the EXI schemaId value of the first schema that includes this label, or it is empty if this label was not intended for use with EXI. This was also clarified with IANA, so they know, but I am sure the authors = will have no problem to explicitly add it to the document. Thanks, Francesca From: core on behalf of Murray Kucherawy via Datatr= acker Date: Thursday, 23 September 2021 at 07:03 To: The IESG Cc: draft-ietf-core-senml-data-ct@ietf.org , core-chairs@ietf.org , core@ietf.org Subject: [core] Murray Kucherawy's Discuss on draft-ietf-core-senml-data-ct= -05: (with DISCUSS) Murray Kucherawy has entered the following ballot position for draft-ietf-core-senml-data-ct-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be easy to resolve: The SenML Labels registry specifies a column called "EXT ID" (or actually j= ust "EI" in RFC 8428) that is absent from the registrations in Section 8. If t= hat column should be empty for these new registrations, that should be explicit rather than implicit. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_HE1PR07MB421731626A0D3CFF5C1E503F98A39HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Murray= ,

&nbs= p;

That colu= mn should indeed be left empty (I got clarifications about it during my AD = review):

&nbs= p;

> 9. -----

>

> FP: In Section 8, several colum= ns for the registration of SenML labels are missing: CBOR label, exi ID.

 

As they should be:=

 

RFC8428 12.2:  [=85] the

  CBOR labels SHOULD be left em= pty as CBOR will use the string encoding

  for any new labels. The EI co= lumn contains the EXI schemaId value of

  the first schema that include= s this label, or it is empty if this

  label was not intended for us= e with EXI.

 

&nbs= p;

This was = also clarified with IANA, so they know, but I am sure the authors will have= no problem to explicitly add it to the document.

&nbs= p;

Thanks,

Francesca=

&nbs= p;

From: core <core-bounces@ietf.org> on be= half of Murray Kucherawy via Datatracker <noreply@ietf.org>
Date: Thursday, 23 September 2021 at 07:03
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-senml-data-ct@ietf.org <draft-ietf-core-senml= -data-ct@ietf.org>, core-chairs@ietf.org <core-chairs@ietf.org>, c= ore@ietf.org <core@ietf.org>
Subject: [core] Murray Kucherawy's Discuss on draft-ietf-core-senml-= data-ct-05: (with DISCUSS)

Murray Kucherawy has en= tered the following ballot position for
draft-ietf-core-senml-data-ct-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be easy to resolve:

The SenML Labels registry specifies a column called "EXT ID" (or = actually just
"EI" in RFC 8428) that is absent from the registrations in Sectio= n 8.  If that
column should be empty for these new registrations, that should be explicit=
rather than implicit.





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

--_000_HE1PR07MB421731626A0D3CFF5C1E503F98A39HE1PR07MB4217eurp_-- From nobody Thu Sep 23 07:05:17 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120813A00B0; Thu, 23 Sep 2021 07:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAk7oLVpMRSr; Thu, 23 Sep 2021 07:05:10 -0700 (PDT) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 6C2333A0061; Thu, 23 Sep 2021 07:05:10 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id y74so2605281vky.12; Thu, 23 Sep 2021 07:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7lEaDJ2YUsy53anMZ4yeDQoPXFYuBs49Y20efgXZLHc=; b=J57F9aJeP7VnVo9mGsTiYLnRZPBbbaIA25+fV5+iEbWxoDmmylKydvVk5P1o8HAa5Z +g7h8pG0vccAxIZKhu8zd/B6RM8l9gS4sbQC9iOPJJaiXwjKJSuylUQqEZJQsm311Ju6 MG7T3Y6OY9JZQonNFnEK4lQkPqa58oaLazC9Sx0qrST74pXTgSSB39WMVmAXUhB4jhuy cjUosR+x6Y70zdZwtdpH4qycpD6OfhL8IdSKhYikUtZZjJD8FzgCUFUqpusJc6ygRDtO 0+LJMpDk1SzIre6lvX74lfoD9haoWYE4IxKkm3IZVfREUBCmdXzGZGPbYqLDpJJ+/flF kCKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7lEaDJ2YUsy53anMZ4yeDQoPXFYuBs49Y20efgXZLHc=; b=HUtFv6PZLPRduzmfdX8ld1/7XL30zmd5XfVs8FoZLYhWSCUkjKK75qiV159C52aOQY YHLPbvlGsYn5N87L5q7NiMFoQwYhApVk3UGDggVOQ1XylaH+0osHmwlYRZ/mZLg5ZO4g NihugSac2mAmsiQR2NFVWei7PSsJclb8XHJNz+REsPuj5Q5v7E8GZPZ7oCCbZZuQITS7 D3rFJkkwMpraCS7O3WJv9BE8tcjacR2F9IOvUIXLglduOArd1qVkq+dbvAd0Fki3Q31h FxwU4xMy17GBwdZpjMbmo/zfGdn7nKoqVCG7sayaxHkAfFWIIwVuykq3hSq0tVBNNA3P V+qQ== X-Gm-Message-State: AOAM5325o1thoZUXMexAKp/tfSQXVA5gHeirNUQV1QEwqbv+oy9ba49K MV81bBP198wcitattuNCun8nMtUGKBeTSObMi/o= X-Google-Smtp-Source: ABdhPJw6D2iJPLRpdqaTWZjyaL9JFvlDbatzi58AYr8Mdu5yf6UxzjmsBtuy6xB714eJsDFDX/08cBQrMy++2wst9/A= X-Received: by 2002:a1f:3102:: with SMTP id x2mr3320243vkx.13.1632405908669; Thu, 23 Sep 2021 07:05:08 -0700 (PDT) MIME-Version: 1.0 References: <163237337180.27394.12786590683382878123@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 23 Sep 2021 07:04:57 -0700 Message-ID: To: Francesca Palombini Cc: The IESG , "draft-ietf-core-senml-data-ct@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050f9cb05ccaa1e60" Archived-At: Subject: Re: [core] Murray Kucherawy's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 14:05:15 -0000 --00000000000050f9cb05ccaa1e60 Content-Type: text/plain; charset="UTF-8" Hi Francesca, On Thu, Sep 23, 2021 at 6:25 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > [...] > > > > This was also clarified with IANA, so they know, but I am sure the authors > will have no problem to explicitly add it to the document. > Perfect, thanks! -MSK --00000000000050f9cb05ccaa1e60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francesca,

On Thu, Sep 23, 2021 at = 6:25 AM Francesca Palombini <francesca.palombini@ericsson.com> wrote:
[...]

=C2=A0

This was also clarified with IANA, so they kno= w, but I am sure the authors will have no problem to explicitly add it to t= he document.


Perfect= , thanks!

-MSK
--00000000000050f9cb05ccaa1e60-- From nobody Thu Sep 23 07:21:32 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D8E3A05A7 for ; Thu, 23 Sep 2021 07:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.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 1x4-citYtTIE for ; Thu, 23 Sep 2021 07:17:11 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F743A059F for ; Thu, 23 Sep 2021 07:17:10 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id b15so26618718lfe.7 for ; Thu, 23 Sep 2021 07:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NgGmKLjgPZyKCMubr3YNXTgnmKwbVvU/4OOAsbI7HE0=; b=vVVQADF5Z766MsKbuWsBMXxziR08bK9OtnQgHUK/92Uwb+lEiz3a25v7Yhsirbm9LZ 3p5gP/NtKMbwDWXfD42WnhNHKxpTP7zlnCGccTb9XqKDcKoFRRxOZCtto/vQZEW4N1HA lHQOoDeFTIjKWcDsS4Tc2l8egynWUBueGJy7oec/31oYLhdVc+C04NrunAp1LRP+tEpW sfnG4wMc92mbIsoZm+UM8c45P2DJLpptVHH3IZ6nrFQK85Sri/I4W5ahPSWTVjRZHGK8 id/n8WgkXYp21JGdnsyvTonelkOHaM6N/gYIXJQr8tQ+iNg+ESa+pfBClbiK+M2Tvmo1 Kzyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NgGmKLjgPZyKCMubr3YNXTgnmKwbVvU/4OOAsbI7HE0=; b=pxGeRaBRT3IvnKkz2QvbYj/2Yt32uGFJbZzUwVdLh/4arGbswHSHWBK+c/KDCRqVBe kdpfeHtuvsYttgLLtl+8kGgqocWktRmIavFq3apNcHyf6TtDja17Ki9xDv5Bb2gA0Fqo MTg5FJMDQpP7dVRURO2XqvMUvQb0wqdF827wFjNCfVL0mbq4IFNZUCPK76tNDuk4VEej Zrw6HgDuZK/E5Yyu9NwwMjvjlasHo8c855BaAoXfPRwkRXnPKE7caxtDfTo6u0l9u0uY A1trJhUiXGQ98oh629698VrUJVcyzhLY7DsRCpH0bbwq6HSjNfwpvTU6TLLtBMuLsT4l kKpg== X-Gm-Message-State: AOAM531hckS1HtJzRkBEiTElYYHlJrCZcmFdzW2MNaYKtVyqD2vTq+vV +W0m+gkHJv1xe8WUaYVOA57T29BCeJ5Fkz9TliSkRw== X-Google-Smtp-Source: ABdhPJyB6/CrhPP8crWfOpoRQC+LknrG+xE4//jkVeuwVB4OqoBND7RJ/+/eHOwxgSqz89ERmdUvXCJR019HAH0gEMs= X-Received: by 2002:a2e:804c:: with SMTP id p12mr5547195ljg.344.1632406621743; Thu, 23 Sep 2021 07:17:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Thu, 23 Sep 2021 07:16:50 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "Murray S. Kucherawy" , Core Content-Type: multipart/alternative; boundary="000000000000d17d1305ccaa484a" Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 14:17:17 -0000 --000000000000d17d1305ccaa484a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann wrote: > Clearly, SIDs are the major innovation here and they are the normal way t= o > use Yang-cbor. > > I don=E2=80=99t agree the string variant should be removed. This takes Ya= ng-cbor > out of the game for =E2=80=9Cbig-web=E2=80=9D applications. > > Instead, we should make sure to explain that strings are a special option > that you chose wholesale when you need it, not something you switch to fr= om > SIDs randomly. > > The problem with this approach (no negotiation, either peer sends SID or string at any time) is that it forces complexity on a constrained device that a giant NETCONF router is not even expected to support. It also forces a constrained device to store the string names. Andy Sent from mobile, sorry for terse > > On 23. Sep 2021, at 01:02, Andy Bierman wrote: > > =EF=BB=BF > > > On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson > wrote: > >> >> Murray S. Kucherawy wrote: >> > I'm happy to take credit for a keen observation such as this, but >> this >> > was actually Eric Vyncke. >> >> sorry, if I screwed that attribution up when creating the issues. >> >> >> I also wonder about this. I think that the SID concept is advanc= ed >> >> enough that we can just rely upon it. Murray's comment is that i= f >> we >> >> support two things, then an encoder needs to pick one, and it's >> likely >> >> wrong. Since this is often data at rest, there is no possible >> >> negotiation either. >> >> >> >> I propose to remove section 4.1.2: >> >> There are also other parts of the document which refer to names as well. >> I have no use for names. >> >> > I agree it is better to remove the string name variant and only support > SIDs as names. > It will be important for the client to be able to obtain the SID File URL > list > representing all SIDs used by the server. This is needed before the clien= t > can > use any data from the server (including the CORECONF YANG library). > > The client will have to be hard-wired with the SIDs or capable of > consuming SID files in JSON format. > > > >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consu= lting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> > > Andy > > >> >> >> _______________________________________________ >> 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 > > --000000000000d17d1305ccaa484a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 22, 2021 at 9:35 PM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
Clearly, SIDs are the major innovation here and they are the normal way t= o use Yang-cbor.=C2=A0

I don=E2=80=99t agree the string = variant should be removed. This takes Yang-cbor out of the game for =E2=80= =9Cbig-web=E2=80=9D applications.=C2=A0

Instead, w= e should make sure to explain that strings are a special option that you ch= ose wholesale when you need it, not something you switch to from SIDs rando= mly.=C2=A0


The problem = with this approach (no negotiation, either peer sends SID or string at any = time)
is that it forces complexity on a constrained device that a= giant NETCONF router is not
even expected to support. It also fo= rces a constrained device to store the string names.


Andy

Sent from=C2=A0mobile, sorry for terse

On 23. Sep 2021, at 01:02, Andy Bier= man <andy@yumawo= rks.com> wrote:

=
=EF=BB=BF


<= div class=3D"gmail_quote">
On Wed, Sep= 22, 2021 at 2:54 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
=C2=A0 =C2=A0 > I'm happy to take credit for a keen observation such= as this, but this
=C2=A0 =C2=A0 > was actually Eric Vyncke.

sorry, if I screwed that attribution up when creating the issues.

=C2=A0 =C2=A0 >> I also wonder about this.=C2=A0 I think that the SID= concept is advanced
=C2=A0 =C2=A0 >> enough that we can just rely upon it.=C2=A0 Murray&#= 39;s comment is that if we
=C2=A0 =C2=A0 >> support two things, then an encoder needs to pick on= e, and it's likely
=C2=A0 =C2=A0 >> wrong.=C2=A0 Since this is often data at rest, there= is no possible
=C2=A0 =C2=A0 >> negotiation either.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I propose to remove section 4.1.2:

There are also other parts of the document which refer to names as well. I have no use for names.


I agree it is better to remove the str= ing name variant and only support SIDs as names.
It will be impor= tant for the client to be able to obtain the SID File URL list
re= presenting all SIDs used by the server. This is needed before the client ca= n
use any data from the server (including the CORECONF YANG libra= ry).

The client will have to be hard-wired with th= e SIDs or capable of consuming SID files in JSON format.



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




Andy
=C2=A0


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core = mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/= core
--000000000000d17d1305ccaa484a-- From nobody Thu Sep 23 07:39:08 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387C3A08A9 for ; Thu, 23 Sep 2021 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmOUJawgyK4P for ; Thu, 23 Sep 2021 07:39:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A823A08B0 for ; Thu, 23 Sep 2021 07:39:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8CA8F39E5E; Thu, 23 Sep 2021 10:46:17 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dUnBPQ22fL2k; Thu, 23 Sep 2021 10:46:12 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 61CBF39E1B; Thu, 23 Sep 2021 10:46:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2B9E040; Thu, 23 Sep 2021 10:38:52 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Andy Bierman , "Murray S. Kucherawy" , Core In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 14:39:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > Clearly, SIDs are the major innovation here and they are the normal w= ay > to use Yang-cbor. Agreed. > I don=E2=80=99t agree the string variant should be removed. This takes > Yang-cbor out of the game for =E2=80=9Cbig-web=E2=80=9D applications. okay. But, a lot of the document is about how to make up these names from the YANG content, and it seems that there are a lot of bugs in those sectio= ns. > Instead, we should make sure to explain that strings are a special > option that you chose wholesale when you need it, not something you > switch to from SIDs randomly. In ietf-anima-constrained-voucher, we are adding text to say that SIDs rule. (Actually, we consider this morning if we can get to the point where yang-s= id can be an informative reference only) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFMkXsACgkQgItw+93Q 3WXPTQf/eM4CiGh754eppSrFDzF1aNdKJ+6hCugzj3QK6JyRpjQKfafdJvx8zgT5 QT+vHc7MXxFaadmiiw3XJF5V/TFvk/lvdTdZsp4U6RtWctqfWf8Nkx2QS7mVx7w4 LZDT+0TLOBF9DO4suNYZWMkqPntY/kJZL1MO39z/3FXp6Yek087ZfBB+88hEbLVn Neowyakv068mtaUU29Ykaqv7r0PMEABG4hP/Ni0UPNZHzeMNJ5qPujqlA2rFCpe1 q8PzqsUql+YI7kOPMip/XWFK7Jys2/6K/VuinIECXCvX+zcWuVF17sGThFk2WJwV iWzc0E8EvIajapal9r5yP4x0T+RZ0A== =+CEk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 23 08:25:25 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C453A0E18 for ; Thu, 23 Sep 2021 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKsoUAd_snPG for ; Thu, 23 Sep 2021 08:25:17 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720563A0E0E for ; Thu, 23 Sep 2021 08:25:17 -0700 (PDT) Received: from smtpclient.apple (ip-109-40-0-186.web.vodafone.de [109.40.0.186]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HFf9k4Twtz31NC; Thu, 23 Sep 2021 17:25:14 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-1BD12F70-09D6-451E-84F1-9A0D29853EA2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: Date: Thu, 23 Sep 2021 17:25:13 +0200 Cc: Michael Richardson , "Murray S. Kucherawy" , Core Message-Id: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> References: To: Andy Bierman X-Mailer: iPhone Mail (18H17) Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 15:25:23 -0000 --Apple-Mail-1BD12F70-09D6-451E-84F1-9A0D29853EA2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Strings would not be used with constrained devices.=20 The point of the string-based names is to ensure that there never is a reaso= n to use text-based encodings (XML, JSON) with yang.=20 It is a completely separate choice.=20 (Supported by Accept: in http.) Sent from mobile, sorry for terse > On 23. Sep 2021, at 16:17, Andy Bierman wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann wrote: >> Clearly, SIDs are the major innovation here and they are the normal way t= o use Yang-cbor.=20 >>=20 >> I don=E2=80=99t agree the string variant should be removed. This takes Ya= ng-cbor out of the game for =E2=80=9Cbig-web=E2=80=9D applications.=20 >>=20 >> Instead, we should make sure to explain that strings are a special option= that you chose wholesale when you need it, not something you switch to from= SIDs randomly.=20 >>=20 >=20 > The problem with this approach (no negotiation, either peer sends SID or s= tring at any time) > is that it forces complexity on a constrained device that a giant NETCONF r= outer is not > even expected to support. It also forces a constrained device to store the= string names. >=20 >=20 > Andy >=20 >> Sent from mobile, sorry for terse >>=20 >>>> On 23. Sep 2021, at 01:02, Andy Bierman wrote: >>>>=20 >>> =EF=BB=BF >>>=20 >>>=20 >>>> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson wrote: >>>>=20 >>>> Murray S. Kucherawy wrote: >>>> > I'm happy to take credit for a keen observation such as this, but= this >>>> > was actually Eric Vyncke. >>>>=20 >>>> sorry, if I screwed that attribution up when creating the issues. >>>>=20 >>>> >> I also wonder about this. I think that the SID concept is advan= ced >>>> >> enough that we can just rely upon it. Murray's comment is that i= f we >>>> >> support two things, then an encoder needs to pick one, and it's l= ikely >>>> >> wrong. Since this is often data at rest, there is no possible >>>> >> negotiation either. >>>> >> >>>> >> I propose to remove section 4.1.2: >>>>=20 >>>> There are also other parts of the document which refer to names as well= . >>>> I have no use for names. >>>>=20 >>>=20 >>> I agree it is better to remove the string name variant and only support S= IDs as names. >>> It will be important for the client to be able to obtain the SID File UR= L list >>> representing all SIDs used by the server. This is needed before the clie= nt can >>> use any data from the server (including the CORECONF YANG library). >>>=20 >>> The client will have to be hard-wired with the SIDs or capable of consum= ing SID files in JSON format. >>>=20 >>>=20 >>>>=20 >>>> -- >>>> Michael Richardson . o O ( IPv6 I=C3=B8T cons= ulting ) >>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>>=20 >>>>=20 >>>=20 >>>=20 >>> Andy >>> =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 --Apple-Mail-1BD12F70-09D6-451E-84F1-9A0D29853EA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Strings would not be used with constrained d= evices. 

The point of the string-based names is to ensure t= hat there never is a reason to use text-based encodings (XML, JSON) with yan= g. 
It is a completely separate choice. 
(Supp= orted by Accept: in http.)

Sent from mobile, sorry for terse

On 23. Sep 2021, at 16:17, Andy Bierman &= lt;andy@yumaworks.com> wrote:

=EF=BB=BF


On Wed= , Sep 22, 2021 at 9:35 PM Carsten Bormann <cabo@tzi.org> wrote:
Clearly, SIDs are the major innovation here an= d they are the normal way to use Yang-cbor. 

I don=E2= =80=99t agree the string variant should be removed. This takes Yang-cbor out= of the game for =E2=80=9Cbig-web=E2=80=9D applications. 
Instead, we should make sure to explain that strings are a speci= al option that you chose wholesale when you need it, not something you switc= h to from SIDs randomly. 


The problem with this approach (no negotiation, either peer sends SID= or string at any time)
is that it forces complexity on a constrai= ned device that a giant NETCONF router is not
even expected to sup= port. It also forces a constrained device to store the string names.


Andy

Sent fr= om mobile, sorry for terse
<= div dir=3D"ltr">
On 23. Sep 2021, at 01:02, And= y Bierman <andy@y= umaworks.com> wrote:

=EF=BB=BF

On Wed, S= ep 22, 2021 at 2:54 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
    > I'm happy to take credit for a keen observation such as t= his, but this
    > was actually Eric Vyncke.

sorry, if I screwed that attribution up when creating the issues.

    >> I also wonder about this.  I think that the SID c= oncept is advanced
    >> enough that we can just rely upon it.  Murray's c= omment is that if we
    >> support two things, then an encoder needs to pick one= , and it's likely
    >> wrong.  Since this is often data at rest, there i= s no possible
    >> negotiation either.
    >>
    >> I propose to remove section 4.1.2:

There are also other parts of the document which refer to names as well.
= I have no use for names.


I agree it is better to remove the stri= ng name variant and only support SIDs as names.
It will be importa= nt for the client to be able to obtain the SID File URL list
repre= senting all SIDs used by the server. This is needed before the client can
use any data from the server (including the CORECONF YANG library).<= /div>

The client will have to be hard-wired with the SIDs= or capable of consuming SID files in JSON format.

=

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T cons= ulting )
           Sandelman Software Works Inc, Ottaw= a and Worldwide




Andy
 


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core m= ailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core=
= --Apple-Mail-1BD12F70-09D6-451E-84F1-9A0D29853EA2-- From nobody Thu Sep 23 08:43:41 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5C3A0EF3 for ; Thu, 23 Sep 2021 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v5Mu5O9g-12 for ; Thu, 23 Sep 2021 08:43:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AB33A0EEB for ; Thu, 23 Sep 2021 08:43:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F214318018; Thu, 23 Sep 2021 11:50:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fTu0hfyK_SGy; Thu, 23 Sep 2021 11:50:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B3D518017; Thu, 23 Sep 2021 11:50:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9F1E740; Thu, 23 Sep 2021 11:43:25 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Andy Bierman , Core In-Reply-To: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> References: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 15:43:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {I was wrong to CC Murray, let's remove him from the CC} Carsten Bormann wrote: > Strings would not be used with constrained devices. I think that we all agree with this. > The point of the string-based names is to ensure that there never is a > reason to use text-based encodings (XML, JSON) with yang. It is a > completely separate choice. (Supported by Accept: in http.) okay, so does it need to be in the same document? It seems more complex, and it (the document) would benefit from having acti= ve implementers using it. While I agree with your goals of not using text-bas= ed encodings, it does not to me feel like we filling an actual market need. That is, we have no running code. If we were taking this document to IS, then we'd wind up removing all the name-based stuff, since it has not gotten any interop testing. Maybe we should just split the document now? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFMoJ0ACgkQgItw+93Q 3WXUuAf7B32mBlu6EH+fusv3s22T03EgAC4YUTwsjlxH6EnlRItjajrmhmVALSAV iU8vqnw9qQzES6GvbPpRjVhvUqJ5Zdtx0U9Sw3QUD8IEDQ4dfJEBSTOGtDAGWPs9 4nxBapgM6r5gv+AhdjHtDloaDLEAeTgbH62Z3Ssx2EdMhtHdyUFoXGn6FO6ECslc tus0ZljEnmDYzobYBPajY5ja/L3kAnheMfuIRPcuHg5s3gpbs3yVDxgKl0N/LNQV VfxYW2nLg+CH+Vf6wceaoOYkDC1xJTOGXJp8BNGldKLhysP71TTCUO+WXybgxPBa KgsxBGvqdkUicDDe2wDs8f8zVH3XtQ== =HFU4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 23 08:50:35 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824583A0FBF for ; Thu, 23 Sep 2021 08:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.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 IsTzxzXwvqlZ for ; Thu, 23 Sep 2021 08:50:27 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 3D8023A0FBA for ; Thu, 23 Sep 2021 08:50:27 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id u1so136674lje.12 for ; Thu, 23 Sep 2021 08:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=loTMhviya6AcsfOOjMl4S8CqNkC5yDwbojS/nDOmTq0=; b=wsKw25mD2l9gJbnJxurdoLE/kUbiUSpHof9YnIaDT2EGjKU0SXnPaPm7FLVjFj6EMH Htu79B/a8yAzJGzreWOY8nlOnsqC4muuxzZfFKk7ZYbZzH0lZ6JFTEejDYWEPbcaf6/L eq+5GlHD0NVJa4vWyPJowLelqwrllHw+xWtYzffCWFpPkQ0pSeJIuAlIkENTp7zZiti8 RLNs2KjGocAq/Sy8wIih+ewzOoNh5Bdd98VQsTNZtTxoS2lGZtHp7YXo/yydgHTw9oAV bsxl5oUfgfLyvki6OFfoZYUNDtDk0krL6OPirtElvCjm44tt4wlmstkpYlV7WGSMlOGk 5i/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=loTMhviya6AcsfOOjMl4S8CqNkC5yDwbojS/nDOmTq0=; b=K0cnVcvgzUxS4AmxFs/mwoB0uY/T74HhQAfBZO8bbAA5UUBdiqqPevX6TS/cOSouJh ZZemGu8b0V6BaZegqTMAxJuDxRE7ZGsJamqrvBbAQXHVVLs0DR0XXGjFmi4ItSNChe/V YQbgzQMgwG6j9zVKZC13YkKJiLcWj8t6ICuwWI+8JmobfpeaLsF1UAKBUArFM3DU43yQ Tc6Gs9rD80b9hsMPd7bHrcFFeuz/uURzTrSvw4c+VVmml0jpr5xTaFcUdouldxDSHov8 FehalAfFxqikrqjLjan+qC9UA9hEC1m0nd8g3zvIZBLbO3YZ2JqA8Cdhd9K2KndC2UwO CNLg== X-Gm-Message-State: AOAM5301Av5/HsPnqjDaD6mYqJRFpsyyv1RJpxQBhJnk9GgN/CWlwPRT RC6l+NdozOsBs22vjb8+wzSoKwxNd3iwFnDeNErU9Q== X-Google-Smtp-Source: ABdhPJzYACg7La12+A806cFYO8u6WEAaaY5dd1Zq1Rqw1SjwAsXLeJcxZ1pTxCVSnW7Pk7+vX0dhUIscuHBBWY7Lw2k= X-Received: by 2002:a05:651c:a12:: with SMTP id k18mr5974650ljq.207.1632412223237; Thu, 23 Sep 2021 08:50:23 -0700 (PDT) MIME-Version: 1.0 References: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> In-Reply-To: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> From: Andy Bierman Date: Thu, 23 Sep 2021 08:50:12 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "Murray S. Kucherawy" , Core Content-Type: multipart/alternative; boundary="000000000000b1839805ccab96ae" Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 15:50:34 -0000 --000000000000b1839805ccab96ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2021 at 8:25 AM Carsten Bormann wrote: > Strings would not be used with constrained devices. > > The point of the string-based names is to ensure that there never is a > reason to use text-based encodings (XML, JSON) with yang. > It is a completely separate choice. > (Supported by Accept: in http.) > > OK, but YANG has qualified names (e.g. RFC 7951 must be used, not plain JSON). I don't see much value for YANG data by using CBOR w/ names vs. JSON. The name to SID compression will be about 15:1 to 30:1 with delta-SID, whil= e the number compression (CBOR over JSON) will barely reach 3:1 compression. If it is optional-to-implement, optional-to-use then that is fine. At least the Accept header forces the entire response to use the same encoding so there can never be SIDs and names in the same message. (I hope). Sent from mobile, sorry for terse > > On 23. Sep 2021, at 16:17, Andy Bierman wrote: > > =EF=BB=BF > > > On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann wrote: > >> Clearly, SIDs are the major innovation here and they are the normal way >> to use Yang-cbor. >> >> I don=E2=80=99t agree the string variant should be removed. This takes Y= ang-cbor >> out of the game for =E2=80=9Cbig-web=E2=80=9D applications. >> >> Instead, we should make sure to explain that strings are a special optio= n >> that you chose wholesale when you need it, not something you switch to f= rom >> SIDs randomly. >> >> > The problem with this approach (no negotiation, either peer sends SID or > string at any time) > is that it forces complexity on a constrained device that a giant NETCONF > router is not > even expected to support. It also forces a constrained device to store th= e > string names. > > > Andy > > Sent from mobile, sorry for terse >> >> On 23. Sep 2021, at 01:02, Andy Bierman wrote: >> >> =EF=BB=BF >> >> >> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson >> wrote: >> >>> >>> Murray S. Kucherawy wrote: >>> > I'm happy to take credit for a keen observation such as this, but >>> this >>> > was actually Eric Vyncke. >>> >>> sorry, if I screwed that attribution up when creating the issues. >>> >>> >> I also wonder about this. I think that the SID concept is >>> advanced >>> >> enough that we can just rely upon it. Murray's comment is that >>> if we >>> >> support two things, then an encoder needs to pick one, and it's >>> likely >>> >> wrong. Since this is often data at rest, there is no possible >>> >> negotiation either. >>> >> >>> >> I propose to remove section 4.1.2: >>> >>> There are also other parts of the document which refer to names as well= . >>> I have no use for names. >>> >>> >> I agree it is better to remove the string name variant and only support >> SIDs as names. >> It will be important for the client to be able to obtain the SID File UR= L >> list >> representing all SIDs used by the server. This is needed before the >> client can >> use any data from the server (including the CORECONF YANG library). >> >> The client will have to be hard-wired with the SIDs or capable of >> consuming SID files in JSON format. >> >> >> >>> -- >>> Michael Richardson . o O ( IPv6 I=C3=B8T >>> consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >> >> Andy >> >> >>> >>> >>> _______________________________________________ >>> 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 >> >> --000000000000b1839805ccab96ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 23, 2021 at 8:25 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
Strings would not be used with constrained devices.=C2=A0

Th= e point of the string-based names is to ensure that there never is a reason= to use text-based encodings (XML, JSON) with yang.=C2=A0
It is a= completely separate choice.=C2=A0
(Supported by Accept: in http.= )



OK, but YANG has qualified names (e.g. RFC 7951 must be used, not pl= ain JSON).
I don't see much value for YANG data by using CBOR= w/ names vs. JSON.

The name to SID compression wi= ll be about 15:1 to 30:1 with delta-SID, while
the number compres= sion (CBOR over JSON) will barely reach 3:1 compression.

If it is optional-to-implement, optional-to-use then that is fine.
At least the Accept header forces the entire response to use
=
the same encoding so there can never be SIDs and names in the same mes= sage.
(I hope).


Sent from=C2=A0mobile, sorry for terse=

On 23. Sep 2021= , at 16:17, Andy Bierman <andy@yumaworks.com> wrote:

=EF=BB=BF


On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann <cabo@tzi.org> wrote:
Clear= ly, SIDs are the major innovation here and they are the normal way to use Y= ang-cbor.=C2=A0

I don=E2=80=99t agree the string variant= should be removed. This takes Yang-cbor out of the game for =E2=80=9Cbig-w= eb=E2=80=9D applications.=C2=A0

Instead, we should= make sure to explain that strings are a special option that you chose whol= esale when you need it, not something you switch to from SIDs randomly.=C2= =A0


The problem with th= is approach (no negotiation, either peer sends SID or string at any time)
is that it forces complexity on a constrained device that a giant = NETCONF router is not
even expected to support. It also forces a = constrained device to store the string names.


=
Andy

Sent from=C2=A0mobile, sorry for terse
=
On 23. Sep 2021, at 01:02, Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaworks.com> wrote:

=EF=BB=BF


On Wed, Sep 22, 202= 1 at 2:54 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
=C2=A0 =C2=A0 > I'm happy to take credit for a keen observation such= as this, but this
=C2=A0 =C2=A0 > was actually Eric Vyncke.

sorry, if I screwed that attribution up when creating the issues.

=C2=A0 =C2=A0 >> I also wonder about this.=C2=A0 I think that the SID= concept is advanced
=C2=A0 =C2=A0 >> enough that we can just rely upon it.=C2=A0 Murray&#= 39;s comment is that if we
=C2=A0 =C2=A0 >> support two things, then an encoder needs to pick on= e, and it's likely
=C2=A0 =C2=A0 >> wrong.=C2=A0 Since this is often data at rest, there= is no possible
=C2=A0 =C2=A0 >> negotiation either.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I propose to remove section 4.1.2:

There are also other parts of the document which refer to names as well. I have no use for names.


I agree it is better to remove the str= ing name variant and only support SIDs as names.
It will be impor= tant for the client to be able to obtain the SID File URL list
re= presenting all SIDs used by the server. This is needed before the client ca= n
use any data from the server (including the CORECONF YANG libra= ry).

The client will have to be hard-wired with th= e SIDs or capable of consuming SID files in JSON format.



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




Andy
=C2=A0


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core = mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/= core
--000000000000b1839805ccab96ae-- From nobody Thu Sep 23 11:07:32 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9163A1622 for ; Thu, 23 Sep 2021 11:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.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 i19jglfxoHfV for ; Thu, 23 Sep 2021 11:07:23 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 2C3653A161C for ; Thu, 23 Sep 2021 11:07:22 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id i4so29416565lfv.4 for ; Thu, 23 Sep 2021 11:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0x7pNwzNOc+PMkKM056FVx3c3UXUTWQsxFVfSAUpkOc=; b=ngufvjuBhenqhGks1hil1iY8uS45ABqTdUDqOtT+q9RT7m3OikJnjoJJstHqrD40iM rJNOdyYedHQ/zvkfkjVJu61jtJHRZwOa9zrtnfO70kV4I1NBpLwf3jn4q+gHaNO5VWXX xESNeCka4RxSJ5tRdvpZsVreprPNXb/3BG2LzQzJRD+YzQYlYyo2ZmxUk3wXxgSaC8WP Ttwn2QXmktCIZHViOFaOOX1nJh5VlFipAzWODV7DNSxnxroufYRNWkYHZkkMvr/TxTB4 NNXMVOoA4NdWlgVvqZqgEFOX0VowHghtCD1Y+b6NGpdEAjOUJL9fhZMo31mzV1tooxwR /6cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0x7pNwzNOc+PMkKM056FVx3c3UXUTWQsxFVfSAUpkOc=; b=0gLtXZq0JI0y9GCtGpLWTPB635lw2h/aEDMeYxA7LSl9wQ3TJQV8gBOkjtf1eDZKUC SJPICmDvvWiRt0LNIhiwcpoRfcSnU/DWH9wVMDGj0f0AOm6vmcVzKw3amu9HzMu2aDGv vnpEPYHNaXbNtUyuEzeUp5ErfF44uvhrusEPy4fz3rvJhooYlCiG1YWaLaKxlYUaNBNH Xvaj14UNww6E1yIGBbcMdcdSE5aeJbPH/jZRsLU2XSTj/Bi2vunAYrqN9N/Is99xy496 L2b7LoE2Ef0Q1I//1qEf5Qge0bcrtQrJGfGSL8elCOUtIHo564WaNzT68lNZIZ6MyvxQ 3SXg== X-Gm-Message-State: AOAM533ZzxfMh5ZLXykbukZVhAe+kWNTGVEmV9tY/VmOycveKTfwORTG KPq4YOM7poDLRzjykPtvvCtP0yk/d5QpBd0Q3iic8g== X-Google-Smtp-Source: ABdhPJz3s95a0h8Cf7byW3jrQkat/J2BfB1fvTtCEIE5R46bK8DLejdMlg+W3NBFSYKszRwJp96A/85GxxUhDkoH18A= X-Received: by 2002:a2e:131a:: with SMTP id 26mr6603793ljt.1.1632420440698; Thu, 23 Sep 2021 11:07:20 -0700 (PDT) MIME-Version: 1.0 References: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> In-Reply-To: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org> From: Andy Bierman Date: Thu, 23 Sep 2021 11:07:09 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "Murray S. Kucherawy" , Core Content-Type: multipart/alternative; boundary="0000000000007e0edf05ccad8099" Archived-At: Subject: Re: [core] removing names from yang-cbor rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 18:07:30 -0000 --0000000000007e0edf05ccad8099 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2021 at 8:25 AM Carsten Bormann wrote: > Strings would not be used with constrained devices. > > The point of the string-based names is to ensure that there never is a > reason to use text-based encodings (XML, JSON) with yang. > It is a completely separate choice. > (Supported by Accept: in http.) > This text in sec 3 implies that text and SID names can be mixed in ad-hoc fashion. This specification supports two types of CBOR keys; YANG Schema Item iDentifier (YANG SID) as defined in Section 3.2 and names as defined in Section 3.3 . Each of these key types is encoded using a specific CBOR type which allows their interpretation during the deserialization process. Protocols or mechanisms implementing this specification can mandate the use of a specific key type. IMO this section should clearly identify the requirements in terms of the Content-Types defined. https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-9.1 How about text that says YANG SID keys MUST only be used with application/yang-data+cbor; id=3Dsid and name keys MUST only be used with application/yang-data+cbor; id=3Dname. Andy > Sent from mobile, sorry for terse > > On 23. Sep 2021, at 16:17, Andy Bierman wrote: > > =EF=BB=BF > > > On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann wrote: > >> Clearly, SIDs are the major innovation here and they are the normal way >> to use Yang-cbor. >> >> I don=E2=80=99t agree the string variant should be removed. This takes Y= ang-cbor >> out of the game for =E2=80=9Cbig-web=E2=80=9D applications. >> >> Instead, we should make sure to explain that strings are a special optio= n >> that you chose wholesale when you need it, not something you switch to f= rom >> SIDs randomly. >> >> > The problem with this approach (no negotiation, either peer sends SID or > string at any time) > is that it forces complexity on a constrained device that a giant NETCONF > router is not > even expected to support. It also forces a constrained device to store th= e > string names. > > > Andy > > Sent from mobile, sorry for terse >> >> On 23. Sep 2021, at 01:02, Andy Bierman wrote: >> >> =EF=BB=BF >> >> >> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson >> wrote: >> >>> >>> Murray S. Kucherawy wrote: >>> > I'm happy to take credit for a keen observation such as this, but >>> this >>> > was actually Eric Vyncke. >>> >>> sorry, if I screwed that attribution up when creating the issues. >>> >>> >> I also wonder about this. I think that the SID concept is >>> advanced >>> >> enough that we can just rely upon it. Murray's comment is that >>> if we >>> >> support two things, then an encoder needs to pick one, and it's >>> likely >>> >> wrong. Since this is often data at rest, there is no possible >>> >> negotiation either. >>> >> >>> >> I propose to remove section 4.1.2: >>> >>> There are also other parts of the document which refer to names as well= . >>> I have no use for names. >>> >>> >> I agree it is better to remove the string name variant and only support >> SIDs as names. >> It will be important for the client to be able to obtain the SID File UR= L >> list >> representing all SIDs used by the server. This is needed before the >> client can >> use any data from the server (including the CORECONF YANG library). >> >> The client will have to be hard-wired with the SIDs or capable of >> consuming SID files in JSON format. >> >> >> >>> -- >>> Michael Richardson . o O ( IPv6 I=C3=B8T >>> consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >> >> Andy >> >> >>> >>> >>> _______________________________________________ >>> 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 >> >> --0000000000007e0edf05ccad8099 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 23, 2021 at 8:25 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
Strings would not be used with constrained devices.=C2=A0

Th= e point of the string-based names is to ensure that there never is a reason= to use text-based encodings (XML, JSON) with yang.=C2=A0
It is a= completely separate choice.=C2=A0
(Supported by Accept: in http.= )

This text in sec 3 impl= ies that text and SID names can be mixed in ad-hoc fashion.

<= /div>
   This speci=
fication supports two types of CBOR keys;
   YANG Schema Item iDentifier (YANG SID) as defined in Sectio=
n 3.2 and
   names as defined in Section 3.3.  Each of these key typ=
es is encoded
   using a specific CBOR type which allows their interpretation during
   the deserialization process.  Protocols or mechanisms implementing
   this specification can mandate the use of a specific key type.
=C2=A0
IMO this section should clearly identify the requir= ements in terms of the Content-Types defined.

How about text that says YANG SID keys MUST onl= y be used with application/yang-data+cbor; id=3Dsid
and name keys= MUST only be used with application/yang-data+cbor; id=3Dname.
Andy



Sent from=C2=A0mobile, sorry for terse

On 23. Sep 2021, at= 16:17, Andy Bierman <andy@yumaworks.com> wrote:

=EF=BB=BF


On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann <cabo@tzi.org> wrote:
Clearly, SID= s are the major innovation here and they are the normal way to use Yang-cbo= r.=C2=A0

I don=E2=80=99t agree the string variant should= be removed. This takes Yang-cbor out of the game for =E2=80=9Cbig-web=E2= =80=9D applications.=C2=A0

Instead, we should make= sure to explain that strings are a special option that you chose wholesale= when you need it, not something you switch to from SIDs randomly.=C2=A0

The problem with this app= roach (no negotiation, either peer sends SID or string at any time)
is that it forces complexity on a constrained device that a giant NETCON= F router is not
even expected to support. It also forces a constr= ained device to store the string names.


=
Andy

Sent from=C2=A0mobile, sorry for terse

On 23. Sep 2021, at 01:02, Andy Bierman <andy@yumaworks.com>= wrote:

=EF=BB=BF


On Wed, Sep 22, 2021 at 2:= 54 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
=C2=A0 =C2=A0 > I'm happy to take credit for a keen observation such= as this, but this
=C2=A0 =C2=A0 > was actually Eric Vyncke.

sorry, if I screwed that attribution up when creating the issues.

=C2=A0 =C2=A0 >> I also wonder about this.=C2=A0 I think that the SID= concept is advanced
=C2=A0 =C2=A0 >> enough that we can just rely upon it.=C2=A0 Murray&#= 39;s comment is that if we
=C2=A0 =C2=A0 >> support two things, then an encoder needs to pick on= e, and it's likely
=C2=A0 =C2=A0 >> wrong.=C2=A0 Since this is often data at rest, there= is no possible
=C2=A0 =C2=A0 >> negotiation either.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I propose to remove section 4.1.2:

There are also other parts of the document which refer to names as well. I have no use for names.


I agree it is better to remove the str= ing name variant and only support SIDs as names.
It will be impor= tant for the client to be able to obtain the SID File URL list
re= presenting all SIDs used by the server. This is needed before the client ca= n
use any data from the server (including the CORECONF YANG libra= ry).

The client will have to be hard-wired with th= e SIDs or capable of consuming SID files in JSON format.



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




Andy
=C2=A0


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core = mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/= core
--0000000000007e0edf05ccad8099-- From nobody Thu Sep 23 12:57:00 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F7F3A1A10 for ; Thu, 23 Sep 2021 12:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zthLjPF1R-Sy for ; Thu, 23 Sep 2021 12:56:53 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2048.outbound.protection.outlook.com [40.107.22.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240003A1A0D for ; Thu, 23 Sep 2021 12:56:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=od7k1IaQx6ShRV3i0UJkjEH1wMLlsqGn19F6/pAPNIaYKd79rHxHdidDovCKScdI0+7cjhQTcSsj9vOIY0Zrs2dc6Scf2a+zP1511+zUlQ8QHXHpMkwVbx/jKP6Xs7nM8F8zWEbrOiKNURoKAMsp7o+6yR1ha13kc6V+mtKOIcaiYstRt/IuQd0eeVvJK4txZABVU5vhY2BQR5lvYN7y5k2Xw0sO+6oLlpM6aGRa3V6OwqvuJXNBkw/jB6XQqMedK4agIeBUXSWSYVydwHlgJcQ6R67LYlBFwWwUYOiXDI6u8+IAxp+aRwYJlX1lRRdj9zkVV+CawBWvzBPq8f0iMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9hX7CfuQvdtBSuKM2UVnQ7JSCfq3NSSfpcwFZimkk1E=; b=YfDYRA9oqEwTMpB1ZzKM+RjkyCdKvSYiauut7aKtp0+iqW3vKlLTQVDY4PhPrum3ee74si+LVq7B1jNg20QRloJhrJ+Hkn5hSzSJHZt4kstk7fDdwDMwyYlBu5dUDe1y5kSJBpt62OnSU1beaSoCIfBA5/1Mj6p8MOJ6MgfIyYkACpdCW3IZRJFuDj4F+fRBTCRjOnsfArp1qqQXwnH4gZALjbKMXLySO76jOZYsNxKP+h1HiH2kxF21hUrap9mrjaRmM40297Ggar2MtQ0D1iRatbRwkNE4Myqw7koiWQEp3GUk0y0ME7gTgp7wVso2t3Jk6aF+VuSEeCJbysuKMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9hX7CfuQvdtBSuKM2UVnQ7JSCfq3NSSfpcwFZimkk1E=; b=TzcaeJE1X0TABak/Jq7VxHmYfQVS0gDozC/GBSQP/DrMqoRzMlW0lxZbMPZUC+hx7so2GQdlxv5uuqfeV+obpxDL0/j6kq900T82tjoepDNWfahg8QaaJKKpBKO4hL25fDJ3ITNhIP3gUVGjnJqaqmUMWKB4B9/elffR3Yx2DSg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1179.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e4::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.15; Thu, 23 Sep 2021 19:56:48 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172%6]) with mapi id 15.20.4544.015; Thu, 23 Sep 2021 19:56:47 +0000 References: To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: Message-ID: Date: Thu, 23 Sep 2021 21:56:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Pa70rPIo5qcFGgxHDFsh50oLGqSmgqOYl" X-ClientProxiedBy: AM3PR07CA0148.eurprd07.prod.outlook.com (2603:10a6:207:8::34) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [192.168.0.65] (92.34.13.218) by AM3PR07CA0148.eurprd07.prod.outlook.com (2603:10a6:207:8::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.8 via Frontend Transport; Thu, 23 Sep 2021 19:56:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5fcad049-b54e-4027-d612-08d97ecc46d3 X-MS-TrafficTypeDiagnostic: DBBP189MB1179: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZZ86LjCKhUjHXjfuQFOl3FKLhG9TwGxkT5nf1wdkGL0oXxN28U+qVbp+NSKCR73ipDhDcFurDVrjpVfwR4z79q29wkZ6MYmUlqS2xSRwOjHwvniEvWkYVBas5aztqI+dsrRNc8XUGi4j0lycfpC+opuo6F9qBsBWK+A+zrx21jd/Fk1wtLAuniT9jKaJxmW3ZXMm0Cm/1DVTQlgM6Qt0pKE6HIJlh1Hw2kRImD9SoyCQuJzgddEGwIbUojqhS4tfuvYHvjdPh2U5BjoLrsngeURxLRTpIVNizPTLq6rf7LKa9LEtBjZwPbMJCBedYIKxu3ayWQTH50e6dubh0GrMDQ0Yf/ZpkjB8rbrP8Nrwfp1e+sWb5UF4pARiJ5BmPlae7rdGiYiK/sW7FVOFHjdZvfWm3lhp9dTINNm7MCxJLt8M0iKB8Sqt89Nj0kU0hSWTITi3WtwEPcrPccMyAjTxZEANPa3WoaQ/2QLcoQtbJV5rItYIv1/uupTuQXmjd5q/flT8USb4/KXwBr9QTC+xgJThxBsfnXHwhySZq2wGHCv0NCtKlZ4QMdKeZMhQ7819/Zr4bz9MvcRe8vX5/xPaxXSGzvjv+6OChozgLqpJX893UsXflfb2nx7sDV7wrVuL23Iu7FkofAOjZs1j28iRn4lXol3ZMsDUsqkdqd4DyQwKVA53Xn5eChmqyKT4BX1sn2NlVdDqzCe3dCRbmJXVaUoguc8Gqe4xeLWQNwd0oWtGTu3bSOovNMoOCJ/IrGGiYoJX/jv0MvIk99Dkc3evc4qYX+Pb2CSjXHa7C1ZxE9U2hHrVRVI1D5GLCNMmXQVM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(166002)(966005)(45080400002)(508600001)(2616005)(83380400001)(956004)(26005)(8676002)(2906002)(186003)(6916009)(44832011)(38100700002)(31686004)(36756003)(21480400003)(86362001)(16576012)(31696002)(316002)(66616009)(33964004)(5660300002)(8936002)(6486002)(235185007)(66556008)(66574015)(66946007)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3V4YmNvd1ZSSGJJM0JpMXhIazVVcUkxZkh0NWViOWRJK3M5UXBPNFF2VDMv?= =?utf-8?B?M2NpUWJoR1c1WGJZc3VVTHd1eC82dXR3WVQ3bHdJTno0a0tEY25kR0NzYlh2?= =?utf-8?B?UmNySnhBTmlSL2w3N1ByYVZZd1NHZ1lFeGdyU3Fyazkxek1oa09aZWh0c0F0?= =?utf-8?B?NjVuZiswV0J4MitMMzh6Y2xNcnppTkZScjZsQkh4UUJtUFo3anQ5TTRRY0JB?= =?utf-8?B?ZHpxdGY4RXJPMlBQanRPZFg5OC9LMWMyNGNiWGpHb2dENy9GUTBSS2tTOE5n?= =?utf-8?B?aE50aUQveFZQMk1jYjJnM0lxQm9wTkRFNENYT0NVK3ltM21YRTVoeVlTMUM5?= =?utf-8?B?WEE3a25IZ1MyRytjV0dvdHlWNDVOek52S2RodkdMZ2dtVEg1Q1N4QlVzSUd4?= =?utf-8?B?QklEK2FDMFhWN3FGZjNidzA0L01ubDJLdHpEWTcybmhWRjAwcUdvR3NXZDV1?= =?utf-8?B?NEZKRGd6aUNjbjNVOVVHeUNwWEF3SnpDUFZQQ2t4TlFqWFphNEZWZFU0dnd5?= =?utf-8?B?QjEyY3ZCQ2kvVi90VnQvOFlBWVBNZDhvTU1UN081bXd3NGlzYXlDUG1PYlUr?= =?utf-8?B?OFExMEZtVUZTcUMxSEJHVDFDbERSYitmYloyNEZWV1M5c082NHVVZnBseDJ6?= =?utf-8?B?blJqT0x2Y2hUelZ3SnhWMENSclhpSmJQWWs5SmwxN1NzNUJmODdXLzROcStP?= =?utf-8?B?b0ZQcU1HTW16Z3hUNER4RVRBay9iNWJTRU1HMW5kNk1mN2l0c3cxMTFxZ0U1?= =?utf-8?B?WTYrUm1iOW0rejRuV3BKUFIrNUtWb0tjckdIYlc4aEJxSHAyQ0htb3ZUc2xH?= =?utf-8?B?VFdPRjEyVTlOK3VXZUc1MGpSN2dBaFl1VUltN0pqRk1WZEI2ZTdDeDBNMVFX?= =?utf-8?B?eDBEdUVHYy9LdmVtcll3V2NRNEEyNkYvU2lITUJxdy9weHo0Y05rVlVNR2dM?= =?utf-8?B?c2RaeUE0TzZVVlU5WXJlL0lFeEllQ096WUpoU3Ira0FVNkp3QjBLWXFoMDBU?= =?utf-8?B?bVM2akpWZXZsa3ZMaVc4WkpQalRHUnpSZjA2bnRVZGlOWXVZNUJoSDNUMXQ0?= =?utf-8?B?ekhtUUxnWjhacnZDU3BkZmxZdnZ2UkNlaHd0bEt2RHJkNksrSHA1MHBiSDha?= =?utf-8?B?SEs5VWZKV1J1U21EMDFCS3llZTR2U1F5aHA4M0x2RzlyZlN4TUFWSFBuMTRy?= =?utf-8?B?RkdiWVpuUUVRa0trZkVyTnl6SHVyS0RxbElUbHhNaG44UHJqbnRJbUVtZXJI?= =?utf-8?B?NldyaFplZHdBUjZ0VlRpM0s1V2pjeE1CeVkxb1Z3Z05HeWdaTjJqaFZpaGZ6?= =?utf-8?B?bTlvSG02RTljMGFyYkYrOW81dExkN0ZINVRVdGhmQThXVllTWHErUk9saUlT?= =?utf-8?B?QllDZ0FQblpSS3QwTzJaeTJrTXE2WHlvWFVZRXRNa0FLTGFsdFJqZExEeXRh?= =?utf-8?B?K2xNQUxoZHE5R2tTMzZxNUkySHhQWDE1Vy90emlOcWYwZlIrUUVKMGRnQk1B?= =?utf-8?B?RUNNVEZNcE5rc0ZBWWlVVC9USkVVRXpyNEZva1BaQUg3NzhmV2RZQ0VyRm1S?= =?utf-8?B?SGI5SUI5cnBiczFWc09SVllxUHF0RHphb2pGaDBsM2RBcSs0bUZLbXduSm9W?= =?utf-8?B?dUpOUzVPL2VNQXhLRGJEdkV2dEpsWjducEUyNWxUSndSV1lRNHk5OEthNDM3?= =?utf-8?B?WVZMcHJaRjNncks0dm1jTkY0ZHBUd1V5WklpTDBJT2xmN1lwOTlQNHhRS1Fz?= =?utf-8?Q?6xqX58MJ5sVYpI2YzjtHsnF/Xv5GvLuv1SzXxFL?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 5fcad049-b54e-4027-d612-08d97ecc46d3 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2021 19:56:47.8124 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HERSpZzHPlLe2INYF7rRJ58K0+vUmLwtG3eNthBWKT7kykutv9T/Icl1TtG4dUWh9yfSHDfAXYuZF/l4TVHsiw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1179 Archived-At: Subject: [core] Fwd: [Iot-directorate] IIC Overview at the IETF - Request to fill the doodle by Friday 25th Sept X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 19:56:59 -0000 --Pa70rPIo5qcFGgxHDFsh50oLGqSmgqOYl Content-Type: multipart/mixed; boundary="YM7RMobKHEpyrZw9vWDmwi8aIItgRwHn7"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Fwd: [Iot-directorate] IIC Overview at the IETF - Request to fill the doodle by Friday 25th Sept References: In-Reply-To: --YM7RMobKHEpyrZw9vWDmwi8aIItgRwHn7 Content-Type: multipart/mixed; boundary="------------F0F56A44139A630BC3131BB6" Content-Language: en-US This is a multi-part message in MIME format. --------------F0F56A44139A630BC3131BB6 Content-Type: multipart/alternative; boundary="------------C89311B8D82B1D8EB957A806" --------------C89311B8D82B1D8EB957A806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable FYI Best, /Marco -------- Forwarded Message -------- Subject: [Iot-directorate] IIC Overview at the IETF - Request to fill=20 the doodle by Friday 25th Sept Date: Thu, 23 Sep 2021 16:36:59 +0300 From: Ines Robles To: IETF IoT Directorate CC: Ari Ker=C3=A4nen , Samita Chakrabarti=20 , Samita Chakrabarti=20 Dear all, In order to understand the work of IIC and discuss possible cooperation=20 efforts, Wael William Diab [1] from IIC, will provide us with an=20 overview of IIC. In order to participate=C2=A0in this meeting, please fill the following=20 doodle by Friday 25th September at 3pm UTC. https://doodle.com/poll/weqq2wnhuh29ie5c?utm_source=3Dpoll&utm_medium=3Dl= ink=20 Notice that the meeting will be recorded and posted on youtube. Thank you very much in advance, Ines, Samita and Ari [1] https://www.iiconsortium.org/awards-program/wael-diab.htm=20 --------------C89311B8D82B1D8EB957A806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: [Iot-directorate] IIC Overview at the IETF - Request to fill the doodle by Friday 25th Sept
Dat= e: Thu, 23 Sep 2021 16:36:59 +0300
Fro= m: Ines Robles <mariainesrobles=3D40googlem= ail.com@dmarc.ietf.org>
To:= IETF IoT Directorate <iot-directorate@ietf.org><= /a>
CC:= Ari Ker=C3=A4nen <ari.keranen@ericsson.com>, S= amita Chakrabarti <samitac.ietf@gmail.com>, Samita Chakrabarti <samita.chakrabarti@verizon.com>=


Dear all,

In order to understand the work of IIC and discuss possible cooperation efforts, Wael William Diab [1] from IIC, will provide us with an overview of IIC.

In order to participate=C2=A0in this meeting, please fill th= e following doodle by Friday 25th September at 3pm UTC.=C2=A0


Notice that the meeting will be recorded and posted on youtube.=C2=A0

Thank you very much in advance,

Ines, Samita and Ari

--------------C89311B8D82B1D8EB957A806-- --------------F0F56A44139A630BC3131BB6 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0gCklvdC1kaXJlY3RvcmF0ZSBtYWlsaW5nIGxpc3QKSW90LWRpcmVjdG9yYXRlQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW90LWRpcmVjdG9y YXRlCgo= --------------F0F56A44139A630BC3131BB6-- --YM7RMobKHEpyrZw9vWDmwi8aIItgRwHn7-- --Pa70rPIo5qcFGgxHDFsh50oLGqSmgqOYl Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmFM2/4FAwAAAAAACgkQ7iZktA5Y2kM2 fgf/SrEJFW0iCb0EIviMFS0atWr0+GgzcSSGi/rBDLlBhRQp7z9rE3NciXCdj2birreIDa+j97pk 5FTO1WgVyFhirb4W21M+0iiQuCTYTojqm/B/hxXlO4S/vKwzwsIHpiO8QtHV3HeL409zKhXuxDum SQId68BHt1MZp5m2c7q8Q7ZezzdeXpsG2pf6URAtvPJNzaCoZUFodWK+R4EMBEBvMcyny9hlkRC4 dbwGxfLkyP4XNq56MCANHQbwvYSwzW+oZniRjg+viH+iDJuQpCrZrptSkzyII06+0ryt7SfU5HCP oiu9FsGWhttpjNXpIrZtVPanU6SA55v6yWsI3MweQw== =RTXR -----END PGP SIGNATURE----- --Pa70rPIo5qcFGgxHDFsh50oLGqSmgqOYl-- From nobody Mon Sep 27 09:58:20 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2333A0C24 for ; Mon, 27 Sep 2021 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAGPBEjgHY79 for ; Mon, 27 Sep 2021 09:58:12 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10063.outbound.protection.outlook.com [40.107.1.63]) (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 C33E63A0C19 for ; Mon, 27 Sep 2021 09:58:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FtkUrVq+G4+zog9vCQZRLje9GndHd4VLERxGcrUAlsgcmDCmArjOlQ020bZXu0Y7o/H17kd/KKDNePnoPjRUIeZs46tRmYMGi6F/vDbL+7VpjcNQetURUu7tnMq6CKS9nXQTbTZAmME3EyoWqeefwQpZQB1Oi3/Mf1bIWyVW6iS9wkllCX7rUV55GRRPZH+aaLuNx4m7/mumtBXp6m9KMYWRJQ4E4Mm85246Tvcri7/91mGkMJ2ww9oeyxT950BZmtQ4RqS2cVzODSf1lpIXioAKXe5rZ9nWZKgn8tZrxZq9yjsnpUxw0t/+pnm2wC2xb3hN5Qf32QPnHnSp+pmRGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EQ0ogV+/aYpdB/6GlE2WDSXNHgxJfZ3bVBcCVrEPZxk=; b=WwYFilUSLcFlRusfbajxYhia5TGUxCK0I6CDucx2EpZG74w0kbc1XA6kYUuYJKHdVashgqEUFVQp7+Emjw3+XrqrAAaDX/HS48vXCuwUCJaLJnPa7CHMLLXjogmypOmhcwFX34FXOWFl4ZF50U4o8Rh2HKybTYtNuWbBE9husRXSHOKpvhHg36Ox1GJUquVLuKrIB4iUgh8VTBq+EeU3mNLDqL6HGTal0Mucwi0Nm/xWRBK24C6R+cAPShdoDF/Dysb0GuX/fD67RncZPwoBRxbYQu1WXDFsjpmWM4DyKupo5+Dv1VnPNS9cJNltS7nNPIV8lzChZrTVamP6QtgRXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EQ0ogV+/aYpdB/6GlE2WDSXNHgxJfZ3bVBcCVrEPZxk=; b=cHbBCf9y3HGY1+WFrPw+wSeHSyc0GAlj8gcZeNGslEcctMvd/D8W8wALjD+nPCE+a3W8APMDxguIGqYrt2slRefALsdNm93oZv+PmuZJD6x+D2dglOYBesxF5EiR73WxPnoI3XDfccYMbM8S/E3glLX3oC1y2cC8UxFSynABVpg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0103.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:25::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.18; Mon, 27 Sep 2021 16:58:03 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::d94b:2e87:a8ef:b172%6]) with mapi id 15.20.4544.021; Mon, 27 Sep 2021 16:58:02 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <27682b78-b880-c2a7-fff1-bee49f834ad9@ri.se> Date: Mon, 27 Sep 2021 18:58:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ik643lbF13uJPHr5yZwdmKKd1uyrbH9Fq" X-ClientProxiedBy: HE1PR05CA0327.eurprd05.prod.outlook.com (2603:10a6:7:92::22) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.2.3] (146.70.21.68) by HE1PR05CA0327.eurprd05.prod.outlook.com (2603:10a6:7:92::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.14 via Frontend Transport; Mon, 27 Sep 2021 16:58:02 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d5153fe-6910-4c50-4d8d-08d981d7f7ef X-MS-TrafficTypeDiagnostic: DB6P18901MB0103: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UBGur61Y0axCgAcRB50+MVky9n9HFtUAZaL09ZJY8rqwhS5MWiwgcJpFQ25mBMgQYHql8wv+lt5Ao8dDzBmyLMOZ5ZAJDbwMNucgpsnvsMqF7HyFLs7FpSRKI8ri1Eh/syjOeSJ7wB34EB/DzaRblj1KX5shV2QQLeccNf4ylhA66adZ1TmsqKE9bQ/hGhMNegrRhYCGwuwQh0DFutiw3FJ2Fb94hoy9jk1CXwNtocgnf3JEfzNNbayV++DeD+1IVf+JIeau8kGFl2GMRvOgESzOla8w3GSeID91p7WwT6s7jS+796oXgy79G3gNwPx+/EgDy87ZTC1F2oC59QDBDOooIj3p7pNWMLaI+MbMQGp96/urhYZgotEjIRHQ4aCY0ReMDJQWmHtiXFcAuQutGU/JbXmGOYPWTmnN6yHQ0iFD1LuuAUa4i7O5mqZCCm8iM+Pm9NtMTy90GqINOSc60VBodPHea91Ls2exNEpInDFt1BzTLyTCMIFNUZgUmd5xnP9y50IJV0ZuK1j09ZMb/x2F11O6OvFaSeg/axaJG1c7EXvwmK+nNkL9nPFR8Bz//riEJnAgqAwFvG4yICWzsFiOTne/b3XQayBZ4YTOzwkURDwuNZaul5w+CISvRJso/DxEzFNtAajHwLvPqpNwOKMAR6zwJ/rxdEfhu9dNl3tzOWVEpN5E28Nh2MaafhJGnIAlPQYoulfshaUBjDDiHn5sbsF3/PFGjycmbNNet0c5Y1zVu7JIQqzpI+4aNQ2Yf95tvd7S6QpZHoQfQ2Hjom4TTPASJ7B9AWXbg9XsDD7Wq7Vh9uOiNT6eGi7ogcNK X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(26005)(316002)(66556008)(21480400003)(186003)(66946007)(31686004)(66476007)(8936002)(508600001)(33964004)(36756003)(16576012)(2616005)(86362001)(31696002)(235185007)(8676002)(83380400001)(44832011)(6486002)(66574015)(6916009)(5660300002)(2906002)(38100700002)(956004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UFZkTVphUnNmaUVCR0dsa1pYUGFsREs0c1orSFRQV2ptT1NuSmJCRmZ1aGVo?= =?utf-8?B?ODZXbm9pdlZ1enZrQWVQYm1FNEc4alZ0Z1BLd2JsOHJtaGJvZ0J6b0RFNEpw?= =?utf-8?B?L1lxNUtHUlhOSmsxQUU3REw0WXdqQUwzR0c4L0tYRThwR0lQWWNXT3JTMkd5?= =?utf-8?B?WGUrNTN6bzNCWERuZDY0c0EwTS8veXJJY0FjWm02bjRsSzhFamZ0WGp2V1VD?= =?utf-8?B?SExhRjRLYmlCYnNRL0lxMjdNN2VqdEpzTk9HL05INmhNQytyRzVQdG5ENUQ3?= =?utf-8?B?ZFd4QkJwNUlDeUZlNVgzUDR6UmYvdmgxbjJ3eHZZaFQrRjRWS09wcjQyeE5j?= =?utf-8?B?NlZySnpjdFFITzZIeFdyZmRHSm95S1h6SGMzVElyb0dzTFB0Y052RGlBY3d5?= =?utf-8?B?YVVBamdQd2UvSFZBclRSY1dEWkJiNldJM2V2TTZONWx3VHhpVHZ0dW9LNjJ6?= =?utf-8?B?YjFRbjNWd3RPbldxY29SZG9vZWxLZDBndzd5ZTR4bzJHU1VDL2d2RDN5L1pW?= =?utf-8?B?T2FRRVFhNCtuYUNremtzRWRvdnpuYldhQVVER1BkU25yWC9aYUpnWUNMdng4?= =?utf-8?B?TDM1ajA0dFZZNTRJMGYxWktpMWNkaHFRTE4zL3ZGWGJTeUtVemdsK08yTFVB?= =?utf-8?B?MmFWdjlueDV2aG5RSytGZFgxaVJTckc0VSs5STcrS0ZMSFZNMFdHanUxeCtm?= =?utf-8?B?Y2hDQ3Vhc0JaTC83L000L2duMEVnNlh1Z05OQVY4R2hYeVdiMyt2OWp6WnJQ?= =?utf-8?B?UmxhNFdOVFlPK3FjRWZoeTBVb1hJQXZjcHVpS0xSbzJJRUlKY1hXSExudWlv?= =?utf-8?B?MWRyV0RSRUNZdllpZmVYRWhvWTJuakI5NzhVREplRk0yTk1wZzNra0IySW4z?= =?utf-8?B?NVU0OURKaytKY1grVEowbzZxK21sTW52QUpPZitDTytmazFoSEl4ODhzOHg0?= =?utf-8?B?U2QyZ1pKTkxvWlVla1F3bjdWRUFTLzJFaXE0dDVQZ0R1WTNoR0QzbkZFbUlX?= =?utf-8?B?WVBDZ2lBVmI0OHd0SVdYSDZiUEhoY3U1aW1TVXdtYXNGclpuVGFubkcweGxs?= =?utf-8?B?VjM0c3AvaHdlM0hCdm44dkZwd1kxcFlLeDVrU0tHaEdPbVpLY3FRRk9FaVM3?= =?utf-8?B?KytDZnlMaXF5bGZuZFY3Wk8xNWdmU0V1SU1HNGpFdlkyVnk3QzduZFo4b0Y3?= =?utf-8?B?UWQzdEFEYXZBYm5mZTRmRHRQV1AyOGNicG5aZjdHZDZKOE1Pc21QMzQ3U2dN?= =?utf-8?B?WFpWYmUvbDc5N1cwUmgrd3h0NGp2WUNIWEhWZU5SMFcvNXVxQ3JGZGR2TGVq?= =?utf-8?B?Qko4bkFVak9yVHBLR0tIQVF6QndnRHBCNloza1pmZEZ6dTRGRWdZR1JUYkVy?= =?utf-8?B?bSt4Q3lYK0o1NDcwUXFYRkFMVk5pcDRWSFZtRzh6TU5ncCtCZVVGSWpibnBi?= =?utf-8?B?bXE0K1FSZVZ1M0FxWUpwUThtYlBEWDBMVDhDZEplR09mK2ZicUxVd0ZCOWox?= =?utf-8?B?dWhPajVzbmViUzJsT0p1N2t6RnlRZ1Z0b01xRHNwSEdyU2JWKzdVaC9EdHpu?= =?utf-8?B?MXNFaVQ3NTNKOVpyNDBNL0lITXJmZ3pOZWVpR1NyaGRFUDU0bjRMNUgxMi85?= =?utf-8?B?OHIwVjZ5UlgvV00vVW11azNjMTJHSlpYQzM1VUZpTVBYeG9lazJlQVFxSTNF?= =?utf-8?B?ajQrZVV6aWRqaWpGbGRCWXVyVG96U3NoenNOaWFlMTM2UVE4M01Xbk45RmNt?= =?utf-8?Q?kODOVkTMUCwYs9ymfUw8qKlikQ/9ATZAqekWDjv?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 8d5153fe-6910-4c50-4d8d-08d981d7f7ef X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2021 16:58:02.9064 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PTkrLig8LctZc1hbUOz5eXfwH3nXo/XWhvJNQyBuELL7zaKGmGzBaIVLVk42ewUX+Daig+FhY6PmiN6uay7FVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0103 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-09-29 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 16:58:18 -0000 --Ik643lbF13uJPHr5yZwdmKKd1uyrbH9Fq Content-Type: multipart/mixed; boundary="MFmINN0nYROqNOyGuP7TqC2NE3KGI1EOc"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <27682b78-b880-c2a7-fff1-bee49f834ad9@ri.se> Subject: [core] CoRE WG Virtual Interim 2021-09-29 --MFmINN0nYROqNOyGuP7TqC2NE3KGI1EOc Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 September 29th at 14:00 UTC. The agenda is available at [1]. As per the Datatracker, the meeting will be on Meetecho [2], while=20 minutes will be taken at [3]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-11/session/cor= e [2]=20 https://meetings.conf.meetecho.com/interim/?short=3D60e19424-f37d-4715-b4= 5b-8bb74ef6aea5 [3] https://codimd.ietf.org/notes-ietf-interim-2021-core-11-core --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --MFmINN0nYROqNOyGuP7TqC2NE3KGI1EOc-- --Ik643lbF13uJPHr5yZwdmKKd1uyrbH9Fq Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmFR+BgFAwAAAAAACgkQ7iZktA5Y2kOK Hgf+MzuyBGbZJhHWjFPC4k7aPcKW1oOqG+rHAGsWRrB/smuWyw4u3WgXp04MKGQtD1sd+CaDmL66 bULFai/5W5uOFdDgm3k9xRRAVxLtw62pSMrY9kHqe/UD5DNJtVx5OvO9eD9gHn/zK4qIpE5SYdBt LR2tfbgQhqLqzjdiADCHcmMuQHzie/3Mci9rPmLoqbx1V7Ddvu/37gsvqBBw5AS+HS22CZARYm5b ReL6VGq/5TaNfs/RDMTmK//x6OB9UdJUjn8CpTyXfs9KzGJf/XpwpkopfiTxPV1E3wKVy1yX+W/R zPBpfSlad5+dbcqXNzN6GLH4ikqIzDGS0hcpUid1pQ== =mHqJ -----END PGP SIGNATURE----- --Ik643lbF13uJPHr5yZwdmKKd1uyrbH9Fq-- From nobody Tue Sep 28 23:54:14 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32D73A1B62; Tue, 28 Sep 2021 23:53: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5G0uNsugrim; Tue, 28 Sep 2021 23:53:53 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C643A1B6A; Tue, 28 Sep 2021 23:53:51 -0700 (PDT) Received: from smtpclient.apple (p548dcf6e.dip0.t-ipconnect.de [84.141.207.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HK6Xq5zpJz2xLY; Wed, 29 Sep 2021 08:53:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <163221352718.31036.11922703653380735485@ietfa.amsl.com> Date: Wed, 29 Sep 2021 08:53:46 +0200 Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez Content-Transfer-Encoding: quoted-printable Message-Id: <3AF5E977-6DF0-450B-969B-34D518AC26E3@tzi.org> References: <163221352718.31036.11922703653380735485@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 06:53:57 -0000 Hi Rob, thank you for pointing out this concern. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this document. >=20 > I have to confess that I am less convinced of the need to have two = ways to > represent this information, i.e., to also support = Content-Format-Strings as > opposed to always requiring a entry in the CoAP Content-Formats = registry. The > CoAP Content-Formats registry seems to be of reasonable size and have = a lot of > space available for FCFS allocations which would mean that it should = be quite > easy to extend if required. However, I'm willing to defer to the = authors & > CORE WG expertise here supporting both ways are needed/useful. Indeed, we actually have an outstanding project to automatically = register a Content-Format number for every one of the couple-thousand = media-type registration out there (this is mostly stalled on practical = issues around how to ensure this is then done for new registrations as = well). However, a Content-Type is not just a media-type name, but also = potentially parameters, and content-codings. Some media-types have a few parameters that can only take a few values, = so it would be possible to register content-format numbers for each = combination. text/plain; charset=3Dutf-8 (Content-Format number 0) is the first = example where this is breaking down a bit: We clearly do not want to register the cross-product of media-type names = that happen to have charset parameters with the registered charset = names, in particular as UTF-8 is the only reasonable value for an = interchange format like SenML that targets long-lived applications. It then gets ugly quickly with actually variable parameters such as = sampling rate, source coding parameters etc. The cross-product consideration also applies to content-coding =E2=80=94 = more so as new content-codings (beyond the widely used, but ageing, = deflate) are becoming more widely used. It is also quite likely that a SenML processor wants to add a = content-coding that has not been on the original sensor data. So we think there is no way to ensure that content-format numbers are = available for all records in a SenML pack, and we need the flexibility = to fall back to a content-format-spec. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 29 04:11:27 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5AE3A0E73; Wed, 29 Sep 2021 04:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIIgngmbSjMb; Wed, 29 Sep 2021 04:11:16 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C073A0E74; Wed, 29 Sep 2021 04:11:12 -0700 (PDT) Received: from [192.168.217.118] (p548dcf6e.dip0.t-ipconnect.de [84.141.207.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HKDFn2r1Wz2xf6; Wed, 29 Sep 2021 13:11:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <163213978178.15913.12022697613892578284@ietfa.amsl.com> Date: Wed, 29 Sep 2021 13:11:09 +0200 Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 654606668.858426-012bcc8146b75c6caca91d354586c19d Content-Transfer-Encoding: quoted-printable Message-Id: <2B4BE0B1-7BB5-49B5-8A8F-9969ADC248CC@tzi.org> References: <163213978178.15913.12022697613892578284@ietfa.amsl.com> To: Lars Eggert X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Lars Eggert's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 11:11:20 -0000 Hi Lars, thank you for having a close look at the cogs and wheels here. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The references to IANA registries could be informative, since RFC7252 > is already normatively cited. I don=E2=80=99t have a strong opinion, but I note that the registries = are actually needed to make use of this document. So I=E2=80=99d like = to stick with a normative reference. (Maybe we need to have something = in the style guide about how normative IANA registry references are.) [other typo =E2=9E=94 = https://github.com/core-wg/senml-data-ct/commit/a3f93] > These URLs in the document can probably be converted to HTTPS: > * http://www.iana.org/assignments/senml > * http://www.iana.org/assignments/core-parameters > * http://www.iana.org/assignments/http-parameters > * http://www.iana.org/assignments/media-types Sigh: = https://mailarchive.ietf.org/arch/msg/tools-discuss/KEgfMQuJGMOIz3LsCKYzNN= Clrz4/ (Four months later, straight from the horse=E2=80=99s mouth: $ curl = https://xml2rfc.tools.ietf.org/public/rfc/bibxml8/reference.IANA.senml.xml= [=E2=80=A6] I don=E2=80=99t think it is productive to fix this manually on each = build, but I did this now.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 29 10:50:48 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490803A083D; Wed, 29 Sep 2021 10:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNOaOFCeq8B9; Wed, 29 Sep 2021 10:49:23 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 4B3263A083C; Wed, 29 Sep 2021 10:49:23 -0700 (PDT) Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 18THnFnG027517 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Sep 2021 17:49:15 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.13; Wed, 29 Sep 2021 10:49:14 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0922.013; Wed, 29 Sep 2021 10:49:14 -0700 From: Michelle Cotton To: Carsten Bormann , Robert Wilton CC: Jaime Jimenez , "draft-ietf-core-senml-data-ct@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" Thread-Topic: [Ext] Re: Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) Thread-Index: AQHXtP7KoPb7NqkDpEuMqt7NaQU3q6u7SqOA Date: Wed, 29 Sep 2021 17:49:14 +0000 Message-ID: <348C1C8F-45F2-421F-B8AF-A473D06D5316@iana.org> References: <163221352718.31036.11922703653380735485@ietfa.amsl.com> <3AF5E977-6DF0-450B-969B-34D518AC26E3@tzi.org> In-Reply-To: <3AF5E977-6DF0-450B-969B-34D518AC26E3@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3715757353_402579561" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-29_07:2021-09-29, 2021-09-29 signatures=0 Archived-At: Subject: Re: [core] [Ext] Re: Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 17:49:33 -0000 --B_3715757353_402579561 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello Carsten, Just double checking regarding this comment below: Indeed, we actually have an outstanding project to automatically regist= er a Content-Format number for every one of the couple-thousand media-type=20 registration out there (this is mostly stalled on practical issues ar= ound how to ensure this is then done for new registrations as well). Does this mean IANA "automatically" registering something? Can you please = clarify about this project? Thank you, Michelle ************ Michelle Cotton Protocol Parameters Engagement Sr. Manager IANA Services =EF=BB=BFOn 9/28/21, 11:54 PM, "iesg on behalf of Carsten Bormann" wrote: Hi Rob, thank you for pointing out this concern. > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - >=20 > Thanks for this document. >=20 > I have to confess that I am less convinced of the need to have two wa= ys to > represent this information, i.e., to also support Content-Format-Stri= ngs as > opposed to always requiring a entry in the CoAP Content-Formats regis= try. The > CoAP Content-Formats registry seems to be of reasonable size and have= a lot of > space available for FCFS allocations which would mean that it should = be quite > easy to extend if required. However, I'm willing to defer to the aut= hors & > CORE WG expertise here supporting both ways are needed/useful. Indeed, we actually have an outstanding project to automatically regist= er a Content-Format number for every one of the couple-thousand media-type r= egistration out there (this is mostly stalled on practical issues around how= to ensure this is then done for new registrations as well). However, a Content-Type is not just a media-type name, but also potenti= ally parameters, and content-codings. Some media-types have a few parameters that can only take a few values,= so it would be possible to register content-format numbers for each combina= tion. text/plain; charset=3Dutf-8 (Content-Format number 0) is the first exampl= e where this is breaking down a bit: We clearly do not want to register the cross-product of media-type name= s that happen to have charset parameters with the registered charset names, = in particular as UTF-8 is the only reasonable value for an interchange forma= t like SenML that targets long-lived applications. It then gets ugly quickly with actually variable parameters such as sam= pling rate, source coding parameters etc. The cross-product consideration also applies to content-coding =E2=80=94 more= so as new content-codings (beyond the widely used, but ageing, deflate) are= becoming more widely used. It is also quite likely that a SenML processor wants to add a content-c= oding that has not been on the original sensor data. So we think there is no way to ensure that content-format numbers are a= vailable for all records in a SenML pack, and we need the flexibility to fal= l back to a content-format-spec. Gr=C3=BC=C3=9Fe, Carsten --B_3715757353_402579561 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISCwYJKoZIhvcNAQcCoIIR/DCCEfgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg/AMIIFrzCCBJegAwIBAgIQAb9GfdVafWaqP8pChY6LTDANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMjAw ODA3MDAwMDAwWhcNMjIxMDI4MTIwMDAwWjCBzDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxKzApBgNVBAMTIk1pY2hl bGxlIENvdHRvbiAoU01JTUUgMTAvMjgvMjAyMikxJzAlBgkqhkiG9w0BCQEWGG1pY2hlbGxl LmNvdHRvbkBpYW5hLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAORSAuKP yQOZeDT1+C+JyDNFSLkJCkwbQcTKMHyvkFPEXy67Sv9cVLha3EaeURR20z4oolde1w/e2vZI bjXFP1fqmQMcoOOnY5gVwGxNazp+uA0ejyiiibFsp2pNGwmlsH6GS7AhGV6g49fEfxPAJxtJ o07IismVoopRT4nARs4IS/6VNRYi22edeTFEREsLZ3HFYiKSbr7VfB0Vn/JLVK1KGEAVUrIk v5U4WizFYNV63fywq9dBW1DjiS5YbaBvZJ+4jvNr2KLoOHHsliImucd169YblxWw8S6cEJmz uRHI3Mf3NYBePmLb/UEkfJ5p5/BD5yub+i7H4PVu8fmOpOsCAwEAAaOCAfEwggHtMB8GA1Ud IwQYMBaAFOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBT3VScp2vawiKA5doG9Rn/w tiEaCzAMBgNVHRMBAf8EAjAAMCMGA1UdEQQcMBqBGG1pY2hlbGxlLmNvdHRvbkBpYW5hLm9y ZzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1Ud IAQ8MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGln aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRt MGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNy dDANBgkqhkiG9w0BAQsFAAOCAQEAgLHPW+HEDV2yzgwqbG2RRSVn6gc9Ud82f57MyWDjT3AQ lro1JH641Kz4QWr53rvYQMak1wObyotqJpFTvXD/sGxNypyrVjFcQlYD4lbLO9wymtmmy2VU 2oFbIxiVgLjKOQjMRvyrWqswiQTCQlbHRD+LLHRN2UDRL09rtaiyxokwBlHpicoHerl6CTiq 5oOcq++0hw+5l9QqTLw6Ld+2FN76hu5iXOGpsIR1OnjHgDaNT+xPP4X00c+9gGV8bpr+YLZS P2JFivSZIJicVvB2FE32fAtNYP0Lp7CUX+Asqqq4d75sx9k9ITHtvfdfFWkHeRKYi3d03dAO 5Y99vHOY6zCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNl cnQgU0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3PgRIz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoF H9pjeFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2 QRdTQDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXq NtdfauIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPh RL16CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQw EgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaG NGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmww OqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD QS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYw ggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQu Y29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8w DQYJKoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jK wXFRXJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4d OZC+W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5d yBn0UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtn eCweknjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhl s+DibsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjEx MTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0 IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0O Fc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+Q rIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlr f9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhV hyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnI sdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0P AQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3z bcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IB AQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVY lzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq 6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBn t2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEw eTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cu ZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAG/ Rn3VWn1mqj/KQoWOi0wwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgA879aJkS eTpUmgpCkkVDflO9kBuqDjtnq3YnW8AwV00wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjEwOTI5MTc0OTEzWjANBgkqhkiG9w0BAQEFAASCAQBcNPPVDPnS 0aw2rfgQwfarX45gONvTqKDZcjN8uwfYo4u0kSXyDSMk4GajhRje3k/PI5PdyLs6L4N6xRAF QoT3hHBEZP25p/WOxbyTeXnkTLyaYhic+sugftHiK51z79YVelniGLkPRV7x8yYyx7is9i9g mixqMYOEzLXpB74WdZj2p0i/KK1dwVR1Y9U55B+ZWbvU3o+TmmNe+iVVjxbtzVksYt5DYRZz WHUbLWYUD7xsXdcvtkvw2c0w1wFrnewhYuKmOVNmaRIodobhFqd89hrYT4av1uZMBCKOJkpx QnEUdJ0efDZa7/IsCMY9UuND7E6KLBdz89nxM8ZZ9Osc --B_3715757353_402579561--