From nobody Sat Aug 1 12:25:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013573A0DFB for ; Sat, 1 Aug 2020 12:25:34 -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 th7dm9o9wGyt for ; Sat, 1 Aug 2020 12:25:32 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B7B3A0DFA for ; Sat, 1 Aug 2020 12:25:32 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 1 Aug 2020 12:25:26 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , 'Marco Tiloca' , 'Francesca Palombini' CC: Date: Sat, 1 Aug 2020 12:25:25 -0700 Message-ID: <04a301d66839$83672d50$8a3587f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZoN0dkod42fujkQca9NimY1M+1/g== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Missing must in the Group OSCORE document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 19:25:35 -0000 Christian, I have been thinking about the problem case of having a duplicate IV reuse in the case where I suggested that we use separate IV spaces for the group and pairwise keying materials. I agree that this is a problem, however the problem is greater than what you outlined. This is going to be a situation that will arise anytime that the request comes in under one security context and the response goes out under a different security context. In this situation you will always have the problem that a reflected IV value from context 1 will lead to a potential IV reuse in context 2. Missing requirement in the document: A server MUST use a PIV value from it's own sender context when ever it would normally use a reflected IV, but the security context for the request and response are not the same. Jim From nobody Sun Aug 2 08:34:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510943A0EFC for ; Sun, 2 Aug 2020 08:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_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 yh9Fvvkm4Ykj for ; Sun, 2 Aug 2020 08:34:37 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00046.outbound.protection.outlook.com [40.107.0.46]) (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 E20253A0EFE for ; Sun, 2 Aug 2020 08:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i7/Ph4f6BcnvlLLL1qHXys/cPehvIh6ZnzMKNwp4Y6sdmrP47UoAAXCrjrcBMOSHEB884YayEsVy5TuraFVeBY7zJ51Rxe2qiCaRGxnB7qAJ/7kRGJIaX+DHIoonq4pbF0+N1NAW1nhRru2+TBjhliLjT5JIMD79mFERrd+45Gn7syqNajev1e4vadU2e/x8v550Hg9jeGzQetVMzLChRdSbz1KcsVu2Jy1QTSnDV0M3uT4Kk0wA/C10TGUX1zmx3feJgaYWeQ73GKhiHCzCI3a0Pld0kR7gqJiB+mlLPQbwx88Umfd3bHoY4BKi6/ROTcBHPxJObLNyfTCUfx5RFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iLISRIC55qe6HktQv0lV4QPteaC2T3mkB7XmBG00taA=; b=eese98ZjLYhFORa2A2bG0pZyFC4jpLrnhQBIyiq3rEbThYjhhqAijzeTLjLA0cxOTCzci5qqfg9z0Yh57m+B73FC6bbpIETr6nVTs/YmUQUVGGXND1fA+1lD/Baw73/HugWA1wprxoXOsr2h9AboQ9OtPCazylOMYow7L2/7sv4nAruhtoRsrP/nN/apgUG17ZuxzromRKlWyyv7meICJqVMXyvTCKzWdG3svj3Hfj5NguGHtaIoRC6mg2182I7B7Fa/OsHbzcGcr3hj0nHnug8kSIiWieOJFLDsf8b8k6RSldZvTdKuJ0hdJg0oqPiSRNnSac8/9owzQltxKwUhmQ== 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=iLISRIC55qe6HktQv0lV4QPteaC2T3mkB7XmBG00taA=; b=WWy4mPmZl67fs74g9KyKPWRdejy1T0J+R4U/TRLtYpO15jGAipIDudriDqAHYGufb4AkHC7SIXPiqjgyUGe620BknZ3JSCwCJsmqhL1H+F1hBh4gouCXUh3ATcMWbtWl3AFvtycTx7U6zBToL+rZF3bB+01707d5qSdtUq2KgDM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Sun, 2 Aug 2020 15:34:33 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3239.021; Sun, 2 Aug 2020 15:34:33 +0000 From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== To: "core@ietf.org WG (core@ietf.org)" Message-ID: <4c58e6df-e43c-236d-a90d-10796d105cd8@ri.se> Date: Sun, 2 Aug 2020 17:34:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="44tLmg3le5AklPjbrDkyPKbBn4zynPVFM" X-ClientProxiedBy: HE1P192CA0008.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::18) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.9] (185.236.42.19) by HE1P192CA0008.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Sun, 2 Aug 2020 15:34:32 +0000 X-Originating-IP: [185.236.42.19] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 568b31ab-1bc6-4bad-aa0d-08d836f98dc5 X-MS-TrafficTypeDiagnostic: VI1P189MB0398: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4DgbdnaZYY8Ayf/fzMfv35nmS5QEC9mNa/mDdvF5Et3foMM66f2nkYwxp9EuX+e/uMRwYcVN+8vryhh02ZKCZf4hmZxoiucknPYfgsItenA55+ahDFrjo1sXSZpmPvGJKogTDsy2zsNshaDhC2kZatddxfcwahK8xJRKNXAEdzGTG7oiyR69SrvPUBzA3EvpbQLLBYGfu1JUzHY7WyTOER4vzJ2LACBEmr9vMpNf+5sUmxZcDewr2yw9S4gNh1QvKj5abDG+hOODt1zw6di0x3VAxIN7oeoacWIswqguXhT4+kMXQJFcTqPP07BGkVVHm2zvtI9oqVvP6Mct4zFU3fJQfQOdBZ4VWEu75v1ifbqKFIyAe+U3AqMdDnRwn9MFhCbK5qWDz4vric4U4xM3ue1v0fVVfQVLMM5ic2NfIcM2yXI7qCzRax2zqJg30UgAkK4EdKVhQ39ytepsSvPe+J+CeCDGE+uVRAIq690fzhQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(136003)(366004)(346002)(39840400004)(86362001)(956004)(966005)(31686004)(2616005)(21480400003)(44832011)(478600001)(8936002)(2906002)(5660300002)(235185007)(6666004)(31696002)(30864003)(52116002)(66946007)(6916009)(66476007)(66556008)(6486002)(36756003)(26005)(316002)(66574015)(8676002)(16576012)(33964004)(83380400001)(186003)(16526019)(11634003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: lvoYd6f62unEDTKYURmrsX4Coj0w3UhgqjNB2OMAmeuZVe1DYm90I1D8G31gh4onl1FxPma9NigwsXieUi+S6762PVTwQ5S3mGfp9Zw0BBYkbT5pedEjP5lEuF5x3Fikhwiy31N4jzksDGcipDbToqYYfNshUIKiynm1QV3hvjK02yo8ZFlT3xpxwuVIB1Vp88/hb4udfAJCUJ3cRNtaqqR6LsCr1auFn6iXPlkJAXJV0QJjhj0hFndBFcZhvXY8MPxv6c1gDmEVukl+AV0qt/FjB0SqMEnrF4l1AZbIDd3JjdpPqUUb/26x8+L9WU04LYx7wxWFSZhBIAbU/ybZiL4+3rczMabI0XkBrTlLiupdYeVZ6p0il78vIHBtt7++ZIJEXEgAg9vCKricgi2toZFk62NSP/rbkjipxL5clBupXNqLSgbjKjZj6HfuELyyUdI9bIs599kMTIp91xD7iJaUOWlyIy1H7+39VmwVQZlLZBe97DVwSP7xsQ2OMM2+8tLzY0Fu4ROiski7cIrZ3K+aNkffTdg/2oVrf6pVk2YxHa+1kkhqe3L78IoFd8O4tHi9jtfqcic0MzCfaAdTXALYrB16kuUuvFUKs2SIwUiBekFkZt0+HWmscALNe3mGj6ScSdcnBtwPn4FLilhGgw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 568b31ab-1bc6-4bad-aa0d-08d836f98dc5 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2020 15:34:32.9761 (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: 4KsruBXBD4u0WUgeg9kgt01o2pUTw6I9khK2wlYC6FRuJl9veOsssEbBwI+9EnafuTcYJuZTGmMXtrvD22GXkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0398 Archived-At: Subject: [core] CoRE @ IETF 108 - Minutes and summary 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, 02 Aug 2020 15:34:41 -0000 --44tLmg3le5AklPjbrDkyPKbBn4zynPVFM Content-Type: multipart/mixed; boundary="CMk8avL0IyM0zJfkabv3eAYh9GHffODDz" --CMk8avL0IyM0zJfkabv3eAYh9GHffODDz Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, The minutes for the two CoRE sessions are available at [1]. Thanks to the fantastic note takers Niklas, Ivaylo, Francesca and Michael! Please, send possible fixes and updates to core-chairs@ietf.org or to the mailing list, preferably within the next 7 days. The recordings of the two CoRE sessions are now available at [2][3]. Finally, you can find below the usual summary of the two sessions, with fewer technical details. This summary together with the raw minutes is also available at [4]. Thank you all for your participation and contribution. Have a great continuation of summer! Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/108/session/core [2] https://www.youtube.com/watch?v=3DrBmhQ_IkDQc [3] https://www.youtube.com/watch?v=3Dvli7kn7YoiU [4] https://github.com/core-wg/wg-materials/blob/master/ietf108/core-108-summ= ary.md ---------- # Summary ## WG and document status =C2=A0 * Published: =C2=A0=C2=A0=C2=A0 * senml-more-units-06: RFC 8798 !! =C2=A0=C2=A0=C2=A0 * senml-etch-07: RFC 8790 !! =C2=A0 * In IESG Processing: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-resource-directory-25: IESG Evaluati= on =C2=A0=C2=A0=C2=A0 * draft-ietf-core-stateless-06: IESG Evaluation::Revis= ed I-D Needed. A few comments remaining, Klaus is processing them. =C2=A0 * In Post-WGLC processing: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-dev-urn-07: AD Evaluation::Revised I= -D Needed. After some discussion, publication was requested as Standards Track. =C2=A0=C2=A0=C2=A0 * draft-ietf-core-echo-request-tag-10: On Shepherd's W= riteup (Marco). =C2=A0=C2=A0=C2=A0 * draft-ietf-core-oscore-groupcomm-09: WGLC finished l= ast week now comments to be processed. =C2=A0=C2=A0=C2=A0 =C2=A0 * In WGLC: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-comi-10 =C2=A0=C2=A0=C2=A0 * draft-ietf-core-sid-14 =C2=A0=C2=A0=C2=A0 * draft-ietf-core-yang-cbor-13 =C2=A0=C2=A0=C2=A0 * draft-ietf-core-yang-library-02 =C2=A0=C2=A0=C2=A0 The WGLC ended on July 29. Carsten will proceed with s= hepherding the documents on mid-August. ## Echo-Request-Tag * draft-ietf-core-echo-request-tag-10 =C2=A0=C2=A0 This latest versions addresses comments post WGLC, related u= pdates have been presented, concerning both the Echo and Request-Tag option, as well as other document improvements. Ongoing shepherd writeup, plan to request for publication soon after this meeting. =C2=A0=C2=A0 =C2=A0=C2=A0 No comment from shepherding, the write up will be written up= next week, then request for publication. =C2=A0=C2=A0 ## Resource Directory * draft-ietf-core-resource-directory-25 This latest version addresses review comments and adds especially security considerations, related to security policies and to the use of Echo for amplification mitigation and client identity in simple registrations. There have been a few interims, some about authorization and use of RD. Not found anything that could be applied to the RD today, bu we will continue with the current state and ship it. There are some ongoing discussions about authentication/authorization with the RD, but they are outside the scope of this current specification. ## CoRE Applications * draft-ietf-core-problem-details-01 Updates were presented and open points discussed. Plan to work on Girhub issues for following revisions. Everyone is free to join the draft repo https://github.com/core-wg/core-problem-details and provide input. =46rom this version, it's just about CoRAL. Discussed how identifiers should be compact, with a low entry barrier. Ongoing research for different approaches to ID schemes. Naming things in a distributed way is one of the two hard problems in computer science. Looking for a way that works well for Problem Types and CoRAL in general. Ideas and suggestions are welcome. Need also to address when a registrant goes away= =2E ## Dynlink =C2=A0=C2=A0=C2=A0 * draft-ietf-core-dynlink-11 Presented updates and planned way forward. Most recent updates incorporated feedback and added small changes. A small group of people has been working on small set of features. Open points are about: observed notifications to reflect restful state change; behavior of pmax in the presence of proxies; possible support for epmin/epmax already used by LwM2M (discussion in Github issue #18). There is one IPR disclosure from Qualcomm, on the current draft not containing epmin/epmax. To keep in mind for future discussions. Next step is to reflect editorial changes and state transfers. Plan to continue discussion in small discussion group, synchronize with Bill if interested to be invited. Meetings over Jitsi. This topic will be also covere in interims after summer. ## SenML Documents * draft-ietf-core-senml-versions-00 Summarized concept of versions signaling as set of features, through a bit array. This doc is also used by RFC 8798 (senml-more-units). It should be ready for WGLC, more reviews would be appropriate. Feature deprecation is hard to predict, but it shouldn't be a problem. People who will review: Bill, Jaime. * draft-ietf-core-senml-data-ct-02 =C2=A0=C2=A0=C2=A0 Indicate the Content-Format of the binary data in the SenML record, so that it can be interpreted correctly. This version removes the must-understand ct_ until a way to use is found. The document will go on a 2-week WGLC. ## Blockwise for DOTS * draft-bosh-core-new-block-04 DOTS creates challenges where there are DDoS attacks and needs mitigation, which is problematic in lossy environments given the large body packets. Proposed two new CoAP options for blockwise transfer, Block3 & Block4 akin to Block1 & Block2. BLOCK3 can send packets without waiting for response, and introduces congestion control to avoid DDoS. GET and FETCH with BLOCK4 trigger BLOCK4 responses provided that the response is big enough. Need for possible better clarification of the document scope, while it claims already that this is not a generic solution, but rather specific to the DOTS use case. The draft discussed at two interim meeting. This latest version incorporates all received comments. The authors request adoption as a WG document. Assessed support for adoption to be confirmed on the mailing start. A call for adoption will start. Christian will provide a review. ## AIF * draft-bormann-core-ace-aif-09 This work was originally for both CoRE and ACE, now ACE has picked it up by ACE, but it is also interesting for CoRE. AIF models access control as a control matrix, with subject and set of permissions. Protection of capabilities is not in scope.=C2=A0 The capabi= lity list is an array of pairs, it takes RESTful case as starting point, but other cases can be specified (e.g. MQTT). Objects are paths, while permissions are expressed as bitmaps. This is good for most applications. Good for static resources, but dynamic action resources can also be around, for which permissions are derived from the base resources, by doubling the bits. First version in 2014, now in WG adoption in ACE. Ben Kaduk asked if there is anything else like this. Most web services have more complicated needs, so AIF is probably too simple. On the other hand, when done, this might be used elsewhere, so we should not block such uses= =2E The AIF pattern is very similar to IPSO (CRUD instead of REST). It's worth writing up for CRUD so a new set of registration bits is not needed every time. A possible extension can provide also dynamic permissions; model the difference between resources that have been created or could have been created by a subject; model time aspects such as the lifetime of an Access Token vs. the lifetime of the resource (e.g. pub-sub topic). This may intersect with identity management. ## EDHOC+OSCORE * draft-palombini-core-oscore-edhoc-00 Based on a discussion started at IETF 106, this new work proposes different approches to combine an execution of EDHOC with the first OSCORE exchange following it. The different approaches can also be signaled in different ways. Essentially, the EDHOC verification on the client is merged with the first OSCORE request protected with the derived security context. This optimization would reduce the overall number of roundtrips. The goal is to select only one approach signaled in one way. Approach 1. EDHOC in OSCORE =C2=A0=C2=A0=C2=A0 - Define new CoAP option indicating that message is bo= th EDHOC and OSCORE =C2=A0=C2=A0=C2=A0 Approach 2. EDHOC in OSCORE =C2=A0=C2=A0=C2=A0 - Use the OSCORE option and a new flag bit to tell tha= t the payload contains both=C2=A0=C2=A0 Approach 3. OSCORE in EDHOC =C2=A0=C2=A0=C2=A0 - Define new CoAP option indicating that the message i= s both EDHOC and OSCORE Approach 4. OSCORE in EDHOC =C2=A0=C2=A0=C2=A0 - Signal with new content format. Approaches 1 and 2 seem preferred, with most preferences for Approach 2. A short-enough EDHOC message can go in the option. Carsten and Klaus can provide feedback on this point. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 People who will review: Christian, Carsten, Jim. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ## Group Communication * draft-ietf-core-groupcomm-bis-01 Discussed current Github issues and other open points. Agreement regarding port number in responses; criteria consistency for response suppression; usage of URI-host for naming application groups; usage of admin-local scope; rationale for mapping between security groups and applications groups. Next version will focus on closing these open points= =2E People who have read this or a previous version: Jim, Christian, Francesc= a People who will review: Carsten, Jim, Christian * draft-ietf-core-oscore-groupcomm-09 This last versions addresses all open point raised at the April virtual meeting. More open points were discussed (mostly coming from the WGLC), requiring more thinking: =C2=A0=C2=A0=C2=A0 1. For the pairwise mode, it should be possible to sig= nal the curve used for the secret derivation, e.g. Montgomery or Weierstrass. It should work to have it as additional information in the security context. Then the same MTI as today can be kept. =C2=A0=C2=A0=C2=A0 2. It's convenient to reset the SSN after group rekeyi= ng, which becomes easier to detect. =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 3. For observations, useful to store the Context ID of= the original request. This would prevent notification misbinding across group rekeying if the SSN is reset. There may be further ways to look into. =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 4. New proposal for separated PIV spaces, for the grou= p mode and the pairwise mode. Early discussion of pros/cons to be continued. Impact on communication overhead, space synchronization with the Echo option, and privacy implications. Some people expressed concerns. =C2=A0=C2=A0=C2=A0 People who have read: Jim, Christian People who will read: Carsten * draft-tiloca-core-oscore-discovery-06 The document defines a method to use the Resource Directory to find links for joining OSCORE groups at their Group Manager (GM). Now it has full support for Link Format or CoRAL. The Fairhair example was polished and also translated to CoRAL. The next version will address some open points, and align with other GM administrative drafts. A future document collecting all target attributes can include also the ones defined in this document. Possible interest can be discussed with Fairhair/BACnet and others. T2TRG can be a good venue, with CoRE invited. * draft-tiloca-core-observe-multicast-notifications-03 The document defines a method to send observe notifications to a set of clients observing a same resource at the server, by using multicast responses. This latest versions updates the encoding of the informative error response to the clients; the mechanism for roughly counting the active clients; and alternative ways to obtain the phantom request associated to the group request. Feedback would be needed on having optional or mandatory also the latest notification sent inside the informative response. Next updates will be about adapting the approach to work also with proxies. People who will review: Jim, G=C3=B6ran, Jaime, Carsten * draft-tiloca-core-groupcomm-proxy-01 The document defines a method to have proxies working in a group communication setting. It addresses the issues in the groupcomm-bis document. The proxy forwards back to the client the individual responses from the servers. The client distinguishes the servers originating the responses and learn their addresses. Two new CoAP options are defined. An appendix describes "Nested OSCORE", to further protect with OSCORE (client to proxy) the group request already protected with Group OSCORE (client to servers). This allows the proxy to still identify the client (as required), as an alternative to DTLS as a separate protocol on the Client-Proxy leg. Next steps will focus on chains of proxies and HTTP headers analogous to the two new options, for cross-proxies. People who have read or are interested: Jim, Christian, Carsten, Francesc= a * draft-amsuess-core-cachable-oscore-00 The documents defines the concept of "Consensus Request", protected with Group OSCORE but yet enabling proxies to serve cached responses to it. Related paper: https://arxiv.org/pdf/2001.08023.pdf A possible type is a "Ticket Request" generated by the server, of which the phantom request used for multicast notifications is a particular case= =2E Another type is a "Deterministic Request", that all clients have to be able to generate as a one and same request. It becomes tricky with Partial IV and key to use. A possible way is proposed based on a "Deterministic client". Some encryption algorithms might have to be ruled out, none of them are in COSE. Next version will give clarifications and more details. Positive feedback on CoRE being the right venue and the importance of the problem People who will review an updated version: Francesca, Jaime ---------- --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --CMk8avL0IyM0zJfkabv3eAYh9GHffODDz-- --44tLmg3le5AklPjbrDkyPKbBn4zynPVFM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8m3QYACgkQ7iZktA5Y 2kO3RQf/bSWkJrrVCCeL/nfvWnXZAjqhexvGol5zs4YiEhjIzbNF4jW1up8CEAYD jochvFUI/U+tsZmltPwJxEmN8a/AcpoyRYa8JZWPxYmKS/xt/DlOTS7YuqE12L/l YkOjJZIHkEV+FGUusCBHUAsuy7dEgDzvDWcynEB0+Z7z46j1qDDEwOMq8pnbWRKv DRZn6BDPvJZ+SySHtAXG9UhMW0l0gRkr4TA8vNvx3js9bXH6FD55QiOCHCZ3jmv6 k2ia0/276Qo36/a7WcmR/xicqrrbGQ4pFPdTZknXQWj0ewUfHzqZagU5SpNQRVz2 IQDnWjCumd9xtMsR+UNFuyDgmo5FMw== =8mGu -----END PGP SIGNATURE----- --44tLmg3le5AklPjbrDkyPKbBn4zynPVFM-- From nobody Mon Aug 3 09:35:10 2020 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 B54A33A10BD; Mon, 3 Aug 2020 09:35:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Marco Tiloca via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Marco Tiloca , iesg-secretary@ietf.org, core@ietf.org, core-chairs@ietf.org, marco.tiloca@ri.se Message-ID: <159647250372.1055.4934227892139167853@ietfa.amsl.com> Date: Mon, 03 Aug 2020 09:35:03 -0700 Archived-At: Subject: [core] Publication has been requested for draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 16:35:09 -0000 Marco Tiloca has requested publication of draft-ietf-core-echo-request-tag-10 as Proposed Standard on behalf of the CORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ From nobody Mon Aug 3 20:17:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF33A094B; Mon, 3 Aug 2020 20:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmfcFugguS19; Mon, 3 Aug 2020 20:16:57 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 3EEB13A093B; Mon, 3 Aug 2020 20:16:54 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id g19so28692357ioh.8; Mon, 03 Aug 2020 20:16:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=04ndaV/uwFzzFiqe5f+uwgYkYU/n1PmC1w/3Y1gNYzE=; b=AwSigPPOdu8BairF8A7QTOKdLXDfl+bFk0LARPrD9Z1hNG3p/EJkbxBmURa/gKE1bj l1mSbtOg8oANQvilaGxSCqnCI1LIINFqC80j4HGhVfATQHEy9hY8sGBVHWErB41KfMOP xEGg1zhyeoj59clg0gjZ89DZgFe1Wkxs/+Qxi9igS0sOxdVkhlyimUR5CWQytG+lc7Kv QDHuC4J5aE+0HC6vnCTSK7KBivEUeL2Yk3UDyj17/k28n5H3PYdXnt8YH8LRKcCWYGqI niF3yYyGs01DcBvN2cqaFEq9qa56S0KBO9M3kqFxUvTmmH9FM2vo8RoqJ1o1qOSw2Dlr aWLg== X-Gm-Message-State: AOAM5311h0xMZkuLiL8l24BUi+pAEof/46vsD+AygSFeUeFoB7UdyGMr /p0QcSi7tkGl03H/7qMJD91WOOO9ETzBSUaooWaA1Q== X-Google-Smtp-Source: ABdhPJxzUvW8CWRJGPXMfEbTRt3kcyiRm5k20fSRH8Tv8o8yxXXuqgp3HiCXlWJRMmEIRqi5KR6TIOHcSMYRGpklLfs= X-Received: by 2002:a6b:5502:: with SMTP id j2mr3100235iob.204.1596511012434; Mon, 03 Aug 2020 20:16:52 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Mon, 3 Aug 2020 23:16:41 -0400 Message-ID: To: "draft-ietf-core-echo-request-tag.all@ietf.org" Cc: "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c6ba3a05ac04af80" Archived-At: Subject: [core] AD review of draft-ietf-core-echo-request-tag-10 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, 04 Aug 2020 03:17:00 -0000 --000000000000c6ba3a05ac04af80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the work on this document. I have a number of comments about things that I think need clarification or rewording in my review below, so I=E2=80=99m setting the state on the document to =E2=80=9Crevised I-D neede= d.=E2=80=9D Please ask if you have questions or disagreements with anything below, and let=E2=80= =99s discuss anything that needs discussion. I would prefer it if the document were specific about what =E2=80=9Cwhen Co= AP is used with security=E2=80=9D means, ideally not using that phrase at all, as =E2=80=9Csecurity=E2=80=9D without explanation isn=E2=80=99t meaningful. I= f you mean =E2=80=9Cover an encrypted channel=E2=80=9D, please say that. Or something else? =E2=80=94 Section 1.1 =E2=80=94 Unless otherwise specified, the terms "client" and "server" refers to Nit: =E2=80=9Crefer to=E2=80=9D, plural. The complete interchange of a request and a response body is called a (REST) "operation". =E2=80=9CREST=E2=80=9D will need expansion and a reference. You can copy t= hese from 7252. Two request messages are said to be "matchable" if they occur between the same endpoint pair, have the same code and the same set of options except for elective NoCacheKey options and options involved in block-wise transfer (Block1, Block2 and Request-Tag). There=E2=80=99s something missing here: this says, =E2=80=9CX is true if A,= B.=E2=80=9D It needs an =E2=80=9Cand=E2=80=9D or an =E2=80=9Cor=E2=80=9D instead of the comma, n= o? Two matchable block-wise operations are said to be "concurrent" if a block of the second request is exchanged even though the client still intends to exchange further blocks in the first operation. This appears to describe concurrent block-wise request operations. Can there also be concurrent block-wise response operations? =E2=80=94 Section 2.2 =E2=80=94 but also in general for synchronizing state between CoAP client and server, cryptographically verify the aliveness of the client, or force a client to demonstrate reachability at its claimed Nit: This isn=E2=80=99t parallel: the first item uses =E2=80=9Csynchronizin= g=E2=80=9D, so the second should use =E2=80=9Cverifying=E2=80=9D and the third should use =E2= =80=9Cforcing=E2=80=9D. =E2=80=94 Section 2.3 =E2=80=94 One way for the server to verify freshness is that to bind the Echo Nit: There appears to be an extra word, =E2=80=9Cthat=E2=80=9D. (In most cases, this means that the proxy needs to ask the client to repeat the request with a new Echo value). Nit: the =E2=80=9C.=E2=80=9D needs to be inside the parentheses. =E2=80=94 Section 3.3 =E2=80=94 results in the new message not being part of he old operation. Typo: =E2=80=9Cthe old=E2=80=9D =E2=80=94 Section 3.4 =E2=80=94 What constitutes a concluded operation depends on that purpose, and is defined there. I=E2=80=99m missing the antecedent to =E2=80=9Cthere=E2=80=9D. Where? The Request-Tag options MAY be present in request messages that carry no Block option (for example, because a Request-Tag unaware proxy reassembled them), and MUST be ignored in those. I think this should be =E2=80=9Cmay=E2=80=9D (or =E2=80=9Cmight=E2=80=9D), = not =E2=80=9CMAY=E2=80=9D. You=E2=80=99re not suggesting it as an option to do, but are instead warning about something that might happen. =E2=80=94 Section 3.5.1 =E2=80=94 is still possible for a man-in-the-middle to maliciously replace a later operation's blocks with an earlier operation's blocks Not a requirement here, and I will accept your best judgment: in the spirit of recent discussion on inclusive vs exclusionary language, I ask you to consider changing =E2=80=9Ca man-in-the-middle=E2=80=9D to =E2=80=9C= an on-path attacker=E2=80=9D. changed, then the client MUST consider messages sent to _any_ endpoint address within the new operation's security context. This is ambiguous. I think you mean =E2=80=9Cto be within=E2=80=9D, yes? o The client MUST NOT regard a block-wise request operation as concluded unless all of the messages the client previously sent in the operation have been confirmed by the message integrity protection mechanism, or are considered invalid by the server if replayed. It=E2=80=99s not clear to me how a client can comply with this: how can the= client possibly know whether the messages it has sent would be considered invalid by the server if they were replayed? Or is there something I=E2=80=99m not understanding? Honestly, I=E2=80=99m having trouble following the explanations in this sec= tion, in general, so there=E2=80=99s a reasonable chance that I am missing something= . =E2=80=94 Section 3.6 =E2=80=94 key, because to proxies unaware of the Request-Tag option Nit: I think =E2=80=9Cto=E2=80=9D is an extra word. The Request-Tag option is repeatable because this easily allows stateless proxies to "chain" their origin address. They can perform the steps of Section 3.5.3 without the need to create an option value that is the concatenation of the received option and their own value, and can simply add a new Request-Tag option unconditionally. I don=E2=80=99t know what =E2=80=98=E2=80=9Cchain=E2=80=9D their origin add= ress=E2=80=99 means, and I don=E2=80=99t know what =E2=80=98their own value=E2=80=99 means. Can you clarify this? In draft versions of this document, the Request-Tag option used to be critical and unsafe to forward. That design was based on an erroneous understanding of which blocks could be composed according to [RFC7959]. It makes sense that this was here during working group discussion. Is there value in having it in the published RFC? If so, why? =E2=80=94 Section 3.8 =E2=80=94 The threat model here is not an attacker (because the response is made sure to belong to the current request by the security layer), but blocks in the client's cache. I don=E2=80=99t understand =E2=80=9CThe threat model is blocks in the clien= t=E2=80=99s cache.=E2=80=9D I think this needs some rewording to explain better what you mean. =E2=80=94 Section 4.1 =E2=80=94 The wrong response may be an old response for the same resource or for a completely different resource Are you referring to an old response for a completely different resource (which is what this says as written), or to any response for a completely different resource (which is what I think you mean)? If the latter, it should say, =E2=80=9C...or a response for a completely different resource= =E2=80=9D. A straightforward mitigation is to mandate clients to not reuse Tokens until the traffic keys have been replaced. One easy way to accomplish this is to implement the Token as a counter starting at zero for each new or rekeyed secure connection. This is essentially repeated in the next section. Can you avoid that, probably by rewording this to say that the next section privides a mitigation? =E2=80=94 Section 4.2 =E2=80=94 One easy way to accomplish this is to implement the Token (or part of the Token) as a sequence number starting at zero for each new or rekeyed secure connection, this approach SHOULD be followed. This is not a proper sentence: I think it=E2=80=99s two sentences splicd to= gether, but it might be that it needs rewording instead. =E2=80=94 Section 5 =E2=80=94 As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see ([RFC8613], Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. Nit: =E2=80=9Cneeds=E2=80=9D, singular. And this also looks like two sentences spliced together. Unless a counting Echo value is used, the Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits. What=E2=80=99s the reason for not just using MUST for 64 bits and being don= e with it? They MUST only be used when the request Echo values are integrity protected. I think this is a tricky way to word it, and that it invites misunderstanding. I suggest that it might be better said as, =E2=80=9CThey= MUST NOT be used unless the request Echo values are integrity protected.=E2=80= =9D Servers MAY use the time since reboot measured in some unit of time. For what? It=E2=80=99s not clear to me what this refers to. the server MUST reject all Echo values that was created before Nit: =E2=80=9Cwere=E2=80=9D, plural. =E2=80=94 Section 5.1 =E2=80=94 Reusing Tokens in a way so that responses are guaranteed to not be associated with the wrong request is not trivial as on-path attackers may block, delay, and reorder messages, requests may be sent to several servers, and servers may process requests in any order and send many responses to the same request. This is a complicated sentence and it has a lot of cascaded negatives. Please try rewording it, and consider splitting it up. One way is to start with =E2=80=9COn-path=E2=80=9D to the end of the sentence, and then have an= other sentence that says, =E2=80=9CThat makes it non-trivial to reuse tokens...=E2=80=9D client is sending TLS protected requests without Observe Nit: hyphenate =E2=80=9CTLS-protected=E2=80=9D. =E2=80=94 Section 6 =E2=80=94 Implementations SHOULD NOT put any privacy sensitive information Nit: hyphenate =E2=80=9Cprivacy-sensitive=E2=80=9D. Unencrypted timestamps MAY reveal information about the server This needs to be =E2=80=9Cmay=E2=80=9D (or =E2=80=9Ccould=E2=80=9D), as it= =E2=80=99s a statement, not a directive. Like HTTP cookies, the Echo option could potentially be abused as a tracking mechanism to link to different requests to the same client. I can=E2=80=99t follow this sentence, particularly the part with the word = =E2=80=9Cto=E2=80=9D repeated three times. Please reword it. Clients only send Echo to the same server from which they were received. The only possible antecedent to =E2=80=9Cthey=E2=80=9D here is =E2=80=9Ccli= ents=E2=80=9D, which is clearly wrong: you mean =E2=80=9CEcho=E2=80=9D. So this needs rewording. Maybe us= e =E2=80=9CEcho options=E2=80=9D, or something like that. =E2=80=94 Section 8.2 =E2=80=94 I=E2=80=99m having a hard time deciding whether some of these references sh= ould be normative, especially 8613. Please give these another review with that in mind and see if you think any of them should be moved. You can find some guidance in the relevant IESG Statement < https://www.ietf.org/about/groups/iesg/statements/normative-informative-ref= erences/>, keeping in mind the general rule that something that needs to be fully understood should be normative, while something that just adds extra enlightenment can be informative. =E2=80=94 Appendix A =E2=80=94 security against an attacker guessing echo values is given by s =3D bit length of r - log2(n). What is =E2=80=9Cr=E2=80=9D? A server MAY want to encrypt its timestamps I suggest that a server doesn=E2=80=99t =E2=80=9Cwant=E2=80=9D to do anythi= ng. Perhaps it=E2=80=99s better to say, =E2=80=9CIt might be important to encrypt a server=E2=80=99s timest= amps (see Section 6)=E2=80=9D. =E2=80=94 Appendix B =E2=80=94 repeated transmission failure; in DTLS, if no packages are lost) Should that be =E2=80=9Cpackets=E2=80=9D? In those situations, no message has any Request-Tag option set, and that can be recycled indefinitely. I don=E2=80=99t understand what is being =E2=80=9Crecycled=E2=80=9D if you= =E2=80=99re not using he Request-Tag option (also applies to the subsequent sentence). =E2=80=94 Barry --000000000000c6ba3a05ac04af80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the work on this document.=C2=A0 I have a numb= er of comments about things that I think need clarification or rewording in= my review below, so I=E2=80=99m setting the state on the document to =E2= =80=9Crevised I-D needed.=E2=80=9D =C2=A0Please ask if you have questions o= r disagreements with anything below, and let=E2=80=99s discuss anything tha= t needs discussion.

I wo= uld prefer it if the document were specific about what =E2=80=9Cwhen CoAP i= s used with security=E2=80=9D means, ideally not using that phrase at all, = as =E2=80=9Csecurity=E2=80=9D without explanation isn=E2=80=99t meaningful.= =C2=A0 If you mean =E2=80=9Cover an encrypted channel=E2=80=9D, please say = that.=C2=A0 Or something else?

=E2=80=94 Section 1.1 =E2=80=94

=C2=A0 =C2=A0Unless otherwise specified, the terms "= ;client" and "server" refers to

<= /div>
Nit: =E2=80=9Crefer to=E2=80=9D, plural.

=C2=A0 =C2=A0The complete interchan= ge of a request and a response body is called a
=C2= =A0 =C2=A0(REST) "operation".

=E2=80=9CREST=E2=80=9D will need expansion and a reference.= =C2=A0 You can copy these from 7252.

=C2=A0 =C2=A0Two request messages are said to be "matchab= le" if they occur between
=C2=A0 =C2=A0the same= endpoint pair, have the same code and the same set of
=C2=A0 =C2=A0options except for elective NoCacheKey options and options = involved
=C2=A0 =C2=A0in block-wise transfer (Block1= , Block2 and Request-Tag).

There=E2=80=99s something missing here: this says, =E2=80=9CX is true if= A, B.=E2=80=9D =C2=A0It needs an =E2=80=9Cand=E2=80=9D or an =E2=80=9Cor= =E2=80=9D instead of the comma, no?

=C2=A0 =C2=A0Two matchable block-wise operations are said to be= "concurrent" if a
=C2=A0 =C2=A0block of t= he second request is exchanged even though the client still
=C2=A0 =C2=A0intends to exchange further blocks in the first oper= ation.

This appears to d= escribe concurrent block-wise request operations.=C2=A0 Can there also be c= oncurrent block-wise response operations?

=
=E2=80=94 Section 2.2 =E2=80=94
=C2=A0 =C2=A0but also in general for synchronizin= g state between CoAP
=C2=A0 =C2=A0client and server,= cryptographically verify the aliveness of the
=C2= =A0 =C2=A0client, or force a client to demonstrate reachability at its clai= med

Nit: This isn=E2=80= =99t parallel: the first item uses =E2=80=9Csynchronizing=E2=80=9D, so the = second should use =E2=80=9Cverifying=E2=80=9D and the third should use =E2= =80=9Cforcing=E2=80=9D.

= =E2=80=94 Section 2.3 =E2=80=94

=C2=A0 =C2=A0One way for the server to verify freshness is that t= o bind the Echo

Nit: The= re appears to be an extra word, =E2=80=9Cthat=E2=80=9D.

=C2=A0 =C2=A0(In most cases, this means tha= t the proxy
=C2=A0 =C2=A0needs to ask the client to = repeat the request with a new Echo value).

Nit: the =E2=80=9C.=E2=80=9D needs to be inside the pare= ntheses.

=E2=80=94 Secti= on 3.3 =E2=80=94

=C2=A0 = =C2=A0results in the new message not being part of he old operation.
<= div dir=3D"auto">
Typo: =E2=80=9Cthe old=E2=80= =9D

=E2=80=94 Section 3.= 4 =E2=80=94

=C2=A0 =C2= =A0What constitutes a concluded operation
=C2=A0 =C2= =A0depends on that purpose, and is defined there.
I=E2=80=99m missing the antecedent to =E2=80=9Cth= ere=E2=80=9D.=C2=A0 Where?

=C2=A0 =C2=A0The Request-Tag options MAY be present in request messages = that carry
=C2=A0 =C2=A0no Block option (for example= , because a Request-Tag unaware proxy
=C2=A0 =C2=A0r= eassembled them), and MUST be ignored in those.

=
I think this should be =E2=80=9Cmay=E2=80=9D (or = =E2=80=9Cmight=E2=80=9D), not =E2=80=9CMAY=E2=80=9D.=C2=A0 You=E2=80=99re n= ot suggesting it as an option to do, but are instead warning about somethin= g that might happen.

=E2= =80=94 Section 3.5.1 =E2=80=94

=C2=A0 =C2=A0is still possible for a man-in-the-middle to maliciousl= y replace a
=C2=A0 =C2=A0later operation's block= s with an earlier operation's blocks

<= div dir=3D"auto">Not a requirement here, and I will accept your best judgme= nt: =C2=A0in the spirit of recent discussion on inclusive vs exclusionary l= anguage, I ask you to consider changing =E2=80=9Ca man-in-the-middle=E2=80= =9D to =E2=80=9Can on-path attacker=E2=80=9D.

=C2=A0 =C2=A0 =C2=A0 changed, then the client MUST co= nsider messages sent to _any_
=C2=A0 =C2=A0 =C2=A0 e= ndpoint address within the new operation's security context.

This is ambiguous.=C2=A0 I think y= ou mean =E2=80=9Cto be within=E2=80=9D, yes?

=C2=A0 =C2=A0o =C2=A0The client MUST NOT regard a bloc= k-wise request operation as
=C2=A0 =C2=A0 =C2=A0 con= cluded unless all of the messages the client previously sent in
=C2=A0 =C2=A0 =C2=A0 the operation have been confirmed by the m= essage integrity
=C2=A0 =C2=A0 =C2=A0 protection mec= hanism, or are considered invalid by the server if
= =C2=A0 =C2=A0 =C2=A0 replayed.

It=E2=80=99s not clear to me how a client can comply with this: how = can the client possibly know whether the messages it has sent would be cons= idered invalid by the server if they were replayed?=C2=A0 Or is there somet= hing I=E2=80=99m not understanding?

Honestly, I=E2=80=99m having trouble following the explanations= in this section, in general, so there=E2=80=99s a reasonable chance that I= am missing something.

= =E2=80=94 Section 3.6 =E2=80=94

=C2=A0 =C2=A0key, because to proxies unaware of the Request-Tag o= ption

Nit: I think =E2= =80=9Cto=E2=80=9D is an extra word.

=C2=A0 =C2=A0The Request-Tag option is repeatable because this = easily allows
=C2=A0 =C2=A0stateless proxies to &quo= t;chain" their origin address.=C2=A0 They can perform
=C2=A0 =C2=A0the steps of Section 3.5.3 without the need to create a= n option value
=C2=A0 =C2=A0that is the concatenatio= n of the received option and their own value,
=C2=A0= =C2=A0and can simply add a new Request-Tag option unconditionally.

I don=E2=80=99t know what =E2= =80=98=E2=80=9Cchain=E2=80=9D their origin address=E2=80=99 means, and I do= n=E2=80=99t know what =E2=80=98their own value=E2=80=99 means.=C2=A0 Can yo= u clarify this?

=C2=A0 = =C2=A0In draft versions of this document, the Request-Tag option used to be=
=C2=A0 =C2=A0critical and unsafe to forward.=C2=A0 = That design was based on an
=C2=A0 =C2=A0erroneous u= nderstanding of which blocks could be composed according
=C2=A0 =C2=A0to [RFC7959].

It makes sense that this was here during working group discussion= .=C2=A0 Is there value in having it in the published RFC?=C2=A0 If so, why?=

=E2=80=94 Section 3.8 = =E2=80=94

=C2=A0 =C2=A0T= he threat model here is not an
=C2=A0 =C2=A0attacker= (because the response is made sure to belong to the current
=C2=A0 =C2=A0request by the security layer), but blocks in the cl= ient's cache.

I don= =E2=80=99t understand =E2=80=9CThe threat model is blocks in the client=E2= =80=99s cache.=E2=80=9D =C2=A0I think this needs some rewording to explain = better what you mean.

= =E2=80=94 Section 4.1 =E2=80=94

=C2=A0 =C2=A0The wrong response may be an old response for the sa= me
=C2=A0 =C2=A0resource or for a completely differe= nt resource

Are you refe= rring to an old response for a completely different resource (which is what= this says as written), or to any response for a completely different resou= rce (which is what I think you mean)?=C2=A0 If the latter, it should say, = =E2=80=9C...or a response for a completely different resource=E2=80=9D.

=C2=A0 =C2=A0A straightforw= ard mitigation is to mandate clients to not reuse
= =C2=A0 =C2=A0Tokens until the traffic keys have been replaced.=C2=A0 One ea= sy way to
=C2=A0 =C2=A0accomplish this is to impleme= nt the Token as a counter starting at
=C2=A0 =C2=A0z= ero for each new or rekeyed secure connection.

<= /div>
This is essentially repeated in the next section.=C2= =A0 Can you avoid that, probably by rewording this to say that the next sec= tion privides a mitigation?

=E2=80=94 Section 4.2 =E2=80=94

=C2=A0 =C2=A0One easy way to accomplish this is to implement th= e Token (or part of
=C2=A0 =C2=A0the Token) as a seq= uence number starting at zero for each new or
=C2=A0= =C2=A0rekeyed secure connection, this approach SHOULD be followed.

This is not a proper sentence: = I think it=E2=80=99s two sentences splicd together, but it might be that it= needs rewording instead.

=E2=80=94 Section 5 =E2=80=94

=C2=A0 =C2=A0As each pseudoranom number must only be used once,
=C2=A0 =C2=A0an implementation need to get a new trul= y random seed after reboot,
=C2=A0 =C2=A0or continou= sly store state in nonvolatile memory, see ([RFC8613],
=C2=A0 =C2=A0Appendix B.1.1) for issues and solution approaches for writ= ing to
=C2=A0 =C2=A0nonvolatile memory.

Nit: =E2=80=9Cneeds=E2=80=9D, singul= ar.

And this also looks = like two sentences spliced together.

=C2=A0 =C2=A0Unless a counting Echo value is used, the Echo
=C2=A0 =C2=A0option value MUST contain 32 (pseudo-)ran= dom bits that are not
=C2=A0 =C2=A0predictable for a= ny other party than the server, and SHOULD contain
= =C2=A0 =C2=A064 (pseudo-)random bits.

What=E2=80=99s the reason for not just using MUST for 64 bits= and being done with it?

=C2=A0 =C2=A0They MUST only be
=C2=A0 =C2=A0used wh= en the request Echo values are integrity protected.
=
I think this is a tricky way to word it, and th= at it invites misunderstanding.=C2=A0 I suggest that it might be better sai= d as, =E2=80=9CThey MUST NOT be used unless the request Echo values are int= egrity protected.=E2=80=9D

=C2=A0 =C2=A0Servers MAY use the time since reboot measured in some unit= of time.

For what?=C2= =A0 It=E2=80=99s not clear to me what this refers to.

=C2=A0 =C2=A0the server MUST reject all Echo = values that was created before

Nit: =E2=80=9Cwere=E2=80=9D, plural.

=E2=80=94 Section 5.1 =E2=80=94
=
=C2=A0 =C2=A0Reusing Tokens in a way so that re= sponses are guaranteed to not be
=C2=A0 =C2=A0associ= ated with the wrong request is not trivial as on-path attackers
=C2=A0 =C2=A0may block, delay, and reorder messages, requests m= ay be sent to
=C2=A0 =C2=A0several servers, and serv= ers may process requests in any order and
=C2=A0 =C2= =A0send many responses to the same request.

This is a complicated sentence and it has a lot of casc= aded negatives.=C2=A0 Please try rewording it, and consider splitting it up= .=C2=A0 One way is to start with =E2=80=9COn-path=E2=80=9D to the end of th= e sentence, and then have another sentence that says, =E2=80=9CThat makes i= t non-trivial to reuse tokens...=E2=80=9D

=
=C2=A0 =C2=A0 =C2=A0 client is sending TLS protected requ= ests without Observe

Nit= : hyphenate =E2=80=9CTLS-protected=E2=80=9D.

=E2=80=94 Section 6 =E2=80=94
<= br>
=C2=A0 =C2=A0Implementations SHOULD NOT put any = privacy sensitive information

Nit: hyphenate =E2=80=9Cprivacy-sensitive=E2=80=9D.

=C2=A0 =C2=A0Unencrypted timestamps MAY
=C2=A0 =C2=A0reveal information about the server

This needs to be =E2=80=9Cma= y=E2=80=9D (or =E2=80=9Ccould=E2=80=9D), as it=E2=80=99s a statement, not a= directive.

=C2=A0 =C2= =A0Like HTTP cookies, the Echo option could potentially be abused as a
=C2=A0 =C2=A0tracking mechanism to link to different req= uests to the same client.

I can=E2=80=99t follow this sentence, particularly the part with the word= =E2=80=9Cto=E2=80=9D repeated three times.=C2=A0 Please reword it.

=C2=A0 =C2=A0Clients only send = Echo to the same
=C2=A0 =C2=A0server from which they= were received.

The only= possible antecedent to =E2=80=9Cthey=E2=80=9D here is =E2=80=9Cclients=E2= =80=9D, which is clearly wrong: you mean =E2=80=9CEcho=E2=80=9D.=C2=A0 So t= his needs rewording.=C2=A0 Maybe use =E2=80=9CEcho options=E2=80=9D, or som= ething like that.

=E2=80= =94 Section 8.2 =E2=80=94
I=E2=80=99m having a hard = time deciding whether some of these references should be normative, especia= lly 8613.=C2=A0 Please give these another review with that in mind and see = if you think any of them should be moved.=C2=A0 You can find some guidance = in the relevant IESG Statement <https://www.ietf.or= g/about/groups/iesg/statements/normative-informative-references/>, k= eeping in mind the general rule that something that needs to be fully under= stood should be normative, while something that just adds extra enlightenme= nt can be informative.

= =E2=80=94 Appendix A =E2=80=94

=C2=A0 =C2=A0security against an attacker guessing echo values is gi= ven by s =3D bit
=C2=A0 =C2=A0length of r - log2(n).=

What is =E2=80=9Cr=E2= =80=9D?

=C2=A0 =C2=A0A s= erver MAY want to encrypt its timestamps

<= div dir=3D"auto">I suggest that a server doesn=E2=80=99t =E2=80=9Cwant=E2= =80=9D to do anything.=C2=A0 Perhaps it=E2=80=99s better to say, =E2=80=9CI= t might be important to encrypt a server=E2=80=99s timestamps (see Section = 6)=E2=80=9D.

=E2=80=94 A= ppendix B =E2=80=94

=C2= =A0 =C2=A0repeated transmission failure; in DTLS, if no packages are lost)<= /div>

Should that be =E2=80=9C= packets=E2=80=9D?

=C2=A0= =C2=A0In those situations, no message has any Request-Tag option set, and<= /div>
=C2=A0 =C2=A0that can be recycled indefinitely.

I don=E2=80=99t understand w= hat is being =E2=80=9Crecycled=E2=80=9D if you=E2=80=99re not using he Requ= est-Tag option (also applies to the subsequent sentence).

=E2=80=94=C2=A0
Ba= rry

--000000000000c6ba3a05ac04af80-- From nobody Tue Aug 4 00:33:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980313A0F6A for ; Tue, 4 Aug 2020 00:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 xzNuEAuENqbo for ; Tue, 4 Aug 2020 00:33:32 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE0C3A0F61 for ; Tue, 4 Aug 2020 00:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1596526411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7FuwX4HN+6Cw9CdRiqrY9Mf6N0MIuwwirkD1M8jmwiM=; b=S14efWeGWLoqaGpwWz/biBQplMT9TTMrclGfM+gCVTR+k5vmnx7Y/hSBt39Sjm9BnCtizi te7epoplPPQNhfT6/9SJjdbC4noZU+KdjYoKpj54tFtw0qxVdfxLYnBG+cn6mpwPfMKSAP OfX/St4dsC3Zq4z4q7PqQ8rMarkdV7I= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2175.outbound.protection.outlook.com [104.47.58.175]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-256-15c1BX0hNSOpsVPd3ZS7Ww-1; Tue, 04 Aug 2020 03:33:29 -0400 X-MC-Unique: 15c1BX0hNSOpsVPd3ZS7Ww-1 Received: from BYAPR16MB2695.namprd16.prod.outlook.com (2603:10b6:a03:ea::14) by BY5PR16MB3125.namprd16.prod.outlook.com (2603:10b6:a03:186::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Tue, 4 Aug 2020 07:33:25 +0000 Received: from BYAPR16MB2695.namprd16.prod.outlook.com ([fe80::683a:57c7:bafe:9811]) by BYAPR16MB2695.namprd16.prod.outlook.com ([fe80::683a:57c7:bafe:9811%7]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 07:33:25 +0000 From: "Konda, Tirumaleswar Reddy" To: "supjps-ietf@jpshallow.com" , =?utf-8?B?J0phaW1lIEppbcOpbmV6Jw==?= , "core@ietf.org" , "mohamed.boucadair@orange.com" CC: "draft-bosh-core-new-block@ietf.org" Thread-Topic: [core] WGA call on draft-bosh-core-new-block-04 Thread-Index: AQHWZc6FGBjjguT73UKvHMqgUR48i6kfsW8AgAAfIYCAB8ZasA== Date: Tue, 4 Aug 2020 07:33:25 +0000 Message-ID: References: <7388_1596092178_5F226F12_7388_217_1_787AE7BB302AE849A7480A190F8B933031508D60@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <321601d6664e$16f97de0$44ec79a0$@jpshallow.com> In-Reply-To: <321601d6664e$16f97de0$44ec79a0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action x-originating-ip: [49.37.200.126] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 282c46ac-b038-4666-9496-08d83848ac62 x-ms-traffictypediagnostic: BY5PR16MB3125: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6sZoxeKmcuD1nENUNv/JQjtKInRv/G2cIa1OtIwjlUPlkjJxPSoEk/6H4DtJgwEG1xNSuvyhFnrYK599MPPZyXJu2YG/PkVN1WgNi7yovktJDwMYfO6p/sZxQxiC12jFuF6bwULwmcihQIWAxLoflI1IADhT8eAgK5+sJ57GsSm63yNMGIFKaXQfSPSXKXfb/pvApm3PDsdXLgSjvYpmPv1xaQ6KYZwBqUnBE7qh/WaCkO27y3tN7qEmeO9DKi7aKu8jP2VmME5LFrkhmZXlk1AY/8sHEeB60n84lrOjSsdU7PO0k/Q1vDPEZfVYYzq3UWCr/KKZbS9NFL3jsaChU2OErANUOWWhIS+upZTU2iGupMKmeQIIQdX+KNe5FhLviH/HCaCkW1ZaBaJUo1Vcog7O7/lnQFlTlx86Kb6WHxieI6gAkzi2Rd9vqNH+D+TZYgzWzA7AA+C/LHTVR783ofKzUGX3BqIstIyOiKU/91o= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR16MB2695.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(136003)(346002)(366004)(396003)(32952001)(66574015)(8676002)(316002)(83380400001)(33656002)(7696005)(4326008)(110136005)(2906002)(53546011)(26005)(66946007)(66446008)(64756008)(5660300002)(186003)(9686003)(66556008)(86362001)(76116006)(55016002)(71200400001)(966005)(52536014)(6506007)(8936002)(478600001)(66476007)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: G6j3m/+YPLuESxaMNARa1IRsV7LOfY+sRBeVfsxflkUx0tbGZBTRCilj2p46yiqcaji6yB+yPgLkCUnvonpMz4ayynk2kbvPbYreqhrkU2vyMIzdj99ckjEgdo9kzpjcUhip+x1oz/Rvu4P7OwbRHlnP5R1vOgFTgovjNjsJXGQkee9P/fKclGuXj6lZflXPWGWa+Djz3TY3QlxCRwjTb84q1bJE9Q6S+/rwXKgXe8eioOlOiBZVLNkEfN1RHj83g10+1/XmCxCvuW0sS1nA9oIRAWlkkOsLrJ/6HozCtgRycFHFI+GtE3RCcfcypAKU8XKN8ckFzUMxflSph/pmM8ARx+dLxdMTVUSMnUDK++nx1MyM6Egj34GOj/pjzzkbM0RjBCkB7vSX9cbvuKoM2sOthmQGa958dDLHEN+CHUoD+uEvKqD5r/vnn+7ZMbAwh1c5u8jAixPRojPJkAI30ldJGeC+IyOhy+6X73TVRaB7yvfdPwt06VGNA4L2mo60I5ve+DLozq/WvXJ6An3CPfAQmU0DwPk61N5Dm1Yxh+NK039sEMhM2/zx+fKey80rk08n6stRft/3ePjk5eQ8X4JMXXqmnqs8umBDDEIWdNVBhTVRHrgRNKWmG/5WJZawhkeNaUgaYB21he+sWQwYOg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR16MB2695.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 282c46ac-b038-4666-9496-08d83848ac62 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 07:33:25.3098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oEaznYfRsYnQpjOZmhzRTfwrA2qYHR1joxukVAhos+DPQ6K2z/Bp4DjQmHVWoKTMCPEixb6P/17Bq8lyHh4u2CngZt64SKytUrG7ga9rtYkJzjnkCxnml77xobKUCFtX X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR16MB3125 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [core] WGA call on draft-bosh-core-new-block-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: Tue, 04 Aug 2020 07:33:35 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4gDQoNCi1UaXJ1DQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2Ygc3VwanBzLQ0KPiBpZXRmQGpwc2hhbGxvdy5jb20NCj4gU2VudDogVGh1cnNk YXksIEp1bHkgMzAsIDIwMjAgMjoxOCBQTQ0KPiBUbzogJ0phaW1lIEppbcOpbmV6JyA8amFpbWVA aWtpLmZpPjsgY29yZUBpZXRmLm9yZzsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0K PiBDYzogZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W2NvcmVdIFdHQSBjYWxsIG9uIGRyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDQNCj4gDQo+IENB VVRJT046IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2ht ZW50cyB1bmxlc3MgeW91DQo+IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250 ZW50IGlzIHNhZmUuDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBJIGxpa2V3aXNlIHN1cHBvcnQgdGhp cyBkcmFmdC4NCj4gDQo+IEkgdG9vIGRvIG5vdCBoYXZlIGFueSBJUFIgcmVsYXRlZCB0byB0aGlz IGRyYWZ0Lg0KPiANCj4gUmVnYXJkcw0KPiANCj4gSm9uDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gPiBTZW50OiAzMCBKdWx5 IDIwMjAgMDc6NTYNCj4gPiBUbzogSmFpbWUgSmltw6luZXo7IGNvcmVAaWV0Zi5vcmcNCj4gPiBD YzogZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBb Y29yZV0gV0dBIGNhbGwgb24gZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jay0wNA0KPiA+DQo+ID4g SGkgSmFpbWUsIGFsbCwNCj4gPg0KPiA+IEkgc3VwcG9ydCB0aGlzIGRyYWZ0LCBvYnZpb3VzbHku DQo+ID4NCj4gPiBGV0lXLCBJIGRvbid0IGhhdmUgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJh ZnQuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPiA+ID4gRGUgOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIEphaW1lIEppbcOpbmV6DQo+ID4gPiBFbnZvecOpIDogbWVyY3Jl ZGkgMjkganVpbGxldCAyMDIwIDE5OjM0IMOAIDogY29yZUBpZXRmLm9yZyBPYmpldCA6DQo+ID4g PiBbY29yZV0gV0dBIGNhbGwgb24gZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jay0wNA0KPiA+ID4N Cj4gPiA+IERlYXIgQ29yZSBXRywNCj4gPiA+DQo+ID4gPiBXZSB3b3VsZCBsaWtlIHRvIHN0YXJ0 IHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvbg0KPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDQNCj4gPiA+DQo+ID4gPiBBcyB5b3Uga25v dyB0aGUgZHJhZnQgcHJvdmlkZXMgdHdvIG5ldyBibG9jayBvcHRpb25zICgzIGFuZCA0KSBmb3IN Cj4gPiA+IGJsb2Nrd2lzZSB0cmFuc2ZlcnMuIFRoZSBvcHRpb25zIGNvbWUgZnJvbSByZXF1aXJl bWVudHMgZ2F0aGVyZWQgYnkNCj4gPiA+IHRoZSBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAo RE9UUykgV0cuIFRoZSBkcmFmdCBoYXMgYmVlbg0KPiA+ID4gcHJlc2VudGVkIGFuZCBkaXNjdXNz ZWQgb24gZmV3IGludGVyaW1zIGFuZCB3ZSBoYXZlIGhhZCBhDQo+ID4gPiBwcmVzZW50YXRpb24g YW5kIGEgdmlydHVhbCBodW0gdGhhdCByZXN1bHRlZCBpbiDigJxwaWFub+KAnSBkdXJpbmcgeWVz dGVyZGF54oCZcw0KPiBDb1JFIHNlc3Npb24uDQo+ID4gPg0KPiA+ID4gQ29uc2lkZXJpbmcgdGhh dCBpdCBoYXMgYWxyZWFkeSBncm91cCBzdXBwb3J0IHRoZSBjaGFpcnMgd291bGQgbGlrZQ0KPiA+ ID4gdG8gY29uZmlybSB0aGUgZHJhZnQgYWRvcHRpb24gaW4gdGhlIGxpc3QuIFRoZSBjYWxsIHdp bGwgbGFzdCB0d28NCj4gPiA+IHdlZWtzIHVudGlsIHRoZSAxMnRoIG9mIEF1Z3VzdC4NCj4gPiA+ DQo+ID4gPiBUaGFua3MhDQo+ID4gPiAtLQ0KPiA+ID4gSmFpbWUgSmltw6luZXoNCj4gPiA+DQo+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4gY29yZSBtYWlsaW5nIGxpc3QNCj4gPiA+IGNvcmVAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiA+DQo+ID4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19f X19fX18NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPg0KPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPiA+IGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UNCj4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0KPiA+IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcw0KPiA+IGQnYWx0ZXJhdGlv biwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZQ0KPiA+IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4NCj4gPiBUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IN Cj4gPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 IHRoZXkgc2hvdWxkIG5vdA0KPiA+IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPiA+IGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4gPiBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiBUaGFuayB5b3UuDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBt YWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg0K From nobody Tue Aug 4 01:09:08 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB93A0C20 for ; Tue, 4 Aug 2020 01:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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 QeUPW-ehvZB4 for ; Tue, 4 Aug 2020 01:09:00 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8577C3A0C18 for ; Tue, 4 Aug 2020 01:09:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bkUTuPUdd841Y4Df13oOHPZiFoQzePfbDHtYDFsmZRh0HRzXiB7AP2QtnARNEbzU7XNcNp7soJTrVKNt95i8oM80SXoRJ67mAgZ/TNVedgkiKQzyuqHwm10pvEHKNYFKdJYnP9qmf1PlhAgOt9vnaHGeR7HH9kVzvFi74UHbGMZXJCKodE4pSPUTXqRCyDe86Go0xTVc49ESLWdcUNNaFab1NtQk+f70/YROvhxnMOMC2GRlHSxhCI3nr9Fxp1YvK1Yd5u4N7U12kd2Jj9seHwQKg4PauWxTj4Zl85XKv7Exdkt7dl6M+NietzZ187hjiCXeOw4X7eLcZ4/qKFMW2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3GpoE1eVeassuf9pOthhnf7DFLsVhhOvF1EcVR+6zK0=; b=hlSEjZ4RAhosO8wTwxgzIRRuMXdtQPe5ezG67GTvG6l02eyOkt4h8jIs+A6LWw8FNVox0xjV2j64KaW9f0fVi+lIHbEG2m/FUMNMpCOaz+D67n4KySJ75LSeLctYCxygj4I2n8QPTQySEMA2XMRz9l1S8Xp0HhJvRrGApJBu9VYLK+JCssgsN4lK6VifqEbwXZ6KFNuYDEn/F73JuarO6ncnD6CpVak4nNvdue7xUcUNCmk/RgLg21zbA3zJEKKdhsCwsndmOzLpH7l9KcznCu+nQAJLAKVC8gYF7ZE5e6XWrSBL4CssoaJh1/rBn0YrDnx5QJwoh1U1ETJQffjNKw== 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=3GpoE1eVeassuf9pOthhnf7DFLsVhhOvF1EcVR+6zK0=; b=ZtgwVPbtWemlK/81KGHXGtD7i/5RULcNyJkeVPitTuxW34xOXJHjLBwvpwdykcIkqsLfNn6kXiG0haYflM2mRwAqFheuHuiKf8MYwFXt6fwKmd9js2JIsfiYoYgEFyhKzYRrJB5GjhoYeAKpF128aLYUSKMOXuC0ccezALqxS7c= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P18901MB0095.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:10::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.19; Tue, 4 Aug 2020 08:08:57 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 08:08:57 +0000 To: Jim Schaad , =?UTF-8?Q?=27Christian_Ams=c3=bcss=27?= , 'Francesca Palombini' Cc: core@ietf.org References: <04a301d66839$83672d50$8a3587f0$@augustcellars.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <29181983-83ab-e7fa-0049-5b11df700a55@ri.se> Date: Tue, 4 Aug 2020 10:08:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <04a301d66839$83672d50$8a3587f0$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KrV6oh1aYKstRxxpi0P0Hzya2mXzZwlXE" X-ClientProxiedBy: HE1PR0202CA0044.eurprd02.prod.outlook.com (2603:10a6:3:e4::30) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.8] (45.83.91.212) by HE1PR0202CA0044.eurprd02.prod.outlook.com (2603:10a6:3:e4::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Tue, 4 Aug 2020 08:08:57 +0000 X-Originating-IP: [45.83.91.212] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b1bf4aca-a303-40a0-9b7b-08d8384da342 X-MS-TrafficTypeDiagnostic: VI1P18901MB0095: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jgkwRqLcQzGTC24aAviJxMmn7bUQ96MlTRJCuyQ0EznhmiTwSY+7OXW8Le9Lc74vh2YOsn6CYz7VNp7BsMqjF7PGI0PyJf2dninXoFBd9o3UnD3M6ukeoxR0TzFkO4z3m+yVHpizEN86l9QRAheddcah845onr9QIQeR144fut/RQ/XwX4qdtsBZpaeQw3dM1uAQiSOcgk9RCjRbG1UO5G0/qfrH5TdUBlX7JyTedvfoqhr3uoMM/2AT69ODrvEZSNiRNgrcuf+acb66xX6OdDcLD9LzXzxtVxO1q9MMAODCG/80ocZDb3nUZ2LWN/rTXTVf6oY/gnIoBTiJw54kV/9uJbMck780n/lhvp7+beNna7v6tUWPWvVLz8qBB5rax4YaMqVLODnfLXX1bH4qdvHV63X9ioCRFHMWcBSJYoxnCF6zweLA3WxZSeBdLRuJC4ZXrmrMlwGVQdeRLkO9qA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(39850400004)(376002)(396003)(136003)(36756003)(52116002)(26005)(5660300002)(66476007)(16576012)(44832011)(31686004)(2906002)(33964004)(186003)(53546011)(2616005)(16526019)(21480400003)(956004)(110136005)(83380400001)(478600001)(66574015)(31696002)(966005)(66556008)(66946007)(86362001)(6666004)(8676002)(8936002)(316002)(235185007)(4326008)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: FXHKj4ept92EA/SFHAh1tMfoTqN6ZFAovEmy6/R9n2L+wOWrArR9c/jmAPNnHrPWSFPVgtTrN6AcTG8P0ID+0E6Qx8wIsOYosdXqgRl/4ttPoQBr1bojAuon5dpZqwF7M76MFxFwvLuyplC9la3qnhonwfH8F6kcJnLYJq42qRIcIkSF8U2Lomdx1NVv4HXN8/zY9B1532JZppEKoMYe3hTm+VHaLEimSQ1Vo0W4R8xEb8xM+viyQnvkbEAn5ueRB+1pa1E6qj2fOThh24LpcZiWl74BaaGnm/L+c8OdGdqWrEYLitrsL9uFWjyq1w0lSWTPueOhpCSzZAiuSqMRfZb1lS5B/bhwJEKvXjKt77OfkMkEqVUkx4tCkbZXdzYqrNkrdXzWmAW9zgeaWMXwM3uw7d1pXP2FtQej4zjkCkuTVhF6cdPRGddk1kQC8w0NRlc2hYjAAHe+7h+itYlGvX7xGZySt/7r3zpLUPllFqFi/YjHylEMjxIu/9TK2/bVNyncy1cQf15gt3XNZcrHUOYXED+LrMf/sTJCo1AIt7JttzOXEkZ+6yNS7h62fONFO5eVL0ZXaTQWzFBBsWu5ToUVXCA9P+XaVTBht2KPlcU5H3ZoP9S+KO/AC0/lFCCrS0JXrP4O6UVHpNqI/jlUzQ== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: b1bf4aca-a303-40a0-9b7b-08d8384da342 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2020 08:08:57.7162 (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: KhhGrJDd3MY2Bw/zVCiPVN8WHjHDItfXjFZzhNBiDwLPITE6cGxMQxZWdvfRmRLVu0G+xOgkGxeKCCzrOhzFNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0095 Archived-At: Subject: Re: [core] Missing must in the Group OSCORE document 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, 04 Aug 2020 08:09:05 -0000 --KrV6oh1aYKstRxxpi0P0Hzya2mXzZwlXE Content-Type: multipart/mixed; boundary="SzaRlNdAtLGo5OcTE2j3S1c8ktrhJdkPj" --SzaRlNdAtLGo5OcTE2j3S1c8ktrhJdkPj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, On 2020-08-01 21:25, Jim Schaad wrote: > Christian, > > I have been thinking about the problem case of having a duplicate IV r= euse > in the case where I suggested that we use separate IV spaces for the gr= oup > and pairwise keying materials. I agree that this is a problem, however= the > problem is greater than what you outlined. This is going to be a situa= tion > that will arise anytime that the request comes in under one security co= ntext > and the response goes out under a different security context. In this > situation you will always have the problem that a reflected IV value fr= om > context 1 will lead to a potential IV reuse in context 2. > > Missing requirement in the document: > > A server MUST use a PIV value from it's own sender context when ever it= > would normally use a reflected IV, but the security context for the req= uest > and response are not the same. =3D=3D>MT I guess here "different security context" means "different protection mode" - hence different PIV space - regardless a possible group rekeying happening. Correct? This seems to confirm the issue (1) raised in slide 9 of [1]. So this MUST-requirement would be needed if the two different PIV spaces are introduced. Just to clarify, do you think that the requirement is needed also in the current document with only one PIV space? Thanks, /Marco [1] https://www.ietf.org/proceedings/108/slides/slides-108-core-sessa-group-o= score-00 <=3D=3D > > Jim > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --SzaRlNdAtLGo5OcTE2j3S1c8ktrhJdkPj-- --KrV6oh1aYKstRxxpi0P0Hzya2mXzZwlXE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8pF40ACgkQ7iZktA5Y 2kOOdAf/TdjPtViyrmwHdFqn4fgUdOFgxdtleI3Mp4WnaWqbAe64PSTlmpG9Z1K5 jlFUVtHoK1wdXuOkxnhcPze7q23WKB7xLidVS+7k9V9D+3EKdhQMRMmRO7omTaW9 /8mkTivH9mhbxO/Gw3PLlOGdNu5biXnCqeMGxauiKf0GX+QS1Wy63wJ2Mcvf99wD W4nOq7UjW7GNJgyM7W8zXOH9H46tO6LsVJ4LIF1yjRz8ineYnStv3JxGe7uDvORG Nq+BQvNn7ZBw+oLElBdHobDDNxFroZ2GyCVmmeiO09XW+tLQyAU6fjaZbftBKtcS h4Acz+niLEZdhtHzhg7uGT2PLts4Mg== =z7wC -----END PGP SIGNATURE----- --KrV6oh1aYKstRxxpi0P0Hzya2mXzZwlXE-- From nobody Tue Aug 4 06:13:22 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77B83A0B35 for ; Tue, 4 Aug 2020 06:13:20 -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 59V82ZCNHtjR for ; Tue, 4 Aug 2020 06:13:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F213A0B4A for ; Tue, 4 Aug 2020 06:13:12 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Aug 2020 06:13:06 -0700 From: Jim Schaad To: 'Marco Tiloca' , =?utf-8?Q?'Christian_Ams=C3=BCss'?= , 'Francesca Palombini' CC: References: <04a301d66839$83672d50$8a3587f0$@augustcellars.com> <29181983-83ab-e7fa-0049-5b11df700a55@ri.se> In-Reply-To: <29181983-83ab-e7fa-0049-5b11df700a55@ri.se> Date: Tue, 4 Aug 2020 06:13:04 -0700 Message-ID: <058601d66a60$feceaad0$fc6c0070$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFcnDjahiYL9g6XE81eEKx67w39RwG/NgnPqg2PmhA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Missing must in the Group OSCORE document 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, 04 Aug 2020 13:13:21 -0000 -----Original Message----- From: Marco Tiloca =20 Sent: Tuesday, August 4, 2020 1:09 AM To: Jim Schaad ; 'Christian Ams=C3=BCss' = ; 'Francesca Palombini' = Cc: core@ietf.org Subject: Re: Missing must in the Group OSCORE document Hi Jim, On 2020-08-01 21:25, Jim Schaad wrote: > Christian, > > I have been thinking about the problem case of having a duplicate IV=20 > reuse in the case where I suggested that we use separate IV spaces for = > the group and pairwise keying materials. I agree that this is a=20 > problem, however the problem is greater than what you outlined. This=20 > is going to be a situation that will arise anytime that the request=20 > comes in under one security context and the response goes out under a=20 > different security context. In this situation you will always have=20 > the problem that a reflected IV value from context 1 will lead to a = potential IV reuse in context 2. > > Missing requirement in the document: > > A server MUST use a PIV value from it's own sender context when ever=20 > it would normally use a reflected IV, but the security context for the = > request and response are not the same. =3D=3D>MT I guess here "different security context" means "different protection = mode" - hence different PIV space - regardless a possible group rekeying = happening. Correct? This seems to confirm the issue (1) raised in slide 9 of [1]. So this = MUST-requirement would be needed if the two different PIV spaces are = introduced. Just to clarify, do you think that the requirement is needed also in the = current document with only one PIV space? [JLS] Yes this is needed in the current document even with only one PIV = space because doing a rekey between the request and the response has = this problem. Jim Thanks, /Marco [1] https://www.ietf.org/proceedings/108/slides/slides-108-core-sessa-group-o= score-00 <=3D=3D > > Jim > > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se From nobody Tue Aug 4 10:07:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC523A0D60 for ; Tue, 4 Aug 2020 10:07:52 -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 y0TeyRNDOE_J for ; Tue, 4 Aug 2020 10:07:49 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70073.outbound.protection.outlook.com [40.107.7.73]) (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 362093A0D56 for ; Tue, 4 Aug 2020 10:07:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ntmNJN5hl7wKv1gRAgOHfh4RB6Khb2NQZYvZqCj/djwnXm46jVuAA9zUGX7i0JwWFXgh4d3IYkdi3XWnIO/NqCJr6oC0/+fEitppoctJI1rS1cwEL65+bUC0OpxeaeZ5U2Iymc4Wxf7tqBSdEYXTGV7nkwP9bOSVb0pLF1LpFfDp2tqrSmY23tHC01g4YrgSapYV+a8u30FhzGoGko9Le3XpB9M79b+qNyus6Luv2aLV4k6mwGcj2TtX54CWQZ1xhkcdgl7TKlh0yaW8SHiSugE7aYFlPaohf2iKUu2ORpIR0/d7qRPm1zZpMDNkjBATsokBlaWiavLLOo50VHUpxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DFN/duWwi9V1apQcj0l8ZPsiJ9j/j3yCS/dSKS1eBJc=; b=nhnoIjGeqKBkH30dMUAvbHBUwyRz3He6GIGQKz/CUOO6NLPRYSi5dBGKSl9YvTDrS+OG7CgVn3Q6fziQSNyHe58LeLiyBkl0Dqz99J1+pt/+lE1ABqKWGgdRsTK5Qg9aDWCIa7qIX/c3HuW1A5yStQz2wgDMwC99HYROlpDhp1MhPsYuR8flDQsbKFLaKVD88e8AAO47vqAvoDLZNB0aO5aIrUZKnPOkCz1CzE+0BgH7anWUpWtB92oxLOtmmAaSIKazqo9x+Fa5OgjviznM4WSoUgG0pZR/K1PP2ZlHpJBvNyr7pahH/capxfJ5MiFaTNfBAEvmh/SVTUilyERxQg== 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=DFN/duWwi9V1apQcj0l8ZPsiJ9j/j3yCS/dSKS1eBJc=; b=g5WlGNvC4F2nH3J2RhTYZ/amUvyRe5lhhuk926lhwJiXR2Yo9y8K3c0tAHFliWb89jdabTZGQid7VfIa6W54T3SqEu86BEv2FFgbC27suwp5LWCVYGxWpS9m/9QTmVdiua675JEfLBvqvQoYeZLszbNDa1wJLsmw8w91K2Z8RcA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0464.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:38::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Tue, 4 Aug 2020 17:07:41 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 17:07:41 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Tue, 4 Aug 2020 19:07:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FDyhvi0yOFvh1ROnSOe40p5e5OaJRR5vu" X-ClientProxiedBy: HE1PR02CA0088.eurprd02.prod.outlook.com (2603:10a6:7:29::17) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.8] (45.83.91.212) by HE1PR02CA0088.eurprd02.prod.outlook.com (2603:10a6:7:29::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Tue, 4 Aug 2020 17:07:41 +0000 X-Originating-IP: [45.83.91.212] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7f4eb1f0-d354-4bf8-b7c6-08d83898e5b0 X-MS-TrafficTypeDiagnostic: VI1P189MB0464: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qtbK6szEDnbbfUQ7yAa4gZq6oEnHDijbzCTGUKyMoBv3zziXawkw5+HvjQB1+MqFXvJDKYnLr1qr4pTnl8LI+1jyjkMuRY2oBMJWVvfeYkANfY3rYmgXPOIH4yCfokcAG/fj+e5A8a1fiPcM098tx4hX436EKaLRpVF0HRZ7PZ8FgyLbzbzoZgFc4ApWm/IhKePpS1/E81N6WYnZFVLGNBPrMGZzUTL2/4Pk7q3hrdl57rc+c13CaX8TnZdJ6WcQZAWbEDL4ws7fepHo//hV+MrdVI/lahPHTU19BQ1OniAsUCwBdN1zDF/WkcNX0YeVrg3wNDqmbYeO4QpC8jNbZKN9UCA598h7Gvd7po/pFAWfSSWezq/3p9vVpH0Y1JuvbDUGdsZPrzFP0g3WQtTc2rc2TACmbINL5xC0E+9AwLNwwk6SJ8vzWfxIkCxzkr+hgMwxqr498se/7Qwk0aZ9HA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(346002)(39850400004)(376002)(44832011)(83380400001)(186003)(16526019)(26005)(2906002)(956004)(31686004)(2616005)(6916009)(235185007)(5660300002)(21480400003)(66946007)(31696002)(6486002)(8676002)(6666004)(66556008)(66476007)(478600001)(36756003)(16576012)(966005)(86362001)(316002)(8936002)(33964004)(52116002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: mzh8iJqunP44W9Ylaw+28eapLLcf7uSZnkJLpE5qASxV95FVSkFsq4968fruSXB/+jtxPuPtKCql0+jsFEk336JulNQ34j+6ufkma6bcbsOgHJWPY9wbRAS4tKchjCoSqBu0IQOiiISZZEZe/SQk6V4/9QM7inz80c3swRbpN4luyF5LqX7Ejq8VmNYl0hWDLsKCFzPPF9Mj39UIevFt4P27A7QgEYEPxl1gNQTI7nqONRaRpjJpLKbowytpLYxpkQH1LDaKj0eAEcQWHeohwfc1m/jCuftchTGQP3KE+83nI5mMD4HNYxNAzqJeU1DFog1Ox2l6b8qm4HNNLcpiBAyMtKZngmTwFvFXtzQCtGuRt7s0WU01VhxNjvHXcjHk6JQ2njK+GlnTzHOVZsQ62v0hLgLNL9JKP8CEOq9kdIeOyHJZ6wJ6LSec6OvtcUksxPSiVEysYJwvmHFfl054ybWGGxzvqeBAXVkzMfVBrxGXdhyqyKFObzKfpvj/9cY+Lnzv2XNQ7O1omLZkVeMad0EsKiJZUZrHbWmP9l0RN8Tz94syK3WcUjzSYe+hmGr55RQnLFpYcivMEca2ieNBeLsCowCW0AgNZWCIM/7oAuPywaXIK6Y9FCjYdBCoLC0GQHAporkQia0WlRz2POcQrg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 7f4eb1f0-d354-4bf8-b7c6-08d83898e5b0 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2020 17:07:41.3882 (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: qOIPqp+slnMcpewbsoawuoR6QwHHB3mneLoSSiZuc0sLRB/I9xafV1z2ptmaAazEK/72K1SPuZbTlT21WqRv3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0464 Archived-At: Subject: [core] CoRE interim meetings 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, 04 Aug 2020 17:07:52 -0000 --FDyhvi0yOFvh1ROnSOe40p5e5OaJRR5vu Content-Type: multipart/mixed; boundary="th9pOMr5L15qshwIRZ1ecqQsB4JHcEk96" --th9pOMr5L15qshwIRZ1ecqQsB4JHcEk96 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, We are planning to schedule regular virtual interim meetings, recurring every other week, starting from the second week of September and until the end of October. Please, cast your preferences at the Doodle poll below, by the 20th of August EOB. https://doodle.com/poll/cb9qshfymw6tdgna The options in the Doodle refer to the week of the first interim meeting. The following meetings will occur every other week on the same weekday and time, until the end of October. Best, Marco and Jaime --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --th9pOMr5L15qshwIRZ1ecqQsB4JHcEk96-- --FDyhvi0yOFvh1ROnSOe40p5e5OaJRR5vu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8pldIACgkQ7iZktA5Y 2kO1cgf/Zqcy3SFqXWCoUFMf/z5mw3fRw5PUS1lVxz4Sizc8XxeBaD5lVM4biHIq 3EO9uYB20tWMCRqG1uHW1KeAeqhMifygDhEixdLhVBTiJr/r8ThG9oPZCQHpHvU8 8N7UnkL0Ag+KLTFY+S2/0jUbo6nxlInxJ93vulINPs5Tvkc2PqPWFn4ukyEQtmxp Jp9K7lZqGz1GMjIycGcXTw3fHCofvOJU8Q1YSXKn8ztDSCpOTOea/9Bx++iOVKhT F98lAbKC3IxaKYTKrWav6lLzuEHZYU+L8G8LhbmGm7sxGnYNd9CUbUSStFhlBAt6 olAXP9pcLLj6qBWemXZLSObrAwxCEw== =10ov -----END PGP SIGNATURE----- --FDyhvi0yOFvh1ROnSOe40p5e5OaJRR5vu-- From nobody Wed Aug 5 00:33:07 2020 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 CC9BA3A136F; Wed, 5 Aug 2020 00:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com, otroan@employees.org, bob.hinden@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159661278180.30518.10421410106159995546@ietfa.amsl.com> Date: Wed, 05 Aug 2020 00:33:01 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-resource-directory-25=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 07:33:02 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-resource-directory-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. I am little puzzled by the document shepherd's write-up dated more than one year ago (the responsible AD has even changed and the change is not reflected in the write-up)... while well-written this write-up seems to indicate neither a large consensus nor a deep interest by the CORE WG community. But, I am trusting the past and current responsible ADs on this aspect. Did the authors check with 6MAN WG about the new RDAO option for IPv6 NDP ? I was unable to find any 6MAN email related to this new NDP option and, after checking with the 6MAN WG chairs, they also do not remember any discussion. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs) and 2 blocking DISCUSS points (but only trivial actions/fixes are required). I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD). -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives. -- Section 2 -- To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ? -- Section 3.3 -- Should the lifetime be specified in seconds at first use in the text? -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later. Please expand and add reference for 6LBR. Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5. -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D). Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ? Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ? As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ? -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options). -- Section 5 -- May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses. -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781. == NITS == -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only. From nobody Wed Aug 5 02:52:20 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E43A13CE for ; Wed, 5 Aug 2020 02:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qp34vO3qisLE for ; Wed, 5 Aug 2020 02:52:16 -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 54C6B3A0C9C for ; Wed, 5 Aug 2020 02:52:15 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8069640760; Wed, 5 Aug 2020 11:52:12 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 548F6AB; Wed, 5 Aug 2020 11:52:11 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:947b:e942:281b:482c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 712A6180; Wed, 5 Aug 2020 11:52:10 +0200 (CEST) Received: (nullmailer pid 3470819 invoked by uid 1000); Wed, 05 Aug 2020 09:52:10 -0000 Date: Wed, 5 Aug 2020 11:52:10 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-groves-coap-webrtcdc@ietf.org, core@ietf.org Message-ID: <20200805095210.GA3251625@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline Archived-At: Subject: [core] CoAP-over-WebRTC: Continued interest and use case 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, 05 Aug 2020 09:52:19 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello coap-webrtcdc authors, hello CoRE group, I think that in addition to the described use cases, CoAP-over-WebRTC can become relevant as a bridging tool for local environments where browser policies make the use of CoAP-over-WS impractical: Browsers are unwillingn to open unsecured CoAP-over-WS connections from HTTPS secured sites. Yet, web applications to control local devices will want to ship via HTTPS to get access to all of the browser's functionality and for general safety reasons. Until someone comes up with[1] and browsers adopt[2] a way to get valid HTTPS certificates for devices without an Internet uplink (or at least without any practical way of regularly obtaining valid PKI certificates), that means that a local gateway (say, something opening a WiFi access point without Internet connectivity, or a local router) is unreachable using CoAP-over-WS from a shipped application. CoAP-over-WebRTC between the browser and the gateway device should, as far as I can tell, be an option there, as the required DTLS session does not rely on PKI certificates but just on out-of-band exchanged fingerprints, which could be transported over XMLHttpRequests to an HTTP server. (That sounds terribly insecure, but a) those exchanges can be OSCORE-protected, and b) it's not like the proxy will be in any way trusted). There has not been any activity around CoAP-over-WebRTC that I could see after the release of the 2017 -02 draft. Christian and Weiwei, are you interested in continuing it, or have any pointers in case I'd like to continue from there? Kind Regards Christian [1]: https://www.w3.org/community/httpslocal/ [2]: I don't have high hopes for the next years --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8qgT0ACgkQOY0REtOk veFGOg//cOng6CvBkKAcbyTajFVDeoReN7mKhHtmY08fEopSSsBUqpnfaPcHOcy/ 4HleCniYIC1hdIuZgfMBkv21IZ+qgvliPzBYvOwJsxF0TO0vms29faAjOWGi5STG tHUpJwevo77o1tmrWWyjqbYEO3Y9VB2HIt7mG37DVnY0jjuiwAtz2J/1p3mXygDe r43gkB8cXcTa8g9zPClFQx/TYJOICYF1PTaZV4O3LcWGRu2rl+zlFS6y8PL+uaLM 7bdtp/wA+ln8T5Vh1nmZ0t8yhYJZ5CcAqYOBkjPIwfwie9PI2zdZrPWX5tV85Q2B 2sntDprsvPx1XdWyCUXgDH8y9JIz3DMtStYEAdhmQkSB/Q5bOeRchSqwKKasI1u8 0j0roLDLljF8bNq9egjXtmJ55a3ViJyo9ZMIn0zY0K8D17I5N79sKR4vXbRRLdk7 mL6wTW9wUk7zSc/m9GPhVNbpcHXHN0IECbzRplX3dd9W5Eb1IVux7n2iR/H1RNBv GDIChYqfBGPrQsMKGlC8HqtJCUTO78Joo8KerhdLfoTPxPA7VS1PNeo+6Du1mlZ8 eAPNJCMA8uajIom17LQCDq5ffkZZwmfbpmk0fwY0GX2WebuG0UrWS9U2lpxSYjrT ep99e9PMP8JSQBpu+11pFN/DnXmfRYcrnK6sudQFN+mR4xD9xjI= =ookU -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From nobody Wed Aug 5 07:24:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728783A09E7 for ; Wed, 5 Aug 2020 07:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vhcI0Vu-dUeq for ; Wed, 5 Aug 2020 07:24:38 -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 61B403A09A2 for ; Wed, 5 Aug 2020 07:24:37 -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 33E4240760; Wed, 5 Aug 2020 16:24:35 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BA7C9AB; Wed, 5 Aug 2020 16:24:33 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:947b:e942:281b:482c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CCBF4180; Wed, 5 Aug 2020 16:24:32 +0200 (CEST) Received: (nullmailer pid 3494816 invoked by uid 1000); Wed, 05 Aug 2020 14:24:31 -0000 Date: Wed, 5 Aug 2020 16:24:31 +0200 From: christian@amsuess.com To: , "Jon Shallow (supjps-ietf@jpshallow.com)" , "core@ietf.org" Message-ID: <20200805142431.GB3480705@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:24:40 -0000 --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, hello Jon, here's a few concrete points I'd like to suggest for new-block: * Applicability: I'd have expected to read something like this in the introduction: > The block-wise transfer of [RFC7959] covers the general case, but > falls short in situations where packet loss is highly asymmetrical. > > The new options introduced here provide roughly similar features to > the Block1/Block2 options. They provide additional properties that > are tailored towards the intended use case, and leave out mechanisms > like non-atomic access and proxy support that would complicate their > description. > > They are not intended for general CoAP usage, and any use outside > the DOTS use case should be carefully weighed against the loss of > interoperability with generic CoAP applications. It is hoped that > experience gained with these options can go into future extensions > of the block-wise mechanism that are both generally applicable and > serve this particular use case. * Separation of layers, sub-topic "congestion control": It should be possible to phrase all congestion control parts of this in a dedicated section (which may also make sense as an appendix). I'd avoid all other mentions of things like PROBING_RATE: For example, Section 3.4 right in the middle of a paragraph on re-requesting missing blocks states that > The rate of requests for missing blocks is subject to PROBING_RATE. Yes it is, but so is every single CoAP request until the client hears back from the server. Repeating these things in places where are not a new requirement may make it easier for some implementers that try to build the whole stack in a single go, but even for them is prone to the authors missing a spot -- and for everyone else this will each time trigger the question of "is this new here or isn't this already handled by a component two layers down the stack?". I haven't tracked every single retransmission and rate limiting statement throughout the document, but I expect that this section could boil down to something like > For the DOTS use case, the following default CoAP parameters are > updated to better reflect the typical deployments: > > * PROBING_RATE: 10 kilobyte/second > > The averaging process mentioned in RFC7252 Section 4.7 after which > PROBING_RATE applies is not fully defined there. For the above > applications, a new parameter PROBING_RATE_WINDOW is introduced. > Messages up to a total size of PROBING_RATE_WINDOW may be sent > before PROBING_RATE is considered, and the probing rate may > generally be exceeded by that amount of data in short term. > > * PROBING_RATE_WINDOW: 15 kilobyte (The latter replaces MAX_PAYLOADS, and I'm not sure whether it is better to express this in terms of package count or bytes on the wire, just giving an example here. All numbers in the above were pulled out of uninformed air.) * Separation of layers, sub-topic "Tokens": Same thing, next layer. Whenever you're tempted to talk of a token, consider some of these replacement phrases as a first step: * "MUST be sent with a new token" -> "is a new request". * "Tokens MUST be included" -> (nothing -- transports use tokens by construction) * "MUST be sent with the same token as the response" -> "is sent as a response to" / "is sent as an additional response to that request". (Here it may make sense to refer to the tokens in an additional " (which means it uses the same token, the same way an observation response uses the requests's token for multiple responses)"). * Naming: It's technically a minor thing, but people have already complained to me about how hard the Block[12] names are to comprehend, and introducing these options as Block[34] would not help here. I'd like to suggest QuickBlock-Block[12]. (I know that this part of designing a new option is annoying. In the interest of winding up with something that can be learned easily, it is unfortunately essential). In connection with that, it may make sense to briefly think about a draft name before it is submitted as a WG draft. new-block sounds like a 7959bis, which in my understanding this does not aim to be. * 4.TBA3 Missing Payloads: I don't quite see why this needs a distinct code. 4.08 Request Entity Incomplete sounds perfectly suitable to me. If you think that sending an existing 4.xx code in the middle of a block-wise transfer would cancel the transfer, there's still two ways out of this: * You're just defining what a block-wise transfer is; just allow it. (In a RFC7959 block-wise transfer that runs over a proxy, the proxy may be currently incapable of doing any forwarding and return 5.03 Service Unavailable Max-Age:5. The client would then just pause 5 seconds and send the latest block again.) * For all but the last block, it may also be an option to send it as a payload to a 2.31 code -- I don't think that would be outright forbidden (and at any rate, all involved clients speak the protocol anyway). * The draft describes this all as "just working through a proxy" -- original block-wise does not, and I'd like to hear how this is hoping to get away without the options being proxy-unsafe. Is there any point at all in using block-by-block proxying for these use cases? Unless a proxy is sitting right inside the link under attack, and unless the bodies get huge, it may be way easier for this to be purely hop-by-hop. Proxies would reassemble the full bodies and, for the next hop, just decide what works best there (be it regular block-wise, Block34 or BERT). =20 (If there's a point in allowing block-by-block forwarding, we can talk it through and work through the initial ideas that will come up like "We use large enough Request-Tag values so they are unique", "how large does that need to be", "why do we end up having a Request-Tag in every request now" and "why do we not want that", but my gut feeling is we won't need to go there.) Kind regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8qwRsACgkQOY0REtOk veEfuQ/+LdRNkEpCCnDwdxNVU2uFyD2LQ2VzAr6mNekREMGsyx8LyLAyY62MuYHd m3DTYfFUPmvVXkD+KgdlNAGl9oKJkgUZGnhZVF4N06DSfIdjNY6gLtPyxvsFYjv3 +QypMGPqOhJC9Hr4Vandx+JPwZ079zrPvaElIjDOPe5CXKIjFZtUsWOWA6h/FvtU HTOHdDUqplceDlCZfYdIEd1wpyU+aH+/t5PGXDJkJ1cSMxy/axcP+h7efl3IZAdv t/Z6VGeZJywRvFdKg7ldU4aR8jQ6GYpou6jZihL1OsUAotNA/pu+Ry23SyBWyyxy IvhhV6YePEiD8OdhccerqlECvRlsVQjiUVnwS9ehf220fWnEKln9mJr5luZR3nlT xQFSPBzCvu1+2u0PrvIfEAjCRyo7+RimoF1jzfZ/tGrZETnzM77SXPAfIEk0Zgmm Ol6nB4tuvQO9IDLVnza2KF1W2p63vb3yHZxnHgym77uqbtz678Xsxf+G2Jy3cMUm fkD2KpLdtUoXhwdTr6VnaFYbAKKRgm9f0wmb0C+OU1adJMxbBUztHts03t0pVId3 QB3Ym7dtMidhcwiGUHqipzJRH4nipGC/zoCXhNoFuhF2IvUbRbi2HThgVHB36fPE Tv6sj4yTsa/61zLpG+E4AOGapKF67u1R7wdWqO5UmsMnOMnXF0o= =2z9b -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- From nobody Wed Aug 5 09:05:30 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D23A0C32 for ; Wed, 5 Aug 2020 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OMYMRHGF9FLZ for ; Wed, 5 Aug 2020 09:05:26 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F9F3A0C0B for ; Wed, 5 Aug 2020 09:05:25 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6F1C840760; Wed, 5 Aug 2020 18:05:22 +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 F27A2AB; Wed, 5 Aug 2020 18:05:20 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:947b:e942:281b:482c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6BF65180; Wed, 5 Aug 2020 18:05:20 +0200 (CEST) Received: (nullmailer pid 3502950 invoked by uid 1000); Wed, 05 Aug 2020 16:05:20 -0000 Date: Wed, 5 Aug 2020 18:05:20 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: Message-ID: <20200805160520.GA3470838@hephaistos.amsuess.com> References: <009501d6629a$509165c0$f1b43140$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <009501d6629a$509165c0$f1b43140$@augustcellars.com> Archived-At: Subject: Re: [core] Payloads and BLOCK2 for various methods 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, 05 Aug 2020 16:05:29 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, On Sat, Jul 25, 2020 at 08:43:14AM -0700, Jim Schaad wrote: > I was going through my code because I found a problem with one of my > blockwise implementations and I found that I did not know where the text = was > about sending payloads for NUM > 1 blocks. The only statement that I ha= ve > found on this seems to be in Figure 10 of RFC 7959. If it is elsewhere t= hen > I have missed it. The problem with this is a) it is an example rather th= an > a statement in the text and 2) it needs to be inferred that this applies = to > more than just POST. I relied on the same figure for my implementations, and on checking again found nothing to support the behavior either. (The best indication I found is the sentence in 2.7 that "To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM" -- without a Block1 option, there is no payload that makes sense there to send). > I also ended up looking at RFC 8132 and, to my surprise, I found that > blockwise is to be supported for FETCH, but there is no statement about > PATCH and iPATCH. Given the explicit statement for FETCH, it is my > assumption that PATCH and iPATCH are not to be used with blockwise. Does > that match what was intended? I'd assume that on PATCH and iPATCH it generally says less because they're already so close to PUT and POST that everything on block-wise with PUT and POST applies equally. Both would make good corr-clar material. KR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8q2LwACgkQOY0REtOk veFs+A/+Kk0RFYigjwVfBU5azTFd4XAHfg3UteDuHTVaAc8kw3xG6gKYEL5DBEg8 eiCvw/NRslYFC61b9eR1Sd0WUU1P9ksZN7UCDgXtXcEFnI8aP90yWZcUz5bVbpKH 5DczDwZbCs8g5a7qRzDjkYtUgUGaRoibRBwRrvlCQMsph7YVgNQEmiPtIkX7/qt1 eaT19cCVT2PE0/wp/YwTYLphnsZQBMaSOahKkt6+8Eccy6W4Nj+SXNLQ2LOW0ODF T0XVGduBBI4pkiv5zz6MvT07Z2M7Zq7p+jZvP7Y0YPu0AnyYHaEIOIrdM0vU2oJv QiWb/iN8NSZedAxQKDup2chP+cEHbyCOVYxmE2zu1jDfsmL2G0hyn52kycneGHWi eakQ3E0g/3+eSUohLSRQJzx/dVeWwVBwKsejrMNodGHFPFxV4+BA/fC6OuvbI4UX 1NDpBy4PADbsPi0AsVCzLPSFAmXWPBx+POrEpicHgSdznm0tlHZu1aNOcfO07EFd aJnVAdCsRvk+Rrgp1fYlb22l/srnw/PfoRyMEDNDz+p9GU3xA/vDp02X84QiDwAZ NbSc+Kp2F6Vn78rFgWEYgtWSjYOf52Fvw1Z4PEQN44PLgrqUOMhOTjp8rS5Easv4 dgb8qRjJRwewKoTiCCtuVHw1jHUjaCe+YcjJhHFzXWeguO3O7P4= =1F8p -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From nobody Wed Aug 5 09:51:43 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4439F3A0D27 for ; Wed, 5 Aug 2020 09:51:41 -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_H4=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 IfpFmnpYeaWW for ; Wed, 5 Aug 2020 09:51:40 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F7D3A0CFD for ; Wed, 5 Aug 2020 09:51:39 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BMHhV1FFWzyyw; Wed, 5 Aug 2020 18:51:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <20200805160520.GA3470838@hephaistos.amsuess.com> Date: Wed, 5 Aug 2020 18:51:37 +0200 Cc: Jim Schaad , core@ietf.org X-Mao-Original-Outgoing-Id: 618339097.452976-5b0774ee99f12fdad31a187937a78ba7 Content-Transfer-Encoding: quoted-printable Message-Id: <8E84C05E-B305-4726-BA9C-FDAE0687619E@tzi.org> References: <009501d6629a$509165c0$f1b43140$@augustcellars.com> <20200805160520.GA3470838@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] Payloads and BLOCK2 for various methods 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, 05 Aug 2020 16:51:41 -0000 On 2020-08-05, at 18:05, Christian Ams=C3=BCss = wrote: >=20 > Both would make good corr-clar material. Yes! Great plan for a summer on the patio. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 5 10:44:58 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11C3A0F20 for ; Wed, 5 Aug 2020 10:44:57 -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, HTML_MESSAGE=0.001, 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 6UwB2Z45R2Ue for ; Wed, 5 Aug 2020 10:44:54 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130075.outbound.protection.outlook.com [40.107.13.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 7FCCB3A0F1E for ; Wed, 5 Aug 2020 10:44:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DGZjwWSxseZeRKCRS35slaFXeKBFyjIRgifpN+8cd0AKRmrHfymA1CTN1t1Fca/BYY6Doj1xtWp/hSh74WqRsLQcz1L81GWkhrIiG8M05taxPMVpyRGxFdOSkm/uhEgUrVqwqIRchHPfCkJ5qtwaAgBgk2bArqFUZru0p70wQT3amG2PGjTx8+ZpUkDwWT4pgorXDXIoFBUlcCjDKt1Dd8PMBY+pSdc4UZU3zfpOjqNlJv3w+cfkfCOv/uwdAUgrf46FTBLzXBW12H8SVtOT08ZBwm6u2kLgKFSs7AN++zi2sxq1VvhQUdMXpAZgRzFXFg7JRrYwHVnUvkNZuQ4b1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4wTvMbF62t4OFcH4y3AWyuPu1rrUCCXh8jRxpV0mfVA=; b=UdcR5RE6LLxJaK/FOnHDb8JVZKRad9SwrCJB4MJDVclqKJBmwf8zmxbrVtGAlKzHlRBDZ6KobsqVQjXxW4vtm09V0qIKiEgI0gyyJeFYJqXbpnkZWs6/w9R3yky405KiL54s7DENErxN3Ib1x0gswi5WWbT4KpOGSi6bhz88jPNAB2HI7d0weOb3Wf9rQKZs+ny/iybNK65bXHH2Pk6TU6YN0aXTLrwFdDd7SGqlb0Ee+J+TBd580FHjAFRdAkou1axk0IaJuL4RfRKry3Fn+h7fLSVPer32ADMzUHSo/57Rn91qcRdKJ3UFVpJ/CopmrQsEj1HpQ8jS07oA+XOdkQ== 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=4wTvMbF62t4OFcH4y3AWyuPu1rrUCCXh8jRxpV0mfVA=; b=LdseMV7AzbN2vLoHqux1fJGOGnvaxI5d9fS7yzckmeScNesGWEaoTemEx05mlrovBylIOgi8XFYqFARgU45MeVI9XjQtzVqwG6t1U2ImXvjPCrDpRhPvGS/5aqspavOwKMbmGDnn48MPH29VyM9O5Ae+QxfdFYaENW1aOQ5gHro= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0431.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 5 Aug 2020 17:44:50 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 17:44:50 +0000 References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> Message-ID: <94add7a3-cfba-46a1-538e-e7bd8faa9f7a@ri.se> Date: Wed, 5 Aug 2020 19:44:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A5Jav65CPBOr7XR7tngJRPaZYclMMF7fS" X-ClientProxiedBy: HE1PR0502CA0003.eurprd05.prod.outlook.com (2603:10a6:3:e3::13) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (196.240.54.44) by HE1PR0502CA0003.eurprd05.prod.outlook.com (2603:10a6:3:e3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15 via Frontend Transport; Wed, 5 Aug 2020 17:44:50 +0000 X-Forwarded-Message-Id: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> X-Originating-IP: [196.240.54.44] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 11b653ce-c03b-418f-c257-08d8396740c5 X-MS-TrafficTypeDiagnostic: VI1P189MB0431: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FY/0BRqTxLQ+RXg90dV0uaYkY9nsa+lbgXKrQrn0gb+uS8wtsIRdn993xzhQI+iR0y18aZeZBO4cW+39ljDYHpXSKj4yjSKrSHkwoM3CzgqzId9kLOoIc9LfaAMCcYmUh5JDI4n93qWm8xaT+/fBGm0rgXBX7ov6Eu4churY1qvFtIU5pDqWmbuTeISc0zEqX9rT5alznuuAE9W4JCS4NPEFbYBIfcjCR3jWaU0JfT0nc52S1+SNeUeB8p94qTeMYxMXYZ83oWefyNUItbpXGQ7pqYSPQB0phTsmw8H8JdUJSw2kHXYlOp37bYrCdosBa/+RxriKyKZdelkDcjyIw6y/dXAYrCQnwKTBX4gNs8JlWhmEtWeKFMotBlDM2OtRl0eZCvn9xvDhRWVpvHBpswv2fwr76j5FcVU+wPTG1V3LV8PNkv3ousFogkW4mVWDR8JV51sCpJOq9XEXLAOHKuEnOTHyRYHcA+DIyJ3SWFk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(136003)(39850400004)(396003)(376002)(52116002)(16526019)(478600001)(66476007)(5660300002)(66556008)(66946007)(8936002)(31686004)(6666004)(21480400003)(5001810100001)(31696002)(26005)(186003)(235185007)(6486002)(6916009)(44832011)(36756003)(83380400001)(8676002)(16576012)(2906002)(956004)(2616005)(86362001)(166002)(966005)(316002)(223384002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: fx8R0MT2MFm1zMpzK7tWCJPI3/kTi2rthxA7xgUKS5wzvwinZqsPe8AU+IC+tX+bhCFfEW5aO+yQzC9TgGE1dQrnoL32RVX+F7hpAZYGpAKop5jV3f5TzQFGzyDfP+eL3fT0eQ7EgwhGbfQUZ+y/hZrKAYiajlLDj2zgozp9GbB2so0cEbcrw506D7L/udLqgCbgnKH7NiHfQq5oPkohX4gxuzp8swQ0Chl2O4UorlinxrH/yeO7kZtL0dskSfqIoALevxw9ECkp/7vEhSKF6R6ArTDt95pAnmhbGHs7XczGXJvxoKgvAGZ1BxeV2VPhHjvDDeqYBOzt37vEIKtVLnyZMGYP2Vc15CsmCAcI3wQsUPOc2M4CldMX1nlB+U0HJ21wiBy2AHSCrZV/ujnaMLEbm1HtSMvTEEbUMQYP9E1r7vzIGN66OSXIBqw7fRB8qFNgxombBGuHPEP11lZm3rYMojqOy25+2xRK8JteYA05aZtgHdSaLdr7mbQJuAudCxqsKwnMHdZM4Fl5hy0HrEUhKTZLSzAcrUSLTetQOcqlaU51Ras0o4D35AhOQniZWXYI/R7YT9o7yuhxB4cz0jMfF7vfMMDyrVOqVPZldRMX0D1HOsxNKAmP+Wam/C+HmTWRwQj8dABhrgltcuLIgg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 11b653ce-c03b-418f-c257-08d8396740c5 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2020 17:44:50.6280 (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: 7ZL5JIQTODI/z+usUBQN4NiX5OitaRTEreVMCtzOpeg65VcK0u0fUUzJG51KbD/+HmRAt7BBDPpnyShHJ584BQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0431 Archived-At: Subject: [core] Fwd: [108all] Final reminder: IETF 108 meeting survey 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, 05 Aug 2020 17:44:57 -0000 --A5Jav65CPBOr7XR7tngJRPaZYclMMF7fS Content-Type: multipart/mixed; boundary="ftu6oTHopT5gFhmKiza0IjSQe7vMLz42E" --ftu6oTHopT5gFhmKiza0IjSQe7vMLz42E Content-Type: multipart/alternative; boundary="------------EDB2C08EF0941CC22E7236FB" Content-Language: en-US This is a multi-part message in MIME format. --------------EDB2C08EF0941CC22E7236FB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, If you participated in IETF 108, please consider to fill the survey below= =2E Best, /Marco -------- Forwarded Message -------- Subject: [108all] Final reminder: IETF 108 meeting survey Date: Wed, 5 Aug 2020 22:30:16 +1200 From: IETF Executive Director To: 108all@ietf.org Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: https://www.surveymonkey.com/r/T3SL7JF Thanks in advance --=20 Jay Daley IETF Executive Director exec-director@ietf.org --=20 108all mailing list 108all@ietf.org https://www.ietf.org/mailman/listinfo/108all --------------EDB2C08EF0941CC22E7236FB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all,

If you participated in IETF 108, please consider to fill the survey below.

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: [108all] Final reminder: IETF 108 meeting survey
Dat= e: Wed, 5 Aug 2020 22:30:16 +1200
Fro= m: IETF Executive Director <exec-director@ietf.org>
To:= 108all@ietf.org


Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey:

https://www.surveymonkey.com/r/T3SL7JF

Thanks in advance

--=20
Jay Daley
IETF Executive Director
exec-director@ietf.org


--=20
108all mailing list
108=
all@ietf.org
https://www.ietf.org/mailman/listinfo/108all
--------------EDB2C08EF0941CC22E7236FB-- --ftu6oTHopT5gFhmKiza0IjSQe7vMLz42E-- --A5Jav65CPBOr7XR7tngJRPaZYclMMF7fS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8q8A8ACgkQ7iZktA5Y 2kMatggAr74+0MIVUNCDFa73fAJo0zNC46i1p3yx6gwEHFt4CV3AdYRuqBEPhV6L 0jtQIJNUQ3YrkcrmeNUxBYiKzGafBVAQbZ8aqG07vGdUVLuy7XtCqnlxy1bP1lnc 5Nbko/FIkq7KqnF96h5ShMqgBu/NobpKDnsZGSISOvol+ZY35WrXsmA1nDoKRtZ5 IwMcZcV6YlK7JGbH5z+j0lrhwHjHXdTyVuFbtQQlXTXhmtJFuOV9zQHRGNMblMuz 0o+srHUlroqMiRmH87mF53ifYUmVmJ+WrbVhPi4XPbG2mf6ye/19U0McSXe5Ax0S reWhdOqqedkTN4n3BlKGTzNEwvqWzA== =aeKV -----END PGP SIGNATURE----- --A5Jav65CPBOr7XR7tngJRPaZYclMMF7fS-- From nobody Wed Aug 5 10:53:43 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44A3A0E61 for ; Wed, 5 Aug 2020 10:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 O_nN1ME13Iln for ; Wed, 5 Aug 2020 10:53:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4961F3A0DB5 for ; Wed, 5 Aug 2020 10:53:40 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 5 Aug 2020 10:53:34 -0700 From: Jim Schaad To: Date: Wed, 5 Aug 2020 10:53:32 -0700 Message-ID: <061001d66b51$576ad330$06407990$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZrUQJrhA8iH7iaTsqhmCK1Hn4Zjg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Observe clarification 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, 05 Aug 2020 17:53:42 -0000 In section 4.5 the text "A notification can be sent in a confirmable or a non-confirmable message." Depending on how you read this, the notification could also be sent in an ACK piggyback message as well. That is you CAN do this, but you don't have to. The text "A notification is sent in a confirmable or non-confirmable message." Would have the connotation that these are the only allowable options. I believe that the latter is what the text was intending to say, but I do not know that is true. Comments? Jim From nobody Wed Aug 5 12:03:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358A73A0E67; Wed, 5 Aug 2020 12:03:37 -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 XZNadK-rbW_B; Wed, 5 Aug 2020 12:03:34 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC3D3A0E8E; Wed, 5 Aug 2020 12:03:13 -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 AC65C40760; Wed, 5 Aug 2020 21:03:10 +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 73332AB; Wed, 5 Aug 2020 21:03:09 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:75ff:3fb:79be:d36d]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EB76964; Wed, 5 Aug 2020 21:03:08 +0200 (CEST) Received: (nullmailer pid 3515558 invoked by uid 1000); Wed, 05 Aug 2020 19:03:08 -0000 Date: Wed, 5 Aug 2020 21:03:08 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: , 'Core WG mailing list' Message-ID: <20200805190308.GB3470838@hephaistos.amsuess.com> References: <009a01d65c90$98bc6da0$ca3548e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <009a01d65c90$98bc6da0$ca3548e0$@augustcellars.com> Archived-At: Subject: Re: [core] Review draft-amsuess-core-cachable-oscore-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 19:03:37 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, thanks for your review! On Fri, Jul 17, 2020 at 04:18:33PM -0700, Jim Schaad wrote: > I will admit that I found what was proposed here to be very interesting. = I > am unsure of how well it would work and think that we may want to workshop > it at some point just to figure that out. Are you thinking in the direction of "let's think through concrete exchanges", or "let's try this out with a prototype implementation"? > * Reading this document made me really long for an OSCORE padding docume= nt > where the message can be predictably padded out to fixed length so that it > would make one of the issues raised in this document moot. Good point -- it'd be generally useful but particularly so here. Would be typical Appendix material. > * One wonders about the goodness of returning both a "This is what the > deterministic request says and here is the encoded request but you cannot > decrypt it". It does mean that you need to have a degree of trust for the > server not lying to you but would potentially allow for an even shorter > request. That shouldn't be the case. Any consensus request the client receives must be readable for the client, otherwise as you say it makes little sense. Any hint to such behavior would be an error in the document -- but I take that point as a cause to point out the importantce of reading it to the client in the Consensus Request definition. > * It might be worthwhile to signal that you are going to ask a lot and use > an application/multiple-coap content to return both the answer and the > deterministic request. This means that it would not be cached until the > next ask but that is going to be true anyway if the server is providing t= his > request. I think that this becomes largely moot with the addition I announced at the meeting (where the client would send a hash of the plaintext in an outer option). In such a setup, the client already gives the server a hint as to the desire for a consensus request and response. (When the client uses a deterministic request, it can start the process as well). On the long run, I expect that indication will rather be needed in the other direction: A client may not know for which requests it is part of a swarm and which are more individual. In that direction, it may work to have a target attribute in the link that asks a client to generate a deterministic request if its security policies allow that. KR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8rAmMACgkQOY0REtOk veFG8hAAi3VtujpIWt7z7oOhdgc1o7+8P2cUQWMIBQLNyFAjSinIMn1P1vKkAGMm vxBgymnh2XjPcb4nhg2uRHXlbgh8ibaiJVr48dRRlHxFRRHi7zTjYK1gMihoCAKI So3rOqUUmqgSsArn3rrOiRnzzoY2kCitkmR+yE4D3uo7z4ZNfS1+CABFRMErCih8 ftLnsgF2GbhvjkDcltZH5X+e3QS4Z4vqXJikVE3+3C7p9HAZfTh1UPmSB+ZYEVk+ 39MlbFo0aANB8lBhN3Fmogqi2xdR3HpAq4FTbX/uGX1cIiOqqTwRjqmbo8gpbB4y YcLUsfW4k8VkebDmm/yl0o2MC5C20Yilt17x9dnjY28xX5ENvGAbL10mB0WPA0/V 3dm7RQc4fGZ3cqnd4+7TmyEtgn+ehlcC3MGfR8tu1jQYxNCBc7PpExdPs3yeeKIN AEhG3XSyifkZjrMRJ3samK4h04KlNDCqN7OVLWGiS83IElcPbZN6B3ucm/52/Dm4 KkHmsVYfubt7RYvyM3omk1rHAbeWpYylynw9RbzUu5qX8Bjxq4DFmYf9BN0goA7L ACoXOnNXtU0fSXhakIHZ/XNGB5tvStfp9HqQMChWTEfPtLJYfzu1VuSOrhm2z3Av BIk8OP7g5OyUDM+Dik/QflYYl0Z16gSwQjQv37agyKkF/854ptM= =/TY6 -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From nobody Wed Aug 5 12:35:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5033A0EC7; Wed, 5 Aug 2020 12:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 etnxjyFonq3I; Wed, 5 Aug 2020 12:35:42 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A303A0EC4; Wed, 5 Aug 2020 12:35:42 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 5 Aug 2020 12:35:17 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= CC: , 'Core WG mailing list' References: <009a01d65c90$98bc6da0$ca3548e0$@augustcellars.com> <20200805190308.GB3470838@hephaistos.amsuess.com> In-Reply-To: <20200805190308.GB3470838@hephaistos.amsuess.com> Date: Wed, 5 Aug 2020 12:35:15 -0700 Message-ID: <061e01d66b5f$8d5c9b50$a815d1f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHQ6d+KdSoz73fcUxnp1ylL1lt8vQHYHF/CqSYmGKA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Review draft-amsuess-core-cachable-oscore-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 19:35:44 -0000 -----Original Message----- From: Christian Ams=FCss =20 Sent: Wednesday, August 5, 2020 12:03 PM To: Jim Schaad Cc: draft-amsuess-core-cachable-oscore@ietf.org; 'Core WG mailing list' Subject: Re: [core] Review draft-amsuess-core-cachable-oscore-00 Hello Jim, thanks for your review! On Fri, Jul 17, 2020 at 04:18:33PM -0700, Jim Schaad wrote: > I will admit that I found what was proposed here to be very=20 > interesting. I am unsure of how well it would work and think that we=20 > may want to workshop it at some point just to figure that out. Are you thinking in the direction of "let's think through concrete exchanges", or "let's try this out with a prototype implementation"? [JLS] I was thinking of the first one I don't know that the second one = is possible until we have a better idea. > * Reading this document made me really long for an OSCORE padding=20 > document where the message can be predictably padded out to fixed=20 > length so that it would make one of the issues raised in this document moot. Good point -- it'd be generally useful but particularly so here. Would be typical Appendix material. > * One wonders about the goodness of returning both a "This is what the = > deterministic request says and here is the encoded request but you=20 > cannot decrypt it". It does mean that you need to have a degree of=20 > trust for the server not lying to you but would potentially allow for=20 > an even shorter request. That shouldn't be the case. Any consensus request the client receives = must be readable for the client, otherwise as you say it makes little sense. Any hint to such behavior would be an error in the document -- but I = take that point as a cause to point out the importantce of reading it to the client in the Consensus Request definition. > * It might be worthwhile to signal that you are going to ask a lot and = > use an application/multiple-coap content to return both the answer and = > the deterministic request. This means that it would not be cached=20 > until the next ask but that is going to be true anyway if the server=20 > is providing this request. I think that this becomes largely moot with the addition I announced at = the meeting (where the client would send a hash of the plaintext in an outer option). In such a setup, the client already gives the server a hint as = to the desire for a consensus request and response. (When the client uses a deterministic request, it can start the process as well). [JLS] The ever popular - I changed things so this is moot ploy. [1] = Need to see it written down but I think it is equivalent. On the long run, I expect that indication will rather be needed in the = other direction: A client may not know for which requests it is part of a = swarm and which are more individual. In that direction, it may work to have a target attribute in the link that asks a client to generate a = deterministic request if its security policies allow that. [JLS] I am not sure why it would matter in some respects. If the = response is going to be more individual then either you are going to get a unique deterministic request or not use it at all. Jim KR c [1] See "The Pink Panther" -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom From nobody Wed Aug 5 12:48:20 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E093A0EC5 for ; Wed, 5 Aug 2020 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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.949, RCVD_IN_MSPIKE_H2=-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 4gb5ENoiWrVi for ; Wed, 5 Aug 2020 12:48:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108C73A0C0F for ; Wed, 5 Aug 2020 12:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1596656888; bh=CDwCn8+E4UuoJly/znwtH2Ux7zpjbOdDkMskEHi5IbE=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=FwJNcF8J6l6KbLSExsFEQghhP3XNlGYjjJ7EZ1cz3pQ7R/e+G2EFiLlIMnCWRH2fJ R78c6RlrVErNH2CF7ADSwvFNxW7Gw0tt2r8pH7NKkIdW+H0+mOUelXN3COYdM3dhYN 2+7WHiyqIUxq5A9VQNqbT/05M7hUwpz4yw+NYrhs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.64.94.53]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MzQkE-1kypMe2U1g-00vQcY; Wed, 05 Aug 2020 21:48:08 +0200 To: Jim Schaad , core@ietf.org References: <061001d66b51$576ad330$06407990$@augustcellars.com> From: Achim Kraus Message-ID: <49d632a7-8bf9-f253-e3ed-b488b220af4b@gmx.net> Date: Wed, 5 Aug 2020 21:48:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <061001d66b51$576ad330$06407990$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:xrI77Tfb6G+KU6ybUg04BzFQc9lCwn+ujdA3eydmJbHIQt0cqqu EfkFpxQ0/bpDs4v71W6DMdPL4gmIefAp1muv2EVC45W01P0UrlXILxCsrsdvJBRMgHnwgk5 2ZsbRQe0O7qeocbwIsxezAU1iAZ/UiFV/ssptiBRy+hEQlf60cvgjq9KSIQQzjMDPP7BW3p TcW+mXh5x9coaH/Rle9Ag== X-UI-Out-Filterresults: notjunk:1;V03:K0:JUhHN8dNY/g=:Tya/VLN/3rNkO2MQdCZiOQ 3UwFFIWBI0Xt2wrh+XgrzOP/bJG9I4d+iyOKGf74drSTBNBP/orR2fRWPU3w2/cOUxr2SH/vg WO3cFmgnPrLfJja3YRPUr6q40vvHbVkNQXUbfRk6+3S4f4D3D3ZM0WaQ8YUIWmElmWO3cM5/D bWFDVI0T1JLAc2rzBzncrtFvjBQYsW8GTlKhZv7GHMMVlvM1JJnL47busKmkU9YjRjiXfjFYx IdFfXeKtMe+DZLgrnxwHCV97WtqXIspgp8N1rvBabyn7b+Vaeon6Jrm2PNSXpczImcOTyJ5mZ iecINGZYy9H9Djrz1cEC8J1AkFHmajd/2cMT3CBa+t+pQgOCycsCfExkN0Ny6jOrGNxm0xWuM yLG6thncBD69tf9BHpcC28pdTMBPDoX9S5HV2q4p+K8zXI/sC8rfygGgVljqv6l9gnyM/GY2Q nFF1BKBxXCd1kLo7Osm09R8u+uWPGgv481g//XBM9UncJpuej12/kBuD69Gn9wV/nJmvAylkx kLSABhZTXhsFsjkI0IARPA5gFKlVZkXCZ46dHDHbfMTnVwIzVMZOD4V6xFonsphTKBbdiLTGl EJsuHqhoXgYzxGCmg/iJI6VbpCwPFwAeDHbyMRKOhrGtYEnz/f0sUaIXdrXrvj9W04u9hxlES gzS8fyr7kYNwKiwLU77ERY/ML5qxio7ibuOnGCMO8e9bHO54w8qQCoUzFdQfD07RtY0Ep1/mB 8cLn0GxGXvs6vp79EPe4AiLE9Pa/vGEfq5wH0YpfogFvpL/Ld3OiygfwcWUf112DLi6qIPzQ9 6d6M8o/GibpfZQYj8dcas4XT0RF5KLPdioY4iZn2nOPoLOJINnV9BPeZs/ttpC5cui0D9GE/y G2NERMhm2SjXJ6ImTVsNIjRm5gDUC3uN9mon1Px2kJtei565axG3bRLMKbZzmrkyURe5EYOxG LGpy7gFYbH34W5yfHonGM9egaTesNc+MndqsG1QnJhuWZFQr/BSda9LcZA5Dw/Do7qFJgCJpR YziHB0naFUA1y6Thk55ujkLw9qyPBlPe1HykyssiyyS5AsMNx2q9jVttBX+bmkMd+vF+OOXhW 2WBw6j96jO381CXNNs9bmYuRvtTLZhco+dOKK/99n2dD64eJ6pVHj5IWlcdotr8HBQ/diC5QN he+s9EtGceF8ob+h9TeGOHmiY2jniQNb6tSycVzTypLSkYD7aXlFwkkrElnjxLcRSmG/7btfL Ac9IKIt8ZK5x6xbZNlUHURyuLfT/11/IhO8qj+w== Archived-At: Subject: Re: [core] Observe clarification 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, 05 Aug 2020 19:48:20 -0000 Hi Jim, I hope, that the later interpretation is the right one. A notification as an ACK-piggybacked would allocate the request MID, that would have strange consequences. best regards Achim Am 05.08.20 um 19:53 schrieb Jim Schaad: > In section 4.5 the text "A notification can be sent in a confirmable or = a > non-confirmable message." Depending on how you read this, the notificat= ion > could also be sent in an ACK piggyback message as well. That is you CAN= do > this, but you don't have to. The text "A notification is sent in a > confirmable or non-confirmable message." Would have the connotation that > these are the only allowable options. > > I believe that the latter is what the text was intending to say, but I d= o > not know that is true. > > Comments? > > Jim > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Aug 5 13:01:59 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB43A0F04 for ; Wed, 5 Aug 2020 13:01: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 aYoAnU6CSYZN for ; Wed, 5 Aug 2020 13:01:55 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B5A3A0F03 for ; Wed, 5 Aug 2020 13:01:54 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1k3Pbk-0000cu-EM; Wed, 05 Aug 2020 21:01:52 +0100 From: To: , , References: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200805142431.GB3480705@hephaistos.amsuess.com> In-Reply-To: <20200805142431.GB3480705@hephaistos.amsuess.com> Date: Wed, 5 Aug 2020 21:01:19 +0100 Message-ID: <390001d66b63$2f8a3790$8e9ea6b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGbgdAKRJXOGFNPLffmJxyavYbYjqmfsTSQ Content-Language: en-gb Archived-At: Subject: Re: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 20:01:57 -0000 Hi Christian, Thanks for this review. Med and I will update the draft as appropriate. Otherwise, comments inline Regards Jon > -----Original Message----- > From: christian@amsuess.com [mailto:christian@amsuess.com] > Sent: 05 August 2020 15:25 > To: mohamed.boucadair@orange.com; Jon Shallow (supjps- > ietf@jpshallow.com); core@ietf.org > Subject: core-block-04: Applicability and general remarks draft-bosh-core- > new-block-04.txt > > Hello Med, hello Jon, > > here's a few concrete points I'd like to suggest for new-block: > > * Applicability: I'd have expected to read something like this in the > introduction: > > > The block-wise transfer of [RFC7959] covers the general case, but > > falls short in situations where packet loss is highly asymmetrical. > > > > The new options introduced here provide roughly similar features to > > the Block1/Block2 options. They provide additional properties that > > are tailored towards the intended use case, and leave out mechanisms > > like non-atomic access and proxy support that would complicate their > > description. > > > > They are not intended for general CoAP usage, and any use outside > > the DOTS use case should be carefully weighed against the loss of > > interoperability with generic CoAP applications. It is hoped that > > experience gained with these options can go into future extensions > > of the block-wise mechanism that are both generally applicable and > > serve this particular use case. Jon> Thanks for the suggestions > > * Separation of layers, sub-topic "congestion control": It should be > possible to phrase all congestion control parts of this in a dedicated > section (which may also make sense as an appendix). Jon> Good idea > > I'd avoid all other mentions of things like PROBING_RATE: For example, > Section 3.4 right in the middle of a paragraph on re-requesting > missing blocks states that > > > The rate of requests for missing blocks is subject to PROBING_RATE. > > Yes it is, but so is every single CoAP request until the client hears > back from the server. Repeating these things in places where are not a > new requirement may make it easier for some implementers that try to > build the whole stack in a single go, but even for them is prone to > the authors missing a spot -- and for everyone else this will each > time trigger the question of "is this new here or isn't this already > handled by a component two layers down the stack?". Jon> OK > > I haven't tracked every single retransmission and rate limiting > statement throughout the document, but I expect that this section > could boil down to something like > > > For the DOTS use case, the following default CoAP parameters are > > updated to better reflect the typical deployments: > > > > * PROBING_RATE: 10 kilobyte/second > > > > The averaging process mentioned in RFC7252 Section 4.7 after which > > PROBING_RATE applies is not fully defined there. For the above > > applications, a new parameter PROBING_RATE_WINDOW is introduced. > > Messages up to a total size of PROBING_RATE_WINDOW may be sent > > before PROBING_RATE is considered, and the probing rate may > > generally be exceeded by that amount of data in short term. > > > > * PROBING_RATE_WINDOW: 15 kilobyte > > (The latter replaces MAX_PAYLOADS, and I'm not sure whether it is > better to express this in terms of package count or bytes on the wire, > just giving an example here. All numbers in the above were pulled out > of uninformed air.) Jon> My leaning is towards packet count - circuit speeds cover a significant range. I need to think this through. Jon> The default RFC7252 PROBING_RATE is too low in my humble estimation - a large packet can cause long inter-packet gaps (300 bytes is a 5 minute delay) > > * Separation of layers, sub-topic "Tokens": Same thing, next layer. > > Whenever you're tempted to talk of a token, consider some of these > replacement phrases as a first step: > > * "MUST be sent with a new token" -> "is a new request". > * "Tokens MUST be included" -> (nothing -- transports use tokens by > construction) > * "MUST be sent with the same token as the response" -> "is sent as a > response to" / "is sent as an additional response to that request". > (Here it may make sense to refer to the tokens in an additional " > (which means it uses the same token, the same way an observation > response uses the requests's token for multiple responses)"). Jon> Agreed - Token references needs to be tidied up. Will work on this. "additional" may help us here to clarify which token 'value' should be used where. > > * Naming: It's technically a minor thing, but people have already > complained to me about how hard the Block[12] names are to > comprehend, > and introducing these options as Block[34] would not help here. > > I'd like to suggest QuickBlock-Block[12]. Jon> Certainly Block[34] are likely to transfer data more quickly than Block[12]. However xxxx [12] implies a replacement for Block[12] which I am not so sure about. > > (I know that this part of designing a new option is annoying. In the > interest of winding up with something that can be learned easily, it > is unfortunately essential). > > In connection with that, it may make sense to briefly think about a > draft name before it is submitted as a WG draft. new-block sounds like > a 7959bis, which in my understanding this does not aim to be. Jon> Good idea. > > * 4.TBA3 Missing Payloads: I don't quite see why this needs a distinct > code. 4.08 Request Entity Incomplete sounds perfectly suitable to me. Jon> As we have to define the diagnostic payload as containing the missing blocks, we did not want to change the semantics of how 4.08 is used - hence TBA3. Jon> That said, a 4.08 response could contain 1 or more Block3 options but that would take up more space. > > If you think that sending an existing 4.xx code in the middle of a > block-wise transfer would cancel the transfer, there's still two ways > out of this: Jon> I was concerned about the 4.08 diagnostic payload changing format, but yes, an 'unexpected' error code could terminate the transfer. > > * You're just defining what a block-wise transfer is; just allow it. > > (In a RFC7959 block-wise transfer that runs over a proxy, the proxy > may be currently incapable of doing any forwarding and return 5.03 > Service Unavailable Max-Age:5. The client would then just pause 5 > seconds and send the latest block again.) > > * For all but the last block, it may also be an option to send it as a > payload to a 2.31 code -- I don't think that would be outright > forbidden (and at any rate, all involved clients speak the protocol > anyway). Jon> I have an issue with changing the 2.31 reporting on the last successful block received - this currently fails if block num of 0 is missing as we cannot indicate block num = -1 has been received. Jon> If the last block is received, but a previous one was not, a 2.31 could be used to re-request the missing block, but a 2.01/2.04 would need to be held back for the final block acknowledgement. > > * The draft describes this all as "just working through a proxy" -- > original block-wise does not, and I'd like to hear how this is hoping > to get away without the options being proxy-unsafe. Jon> I was not aware of CoAP to CoAP proxy issues with BLOCK[12] when this was written, but your comment implies that there is. Certainly CoAP to other protocol proxies could run into issues. Jon> I was thinking of block by block proxying working and hence could be proxy unsafe. > > Is there any point at all in using block-by-block proxying for these > use cases? Unless a proxy is sitting right inside the link under > attack, and unless the bodies get huge, it may be way easier for this > to be purely hop-by-hop. Proxies would reassemble the full bodies and, > for the next hop, just decide what works best there (be it regular > block-wise, Block34 or BERT). Jon> Yes, there could be full body re-assembly and the full body held in cache if needed. This would add in a bit of latency. However this would restrict a Block[34] possibility of supporting streaming of data should that be required. > > (If there's a point in allowing block-by-block forwarding, we can talk > it through and work through the initial ideas that will come up like > "We use large enough Request-Tag values so they are unique", "how > large does that need to be", "why do we end up having a Request-Tag in > every request now" and "why do we not want that", but my gut feeling > is we won't need to go there.) Jon> For Block3 which would use Request-Tag, I would expect that for a specific body of data for a specific resource the Request-Tag to remain the same - and if the body changes a new Request-Tag is used. Jon> As this is the same Request-Tag for whether the whole body is cached, or individual blocks of the body the Request-Tag usage will not change. 2^32 should be large enough - 2^64 even better - but re-usage has to be generally considered. ~Jon > > Kind regards > Christian > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom From nobody Wed Aug 5 13:32:40 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B463A0F51 for ; Wed, 5 Aug 2020 13:32: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 rGznTjxgAEd7 for ; Wed, 5 Aug 2020 13:32:35 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CF73A0F11 for ; Wed, 5 Aug 2020 13:32:35 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1k3Q5P-0000dY-VI; Wed, 05 Aug 2020 21:32:32 +0100 From: To: "'Achim Kraus'" , "'Jim Schaad'" , References: <061001d66b51$576ad330$06407990$@augustcellars.com> <49d632a7-8bf9-f253-e3ed-b488b220af4b@gmx.net> In-Reply-To: <49d632a7-8bf9-f253-e3ed-b488b220af4b@gmx.net> Date: Wed, 5 Aug 2020 21:31:59 +0100 Message-ID: <390201d66b67$77f867a0$67e936e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKfyQjcnB6GrptBx4L15yK3+P4EhQJMZy9vp4TW4dA= Content-Language: en-gb Archived-At: Subject: Re: [core] Observe clarification 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, 05 Aug 2020 20:32:39 -0000 Hi Jim, As I read RFC7641 the initial request with Observe:0 can have the response in an ACK piggyback. However, this response is not an Observe notification - it is the current representation. 4.1. Request A GET request with an Observe Option set to 0 (register) requests the server not only to return a current representation of the target resource, but also to add the client to the list of observers of that resource. Upon success, the server returns a current representation of the resource and MUST keep this representation updated (as described in Section 1.3) as long as the client is on the list of observers. When an Observer notification is triggered, this can only be Confirmable or Non-confirmable. Regards Jon > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Achim > Kraus > Sent: 05 August 2020 20:48 > To: Jim Schaad; core@ietf.org > Subject: Re: [core] Observe clarification > > Hi Jim, > > I hope, that the later interpretation is the right one. > > A notification as an ACK-piggybacked would allocate the request MID, > that would have strange consequences. > > best regards > Achim > > Am 05.08.20 um 19:53 schrieb Jim Schaad: > > In section 4.5 the text "A notification can be sent in a confirmable or a > > non-confirmable message." Depending on how you read this, the > notification > > could also be sent in an ACK piggyback message as well. That is you CAN > do > > this, but you don't have to. The text "A notification is sent in a > > confirmable or non-confirmable message." Would have the connotation > that > > these are the only allowable options. > > > > I believe that the latter is what the text was intending to say, but I do > > not know that is true. > > > > Comments? > > > > Jim > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 5 22:59:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2C3A0ED3 for ; Wed, 5 Aug 2020 22:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uyorhm3JYquP for ; Wed, 5 Aug 2020 22:59:29 -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 62F713A0ECE for ; Wed, 5 Aug 2020 22:59:28 -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 C23F540758; Thu, 6 Aug 2020 07:59:25 +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 30DF7AB; Thu, 6 Aug 2020 07:59:24 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:75ff:3fb:79be:d36d]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DD9BC64; Thu, 6 Aug 2020 07:59:22 +0200 (CEST) Received: (nullmailer pid 3566463 invoked by uid 1000); Thu, 06 Aug 2020 05:59:21 -0000 Date: Thu, 6 Aug 2020 07:59:21 +0200 From: To: Cc: , Message-ID: <20200806055921.GC3480705@hephaistos.amsuess.com> References: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200805142431.GB3480705@hephaistos.amsuess.com> <390001d66b63$2f8a3790$8e9ea6b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IpbVkmxF4tDyP/Kb" Content-Disposition: inline In-Reply-To: <390001d66b63$2f8a3790$8e9ea6b0$@jpshallow.com> Archived-At: Subject: Re: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 05:59:32 -0000 --IpbVkmxF4tDyP/Kb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, just some quick ones: > Jon> Certainly Block[34] are likely to transfer data more quickly than > Block[12]. However xxxx [12] implies a replacement for Block[12] which I= am > not so sure about. I'd read Something-Block[12] more as a variaton on it, and Block[34] as "the successors to Block12". > Jon> As we have to define the diagnostic payload as containing the missing > blocks, we did not want to change the semantics of how 4.08 is used - hen= ce > TBA3. No, that's what media types are for. By putting in a Content-Format that the client understands, you pick a (not the) representation of the error situation (which, unlike in a situation where no Content-Format is present, is not called a diagnostic payload, but just a payload, or some representation of the error). That payload is, by the way, a piece I'd be very happy to use outside new-block as well. There's nothing that keeps a server from reporting application/missing-blocks+cbor-seq in response to a Block2 (granted, it'd a bit underspec'd there, but at least worth experimenting), so the client could still try to send the missing blocks again. > Jon> Yes, there could be full body re-assembly and the full body held in > cache if needed. This would add in a bit of latency. However this would > restrict a Block[34] possibility of supporting streaming of data should t= hat > be required. Unless DOTS has a use case for streaming data, I'd put that out of scope. (This scope limitation is what'll allow us to get this done in a reasonable time scale). And even if it were, that's not true: There could still be contentual fast forwarding of parts (once the server has a fresh representation of some of the resource, it could make it available using the same or a different block-wise mechanism), just not (potentially even proxy-safe) direct forwarding of the requests as they are. KR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --IpbVkmxF4tDyP/Kb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8rnDQACgkQOY0REtOk veGb9Q/+NZF0eSwRzy2/2CVs4731GCrD2vNnhQziUqfT7PUr7/1rtRvRT51tQaXI ufUyX/7c5Po/zxyh3jd+P3tR4iUcjtpDqeY0q89aG1e01g7+25BmHakuWFsTW6zI wDzVKHob3tcWCHEMt8dQqIyc3bF8jbcbg+xxE77U5+nKVCH/4XBlnmY8vdgxWOip u6P1+og4+IHM1EvVanXUpcVeFw4xFd0w/NbrPpxwaP9zVyLmfBwrgha1WB/jpvfM yX58dvElg+GWCwWcXvv4oChzsblOoW5212PVML2ixZu89oa838h1cW0OTxLcS8lv R8UU0VsBR11g4GbZmBql9mia/1RD9HXWm1DGrBTaVWfc28YqwTT9sisMQSzOd/w5 pBrYcBbZOKtHcRucJsbaMNFjG8dNCFRrSnFHkplEjhWrKX4Hl01QZfGOPqNtwQBS QbUzVeFKrJw1vg7sQgjc0jpEb0+LgaP0RaPBb95zks+pZyTFxP6V3yOzhdH4DgZm QIMcwX4T8x49+Rpo5fhKdWQy/53VAhJPOJLmgWF3Bz/JVJTkr0ZCC1VUMFqVEpao x+8LvUrExqo1Ebr2TDMTjNHqAW4MLh8D46BTek/PN4iDfhyDL3LlJhFi71/f4U0w H94JnG37rjAjiVVqGRnpGKUl+D+UWDLX7FL5Mdc6I+0g22RcwHw= =/ED+ -----END PGP SIGNATURE----- --IpbVkmxF4tDyP/Kb-- From nobody Sat Aug 8 14:35:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216FD3A0658 for ; Sat, 8 Aug 2020 14:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNUlOPgF8o9H for ; Sat, 8 Aug 2020 14:35:25 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 1A0753A0645 for ; Sat, 8 Aug 2020 14:35:25 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id t14so4914487wmi.3 for ; Sat, 08 Aug 2020 14:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AIuSDZ3ZzyUvLPA22kl7xA+aN7PN0qWICxnHiCD3XqA=; b=RmgIeOsJGMGq+6vgTZL52nw4vKWpJpmMn8ykM7uha2zRka3JJNIqXGnd6ZWi49wx3T 7lJSQToaD3daGfIFt9mrWcBnjynx1K2oleFI5J9UmBZcUN9cQZS0x4h0+LcCmo6NJ6iQ hbNB29hicW3Vs8CygQ4+zxdbZCn6WLn7KHSCD12NexvZLXtgt1dOR4qFr8UJD9U8ES5X Xu5ZQ7glVj9eFFDcFCA0AVjo4FLNikMamrzAWfNVkCesjt0hzm2bOacR9dP8OeEzTte7 raqqCNvEmyaURD/dnLF3tAeKQ0F5fYZU4hmKEsSipiMldaKAuilogalFn9zpuQi538ea axKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AIuSDZ3ZzyUvLPA22kl7xA+aN7PN0qWICxnHiCD3XqA=; b=LamAMnCkPvcdJL3BLh4r5Of136v0qVuZ2wxLxPgTmAUN8yW+k2EeLYIenQHA9o/BlW Dm/X4MvHjxKMYNRAWbhF47/yOFCWkpcaYNKImewBcnKLl0RT5JhuYsP6DmhWeUVVqJ+A IRakKRLMMsH2eP1+ABXuE80iQPP85JPPW8yx7dSoITnKKlkHw5cy8+QVKOeW8xSc71mp w+iRSmK8TZ5fBpqEFUPhI1x9HitavwLB662g6PZvHmoFAuwi4Ke9w05YrBJ2XZPIWboq zt5n+4aOgv4a+eyA4bMU91TK49HZx7m/ZI9zos7183MfO6q6kEvVNISpyT2WEAteAnvq d66Q== X-Gm-Message-State: AOAM532y+Y1D9yItcS5ssiBik9Sn1+QyKbMkHZWzvwA8YVem2ohuGKzp ztI53fM1X5tMHp2aKdcbTD8fisqeB1BJEEAa0NpcLw== X-Google-Smtp-Source: ABdhPJwb5jJhmV24Oqi7X11Nq05H9LmSRJuCw2racby8OgA80OFenJu6G21ld66xteRrJQkT8JO7ISavc9dZDLzHSDc= X-Received: by 2002:a1c:b787:: with SMTP id h129mr18539648wmf.93.1596922523461; Sat, 08 Aug 2020 14:35:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Sat, 8 Aug 2020 23:34:57 +0200 Message-ID: To: Marco Tiloca Cc: "core@ietf.org WG (core@ietf.org)" , Cose Chairs Wg Content-Type: multipart/alternative; boundary="000000000000bec03705ac647ff6" Archived-At: Subject: Re: [core] CoRE interim meetings X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 21:35:27 -0000 --000000000000bec03705ac647ff6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marco, Just to make sure that everyone is aware that currently COSE is looking at having its virtual interims (at least 3 of them, 1h each) from 16:00 UTC on 26/08, 09/09, 23/09. That conflicts significantly with only one of the slots that you have proposed and less with another one. Cheers, Ivaylo On Tue, Aug 4, 2020 at 7:08 PM Marco Tiloca wrote: > Dear all, > > We are planning to schedule regular virtual interim meetings, recurring > every other week, starting from the second week of September and until > the end of October. > > Please, cast your preferences at the Doodle poll below, by the 20th of > August EOB. > > https://doodle.com/poll/cb9qshfymw6tdgna > > The options in the Doodle refer to the week of the first interim > meeting. The following meetings will occur every other week on the same > weekday and time, until the end of October. > > Best, > Marco and Jaime > > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000bec03705ac647ff6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Marco,

J= ust to make sure that everyone is aware that currently COSE is looking at h= aving its virtual interims (at least 3 of them, 1h each) from 16:00 UTC on = 26/08, 09/09, 23/09. That conflicts significantly with only one of the slot= s that you have proposed and less with another one.=C2=A0
<= br>
Cheers,
Ivaylo
=


On Tue, Aug 4, 2020 at 7:08 PM Marco Tiloca <marco.tiloca@ri.se> wrote:
Dear all,

We are planning to schedule regular virtual interim meetings, recurring
every other week, starting from the second week of September and until
the end of October.

Please, cast your preferences at the Doodle poll below, by the 20th of
August EOB.

https://doodle.com/poll/cb9qshfymw6tdgna

The options in the Doodle refer to the week of the first interim
meeting. The following meetings will occur every other week on the same
weekday and time, until the end of October.

Best,
Marco and Jaime

--
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://= www.ri.se


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000bec03705ac647ff6-- From nobody Sun Aug 9 23:47:26 2020 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 F357D3A141A; Sun, 9 Aug 2020 23:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159704204394.11310.18005109400419971010@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Sun, 09 Aug 2020 23:47:23 -0700 Archived-At: Subject: [core] Secdir telechat review of draft-ietf-core-resource-directory-25 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, 10 Aug 2020 06:47:24 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The -24 version of this draft was reviewed by Adam Montville. I looked over his review and I think that the issue he raised about possible mitigation of DDoS amplification attacks has been addressed in this version. I personally think that sentences describing how DNS and NTP are vulnerable to amplification attacks are redundant in this document, but that's a matter of taste and doesn't hurt. It is my impression, that Security Considerations were mostly written having in mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or even "MAY" if we look at RFC6690 which Security Considerations this draft refers to). I think that adding a few words describing which consequences for security not using (D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent. From nobody Tue Aug 11 12:27:11 2020 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 305153A08B9; Tue, 11 Aug 2020 12:27:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <159717402717.27772.14957520028083871786@ietfa.amsl.com> Date: Tue, 11 Aug 2020 12:27:07 -0700 Archived-At: Subject: [core] Warren Kumari's No Objection on draft-ietf-core-resource-directory-25: (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, 11 Aug 2020 19:27:07 -0000 Warren Kumari has entered the following ballot position for draft-ietf-core-resource-directory-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: " A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is trying to say, or "for discovery purposes" should be dropped.... 4: "As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/ From nobody Tue Aug 11 19:57:57 2020 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 50E4B3A0EA9; Tue, 11 Aug 2020 19:57:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159720107494.28255.1546033232009788973@ietfa.amsl.com> Date: Tue, 11 Aug 2020 19:57:55 -0700 Archived-At: Subject: [core] Roman Danyliw's Discuss on draft-ietf-core-resource-directory-25: (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, 12 Aug 2020 02:57:55 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-resource-directory-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There appear to be a few areas of straightforward, under-specified elements of the authorization model. -- How does the RD know that a node claiming to be a CT is in fact a CT and is permitted to register on behalf of end-points? It seems like there is a missing, simple statement to make that this is configured out of band with the RD? Or is that carrier somehow in a authentication credentials? -- Is there are reason why there is not normative guidance requiring the RD to check whether authentication clients are authorized to register particular resources? Section 7.1 covers the issue, but all of Section 7.* is explicitly noted as informative. Section 8.1. says “Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (Section 7.1) or whether arbitrary names are accepted (Section 7.1.1)” but this text seems to frame it as authentication issue. Section 8.2 seems to stress only the distinction between the registration and lookup API. -- Section 8.1. Per “If the server does not check whether the identifier provided in the DTLS handshake matches the identifier used at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device.”, this is good advice. If DTLS PSK and RPK are used, what identifiers does the RD have to check to ensure the DTLS and CoAP layers match? Per 9.1.3.1. (for PSK) and 9.1.3.2.1 (for RPK) of RFC7252 there is the notion of identifiers for DTLS but those don’t manifest in CoAP? Additionally, when DTLS with a certificate is used, is it intended to compare the subjectAltName with the authority in the Registration Base URI (i.e., which exact certificate fields should it compare with the CoAP)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 3.5. Per “When endpoints are not connected … a remote server is usually used to provide proxy access to the endpoints”, this architecture wasn’t entirely clear to me. How can a proxy provide access to an endpoint that isn’t connected? Or is proxy meant as a substitute here or an intermediary? ** Section 3.6. The home and building automation use case doesn’t make any reference to the RD architecture (like the other two use cases). ** Section 4.0. Per “… falling back to failing the operations if recovery is not possible”, can “failing the operation” be clarified? ** Per Section 4.0. Per “An RD MAY make the information submitted to it available to further directories”, are there circumstances where end points would not want that? ** Section 4.1. Per “2. In a network that supports multicast well, …”, what does it mean to “support multicast _well_”? ** Section 5. Per the ep definition of the URI Template Variables, what does it mean for the an endpoint to be “(mostly mandatory)? ** Section 7.1. Per “When certificates are used as authorization credentials, the sector(s) and endpoint name(s) can be transported in the subject”, recommend being more precise on what exact X.509 field(s) you mean when saying “subject”. ** Section 7.1.1. Per “Registrants that are prepared to pick a different identifier when their initial attempt at registration is unauthorized should pick an identifier at least twice as long as the expected number of registrants”, how would a registrant know the population size? ** Section 7.2. Per “To avoid the limitations, RD applications should consider prescribe that lookup clients only use the discovered information as hints, and describe which pieces of information need to be verified with the server”, I wasn’t sure which verification this would be. ** Section 7.3. This section cautions about the differences between the registrant publishes itself vs. what is in the RD. It might be worth reiterating that the RD may also publish what it knows to others per Section 4.0’s “An RD MAY make the information submitted to it available to further directories” ** Editorial Nits -- Global. s/can not/cannot/g -- Section 4. Editorial. Per “Only multicast discovery operations are not possible on HTTP, and Simple Registration can not be executed as base attribute … can not be used there”, this sentence didn’t parse. From nobody Wed Aug 12 00:06:09 2020 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 2840A3A0C9F; Wed, 12 Aug 2020 00:06:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159721596413.8457.13314798043091474779@ietfa.amsl.com> Date: Wed, 12 Aug 2020 00:06:04 -0700 Archived-At: Subject: [core] Erik Kline's Discuss on draft-ietf-core-resource-directory-25: (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, 12 Aug 2020 07:06:04 -0000 Erik Kline has entered the following ballot position for draft-ietf-core-resource-directory-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [[ discuss ]] [ section 4.1.1 ] * Did this get presented to 6man at any point, either via mail to the list or chair or in a presentation slot at an IETF meeting or a 6man interim? I feel confident that there would be no objection to the option as described here, but the working group should have its chance to make an evaluation irrespective of my opinion. --- If this is to be used when link-local methods don't work, another option would have been to add an RD PVD API key and recommend including a PVD option. [ section 4.1.1 & 9.2 ] * Please clarify which ND messages can carry an RDAO. I suspect they should only appear in RAs, but it would be good to state the expectation explicitly. [ Appendix A. ] * Can you explain the ff35:30:2001:db8:1 construction? RFC 3306 section 4 defines some fine-grained structure, and I'm wondering how a group ID of 1 is selected/computed/well known. If there is already a COAP document describing this vis. RFC 3307 section 4.*, perhaps it's worth dropping a reference in here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 1 ] * I'm unclear on what "disperse networks" might mean. [ section 10.1.1 ] * What is meant by "therefore SLAAC addresses are assigned..." followed by this table of not-very-random-looking IPv6 addresses? Is the assumption that there might not be some off-network DNS server but there is some RA with a /64 A=1 PIO? From nobody Wed Aug 12 10:01:12 2020 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 BD6953A03EC; Wed, 12 Aug 2020 10:01:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <159725166775.21744.348589503930840040@ietfa.amsl.com> Date: Wed, 12 Aug 2020 10:01:07 -0700 Archived-At: Subject: [core] Alissa Cooper's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 17:01:08 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-core-resource-directory-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. From nobody Wed Aug 12 10:01:44 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9F3A0DD4; Wed, 12 Aug 2020 10:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=OJbeA0/W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pRH975Id Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBZgGm-kqSvg; Wed, 12 Aug 2020 10:01:41 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360E73A0317; Wed, 12 Aug 2020 10:01:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 58AAA2BD; Wed, 12 Aug 2020 13:01:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 12 Aug 2020 13:01:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p dK0J9fSuMmtHv3X4GK4KsqJ7SjH6/SliOF8uo9Fk/s=; b=OJbeA0/WicZRJPZ9K xb/sYp8zRG3TAOzia+fG4VVgpPZkaAnglA5OxoM169HBCTnI1pCDmMCRx0FDuQi9 uiWh6BFlw4az521AtpvDvtqQ43X3sRi6q/NbbI58wuwSxwpB1zm6gLlEInkZZQTg uN8KLcYYO963A1BmCSKtrLgCVCD7di9CEEmVCmK7xXqyI4g2ZORXPkA9IxVNbZl1 U9PpiYy051KXV1p19QOMRyDMl32H3D9GC03vr1T+MrvHIWK1S2W9cz0Lp7WHIEZ9 xxJh7GsuyjHJPWyJ/tTdf61ra5eeKhtIQCiDoIDKf65ZxDh2mlHoM3lZAO5088Xe /Z2KQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pdK0J9fSuMmtHv3X4GK4KsqJ7SjH6/SliOF8uo9Fk /s=; b=pRH975IdE6Vg8swGmKbuCQv4RWWQZHuYJn4FOgUIwoMMMgMe+tod1odfQ z4y+nsCbpOXV+xx+D9bQHPE373F4nYMNmaJIZdyj1Hqdv7yJxBi+08/tG+3fSUgg DFzvT2AzAco5PgTwcjdALwcX2+KQKOa+0+l/+s2DysyLIxlYolTM/HKn+l9jfOzE 8hDUpOIMYGMAnKLxRvMMFlFImrsNycAeLLMYg9T5UChsvvgsMGibt7mVy0x00uXj 64hpUKOz/mxBR+9NWkAW7x48Pkno7l7QwRK1m0krGfKq4fxP48DLdJNAFBQA7GPQ SSTjsinxzf+24vQsj5qT8x4ubRovw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrledvgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpeefudfhgfetgfetvddvffeiuddtkeffgedvjeejtdeiheefgfelfeeutdel vdfggfenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtud drleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 8975930600DC; Wed, 12 Aug 2020 13:01:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Alissa Cooper In-Reply-To: <159587595578.28258.680109279207698132@ietfa.amsl.com> Date: Wed, 12 Aug 2020 13:01:35 -0400 Cc: gen-art , last-call@ietf.org, core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <21CB1CDE-A9CA-49F1-A402-70A786810931@cooperw.in> References: <159587595578.28258.680109279207698132@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] [Gen-art] Genart telechat review of draft-ietf-core-resource-directory-25 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, 12 Aug 2020 17:01:43 -0000 Thanks Russ. I pointed to your review in my No Objection ballot. Alissa > On Jul 27, 2020, at 2:52 PM, Russ Housley via Datatracker = wrote: >=20 > Reviewer: Russ Housley > Review result: Almost Ready >=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 > Document: draft-ietf-core-resource-directory-25 > Reviewer: Russ Housley > Review Date: 2020-07-27 > IETF LC End Date: 2020-03-31 > IESG Telechat date: 2020-08-13 >=20 > I reviewed -24 on 2020-03-14. The Major Concerns raised in that > review have been resolved. Some Minor Concerns were introduced as > part of the changes. >=20 > Summary: Almost Ready >=20 >=20 > Major Concerns: >=20 > None. >=20 >=20 > Minor Concerns: >=20 > Section 7.1 says: "... can be transported in the subject." I think > you should say "subject field" or "subject name". Do you mean to > exclude the subject alternative name? >=20 > Section 7.1.1 says: >=20 > Registrants that are prepared to pick a different identifier when > their initial attempt at registration is unauthorized should pick an > identifier at least twice as long as the expected number of > registrants; registrants without such a recovery options should pick > significantly longer endpoint names (e.g. using UUID URNs = [RFC4122]). >=20 > I think that the reason for the recommendation on length is to reduce > the likelihood of name collision. However, it is not clear to me why > this is linked in any way to authorization failures on the first > attempt to register. >=20 >=20 > Nits: >=20 > Section 7.1: s/It is immaterial there whether/It is immaterial = whether/ >=20 > Section 8.1: s/address based access/address-based access/ >=20 > IDnits reports: >=20 > =3D=3D There are 3 instances of lines with non-ascii characters in the > document. >=20 > =3D=3D There are 1 instance of lines with multicast IPv4 addresses in = the > document. If these are generic example addresses, they should be > changed to use the 233.252.0.x range defined in RFC 5771 >=20 > =3D=3D There are 3 instances of lines with non-RFC3849-compliant IPv6 > addresses in the document. If these are example addresses, they > should be changed. >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Aug 12 22:16:57 2020 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 341A63A16C6; Wed, 12 Aug 2020 22:16:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <159729581019.30986.4796757249133933498@ietfa.amsl.com> Date: Wed, 12 Aug 2020 22:16:50 -0700 Archived-At: Subject: [core] Martin Duke's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 05:16:50 -0000 Martin Duke has entered the following ballot position for draft-ietf-core-resource-directory-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document was particularly easy to follow and presented ideas in a sensible order. One nit: the sentence that contains “cannot be executed as a base attribute” appears to have been mangled. From nobody Thu Aug 13 00:36:23 2020 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 1C5653A0832; Thu, 13 Aug 2020 00:36:21 -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-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159730418060.12332.7885245575969951169@ietfa.amsl.com> Date: Thu, 13 Aug 2020 00:36:21 -0700 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 07:36:21 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-resource-directory-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with my colleagues who commended the authors for making the document very readable. I support Roman's first two DISCUSS points. In Section 9.2, you might want to mention that you're talking about a sub-registry under "Internet Control Message Protocol version 6 (ICMPv6) Parameters". In Section 9.3, you enumerate six fields in each registration, but the initial table of entries has only five columns. It's obvious (I think) that the sixth column would be "this document" for all entries, but I suggest that you should either include the column or some prose making this explicit (since everything else is). From nobody Thu Aug 13 01:12:05 2020 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 AA8993A0859; Thu, 13 Aug 2020 01:12:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159730632066.12379.5174560093789503034@ietfa.amsl.com> Date: Thu, 13 Aug 2020 01:12:00 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 08:12:01 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-resource-directory-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I agree with Roman that the authorization model seems under-developed. While I recognize that there is need for flexibility across various deployments, I think that we should be providing a default model (and procedures for it) that will apply in many cases, and let deployments specify alternate models if needed. This stuff is hard enough to get right that we should have a secure option that people can use if they don't need to have customized details. (To be clear, I agree with the change of focus from -24 to -25 on the properties that a security policy needs to provide and/or consider, as that is fundamentally the important thing. I just want a fallback/default option that "does something reasonable in most cases" in addition. Doing that by reference to some other existing thing would be fine, if such a thing exists.) In particular, the current text seems to rely on the authorization model including: (1) the RD knowing how clients will be using it (and thus what properties the RD needs to enforce), which in the general case cannot be known (though for static networks it could be), yet I don't see any discussion that indicates this as a prerequisite; and (2) the client either knowing out-of-band that an entity is authorized to act as a RD or just blindly trusting any of the unauthenticated (*) advertisement mechanisms. (* Yes, there may be some protection in the network on subscribing to the relevant multicast address, DNS-SD, etc., but the client cannot a priori know that such protections are in place.) Relatedly, the naming model and naming authority should have some clearer discussion. We do mention in Section 7 the possibility for a weak naming model where the RD is responsible for enforcing uniqueness of names but otherwise link attributes are the primary authorization criteria (vs. a traditional scheme with a naming authority and naming hierarchy), but with naming as a fundamental prerequisite of any authentication/authorization scheme, I think clearer discussion of how a naming model is to be selected (and, perhaps more importantly, that it must be fixed as part of a given deployment) for a given network is needed. If I understand correctly, we have some codepoint squatting going on in the examples (e.g., for resource types). We should talk about the security properties of the various RD discovery mechanisms that are defined. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My apologies for where these comments diverge off into rambling incoherency, or where I'm misunderstanding something that's clearly laid out; this document had the misfortune of being the last one I got to this week. Section 1 [RFC6690] only describes how to discover resources from the web server that hosts them by querying "/.well-known/core". In many constrained scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. nit(?): I'd consider specifying that the RD is "a trusted entity". (Even when the resources themselves are authenticated, a hostile RD can still deny existence of a given resource, so by choosing to use an RD there is some level of trust involved.) Section 2 Resource Directory (RD) A web entity that stores information about web resources and implements the REST interfaces defined in this specification for discovery, for the creation, the maintenance and the removal of registrations, and for lookup of the registered resources. nit: the list structure is not parallel here. Maybe "for discovery, creation, maintenance, and removal of registrations, and for lookup of the registered resources"? Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. Is "the installation of the network" a one-time event? (Might a CT be involved when adding a new device to a network at a later time?) Section 3.1 Information SHOULD only be stored in the RD if it can be obtained by querying the described device's /.well-known/core resource directly. When might that not be the case? Section 3.2 The RD architecture is illustrated in Figure 1. An RD is used as a repository of registrations describing resources hosted on other web servers, also called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port. A physical node may (side note) hmm, I feel like in the HTTP world an endpoint is more likely to be associated with a DNS name than an IP address, in common usage. Also, we later go on to assert that the endpoint's name has primacy and that the IP address/port can be ephemeral. An endpoint uses specific interfaces to register, update and remove a registration. It is also possible for an RD to fetch Web Links from endpoints and add their contents to its registrations. At the first registration of an endpoint, a "registration resource" is created, the location of which is returned to the registering endpoint. The registering endpoint uses this registration resource to manage the contents of registrations. Does the "RD fetches links unilaterally" case count as a "first registration of an endpoint"? I'm having a hard time seeing how these two statements are consistent with each other, and a naive reading admits the possibility that a given endpoint could be "locked out" of the ability to manage the contents of its registrations. Section 4 REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible. In particular, they should retry the request upon "MUST be prepared [...] to the best of their abilities" seems non-actionable. The stuff after "In particular", on the other hand, is actual concrete guidance that could be mandated using normative language. Section 4.1 1. In a 6LoWPAN, just assume the Border Router (6LBR) can act as an RD (using the ABRO option to find that [RFC6775]). Confirmation can be obtained by sending a Unicast to "coap://[6LBR]/.well- known/core?rt=core.rd*". nit(?): I was unaware that "Unicast" was a proper noun. Section 4.3 "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup operations, core.rd* is used to discover all URI paths for RD operations. [...] Is the distinction between URIs (for RD Lookup) and URI paths (for RD) important here? While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement. Clients of the RD SHOULD therefore accept URIs of all schemes they support, both as URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. I'm not sure I see how the "not limit [...] to those hosted at the address used for URI discovery" follows from the non-requirement for expression of the link-targets from discovery in path-absolute form. (Given the ability to send the discovery query to a multicast address, the guidance seems okay; it's just the "therefore" that is puzzling me.) It would typically be stored in an implementation information link (as described in [I-D.bormann-t2trg-rel-impl]): Req: GET /.well-known/core?rel=impl-info This seems to be depicting a link-relation type that is not registered at https://www.iana.org/assignments/link-relations/link-relations.xhtml , i.e., codepoint squatting. Please put in a stronger disclaimer that this is an example link relation type, not just an example exchange. Section 5 These first few paragraphs give the impression that this is first-come-first-served with minimal authentication or authorization checking. Mentioning that there are authorization checks, with a forward-reference, might be helpful. further parameters (see Section 9.3). The RD then creates a new registration resource in the RD and returns its location. The Is this returned "registration resource" expected to function as a "capability URL" (https://www.w3.org/TR/capability-urls/) that would need to contain an appropriate amount of entropy to be reasonably unguessable by parties other than the registrant-ep/CT responsible for it? The registration request interface is specified as follows: Interaction: EP -> RD I thought that the CT could be a requestor as well as the EP. well. The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. What should the RD do if they are set but also present in the accompanying authorization token? Req: POST coap://rd.example.com/rd?ep=node1 Content-Format: 40 Payload: ;ct=41;rt="temperature-c";if="sensor", (side note) XML for the sensors, not SenML? With Carsten as an author, even? ;) An RD may optionally support HTTP. Here is an example of almost the same registration operation above, when done using HTTP. Req: POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1 Host: example.com Wouldn't "Host: rd.example.com" be closer to "almost the same registration"? Section 5.1 I'm a little uneasy about specifying new behavior for POST to the existin /.well-known/core that was defined by RFC 6690 for other uses. What factors go into using the same well-known URI vs. defining a new one for this usage? The sequence of fetching the registration content before sending a successful response was chosen to make responses reliable, and the caching item was chosen to still allow very constrained registrants. I'm not sure what "the caching item" is supposed to be (if it's not a typo/misordering of words). Section 5.3 queries concerning this endpoint. The RD SHOULD continue to provide access to the Registration Resource after a registration time-out occurs in order to enable the registering endpoint to eventually refresh the registration. The RD MAY eventually remove the registration resource for the purpose of garbage collection. If the Registration Resource is removed, the corresponding endpoint will need to be re-registered. (This MAY is actually a MUST for the simple registration case, per §5.1, right?) Section 5.3.1 An update MAY update the lifetime or the base URI registration parameters "lt", "base" as in Section 5. Parameters that are not What about the "extra-attrs"; are they inherently forbidden from updates? base := Base URI (optional). This parameter updates the Base URI established in the original registration to a new value. If the parameter is set in an update, it is stored by the RD as the new Base URI under which to interpret the relative links present in the payload of the original registration, following the same restrictions as in the registration. If the parameter is not set in the request nit: is it the interpretation of relative links that is following the same restrictions as in the registration, or the new value of the parameter being supplied in the update? The following example shows how the registering endpoint updates its registration resource at an RD using this interface with the example location value: /rd/4521. The path component "4521" contains a worryingly small amount of unpredictableness; I would prefer examples that used longer random locations, as for capability URLs. (Throughout the document, of course.) See also draft-gont-numeric-ids-sec-considerations, that I'm AD sponsoring, though I do not see any clear issues on first glance. (Also, it might be worth another sentence that this update is serving just to reset the lifetime, making no other changes, since this might be expected to be a common usage.) Section 6 With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level siblings, would it make sense to put 6.2, or at least 6.3, as subsections under 6.1? Section 6.1 Resource lookup results in links that are semantically equivalent to the links submitted to the RD. The links and link parameters returned by the lookup are equal to the submitted ones, except that the target and anchor references are fully resolved. Are the "submitted ones" the submissions at registration time, or during the lookup query itself? (I assume registration-time, but being explicit costs little.) If the base URI of a registration contains a link-local address, the RD MUST NOT show its links unless the lookup was made from the same link. The RD MUST NOT include zone identifiers in the resolved URIs. Same link as what? Section 6.2 The page and count parameters are used to obtain lookup results in specified increments using pagination, where count specifies how many (We haven't introduced the page and count parameters yet.) operator as in Section 4.1 of [RFC6690]. Attributes that are defined as "link-type" match if the search value matches any of their values Where is it specified how an attribute might be "defined as 'link-type'"? This is the only instance of the string "link-type" in this document, and it does not appear in RFC 6690 at all... references) and are matched against a resolved link target. Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either. The "anchor" attribute is usable for resource lookups, and, if queried, MUST be for in URI form as well. I don't see how it can be only a SHOULD to recognize either given these generation criteria. Section 6.3 The following example shows a client performing a lookup of all resources of all endpoints of a given endpoint type. It assumes that two endpoints (with endpoint names "sensor1" and "sensor2") have previously registered with their respective addresses "coap://sensor1.example.com" and "coap://sensor2.example.com", and posted the very payload of the 6th request of section 5 of [RFC6690]. Er, the 6th request is a GET; do we mean to say the response to the 6th request? Section 6.4 The endpoint lookup returns registration resources which can only be manipulated by the registering endpoint. This seems to leave it unclear whether the endpoint lookup is expected to return resources that the requestor will not have permission to manipulate (in addition to those it does have permission for). While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients. Clients SHOULD NOT attempt to dereference or manipulate them. But why expose them at all if they're not going to be accessible? An RD can report endpoints in lookup that are not hosted at the same address. [...] The "same address" as what? Section 7.1 Whenever an RD needs to provide trustworthy results to clients doing endpoint lookup, or resource lookup with filtering on the endpoint How will the RD know whether the client is expecting trustworthy results? (When would a client *not* expect trustworthy results?) name, the RD must ensure that the registrant is authorized to use the given endpoint name. This applies both to registration and later to operations on the registration resource. It is immaterial there whether the client is the registrant-ep itself or a CT is doing the registration: The RD can not tell the difference, and CTs may use I suppose there might be plausible authorization models where a return-routability check to a given address constitutes authorization to use that address as an endpoint name, in which case the RD can tell the difference between a registrant-ep and a CT attempting to act on its behalf. When certificates are used as authorization credentials, the sector(s) and endpoint name(s) can be transported in the subject. In an ACE context, those are typically transported in a scope claim. As Russ noted in the Gen-ART review, "transported in the subject" is sufficiently vague to not really be actionable. It might be better to say that the holder of the private key corresponding to the public key certified in the certificate is generally considered authorized to act on behalf of any identities (including endpoint names) contained in the certificate's subject name. Section 7.1.1 Conversely, in applications where the RD does not check the endpoint name, the authorized registering endpoint can generate a random number (or string) that identifies the endpoint. The RD should then How much entropy/randomness in the random name? Does a CSPRNG need to be used? (I do see the follow-up about doubling the length in case of failure or starting with a UUID if that's not possible, but some guidance on where to start still seems appropriate.) Section 7.2 When lookup clients expect that certain types of links can only originate from certain endpoints, then the RD needs to apply filtering to the links an endpoint may register. As before, how will the RD know what behavior clients are relying on? An RD may also require that only links are registered on whose anchor (or even target) the RD recognizes as authoritative of. One way to I don't think I can parse this sentence (especially "the RD recognizes as authoritative of"). Section 8 In contexts where we discuss DTLS and TLS as being generally comparable, we typically will state that DTLS replay protection is required in order to provide equivalent levels of protection. We might also want to reiterate or refer back to the previous discussion of the potential for attributes or resource/endpoint names, link relations, etc. that may need to be confidential, the relevant access control/filtering, and the avenues by which disclosure of resource names can occur even when access to those resources will not be permitted. (I think some of this overlaps with 8288 and 6690, but don't mind repeating it.) Section 8.1 It's probably worth reiterating that all name comparisons must be done at sector scope (since failing to do so can lead to attacks). Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (Section 7.1) or whether arbitrary names are accepted (Section 7.1.1). I think this is more properly authorization than authentication. Section 8.3 attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. An RD which (It's not clear to me why the specific discussion of NTP numbers is relevant here, since RD is not NTP.) Section 9.3 Should we also include "rt" in the initial entries? I see it is used as a query parameter for resource lookup in the examples in Section 6.3. * indication of whether it can be passed as a query parameter at registration of endpoints, as a query parameter in lookups, or be expressed as a target attribute, (Since this text does not clarify about lookup of endpoints vs. resources... Review" as described in [RFC8126]. The evaluation should consider formal criteria, duplication of functionality (Is the new entry redundant with an existing one?), topical suitability (E.g. is the described property actually a property of the endpoint and not a property of a particular resource, in which case it should go into the payload of the registration and need not be registered?), and the ... and this text suggests that query parameters for *resource* lookups need not be registered.) potential for conflict with commonly used target attributes (For example, "if" could be used as a parameter for conditional registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered endpoint property or the [RFC6690] target attribute). Then why do we use it as an example of lookup filtering in Section 6.2? Section 10.1.2 Should we really be using unregistered resource types (i.e., codepoint squatting) in the examples? After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. Just to check: the luminaries are learning their own group membership by querying the resource directory? Section 10.2.2 Please expand MSISDN. Section 13.2 I think RFC 7252 should probably be normative. Likewise for RFC 8288 ("the query parameter MUST be [...] a token as used in [RFC8288]"). From nobody Thu Aug 13 05:44:45 2020 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 5CB033A0BEA; Thu, 13 Aug 2020 05:44:43 -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-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159732268335.29656.5724379569570361825@ietfa.amsl.com> Date: Thu, 13 Aug 2020 05:44:43 -0700 Archived-At: Subject: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 12:44:43 -0000 Robert Wilton has entered the following ballot position for draft-ietf-core-resource-directory-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy. Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: 5.3. Operations on the Registration Resource An endpoint should not use this interface for registrations that it did not create. This is usually enforced by security policies, which in general require equivalent credentials for creation of and operations on a registration. What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate? Would the updated endpoint expect to be able to update the registration? Or would it have to wait for the existing registration to timeout (which could be a long time)? 5.3. Operations on the Registration Resource The Registration Resource may also be used cancel the registration using DELETE, and to perform further operations beyond the scope of this specification. These operations are described below. Nit: Perhaps reword the second sentence. Otherwise it seems to conflict with the last sentence of the prior paragraph. 5.3.1. Registration Update The update interface is used by the registering endpoint to refresh or update its registration with an RD. To use the interface, the registering endpoint sends a POST request to the registration resource returned by the initial registration operation. An update MAY update the lifetime or the base URI registration parameters "lt", "base" as in Section 5. Parameters that are not being changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in Section 5. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT". In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration. I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. 5.3.1. Registration Update Req: GET /rd-lookup/res?ep=endpoint1 Res: 2.05 Content Payload: ;ct=41; rt="temperature-c";if="sensor"; anchor="coap://local-proxy-old.example.com:5683/", ; anchor="coap://local-proxy-old.example.com:5683/sensors/temp"; rel="describedby" Figure 14: Example lookup before a change to the base address Just to check, is it correct that the anchor in the http link is also to coap://? If this is wrong then there is a second example in the same section that also needs to be fixed. Regards, Rob From nobody Thu Aug 13 06:03:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1C3A0C04; Thu, 13 Aug 2020 06:03:33 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojJgbjvTz4m8; Thu, 13 Aug 2020 06:03:33 -0700 (PDT) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (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 8D4EE3A0C03; Thu, 13 Aug 2020 06:03:32 -0700 (PDT) Received: by mail-il1-f181.google.com with SMTP id q14so2013023ilm.2; Thu, 13 Aug 2020 06:03:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tgl5OzMhxjQrRuJVjxXg6hm94ryoBTFkZp8o5oERLTQ=; b=cMWNDU8hagd40qmfiekRbFk1Eb88ICxqRAD5iCpG2p/fseaKettIyWNDWJCaddhrhR 2LtHdrAydgjitVpNsvDB/VDMH5A1nGSFaHS2DLdMR95+L31sKME5+RZ+avBHJCZPcRj0 yKWx9j6PtHdOTjJ9cURO2mAz4hNbxYtEfVyWPUh4RvVvHiqf3filtuTh4bpok8eF4xjD wMX9pMwfhKCB7TOpNUyKPxiWTw5UlFLf5KwrY+Dw9b+5SGJLIHMmVTTNGvbN+Ys+ZzZT tizWijaDvghoOg7apCwEuF/sqAIp3MsEReQY+5lCrn+4Xlg9Wra90aPJks4tV/8ZfufL cwSg== X-Gm-Message-State: AOAM531CDlPYRZ9+gKbLGp9XpE5I6zjV2Lk0jQOuD376ArOj20ygpKjw E7rVERH7TbLKsf8QxXEtPjJ+yxBd719gMXuiRiLAeg== X-Google-Smtp-Source: ABdhPJzJVSgeoWK7Pmaq1iHiblWcO4zJ8i5YLWNGa8ErKeh3tqvolYS7MKz7hRk7S3Qh93o5uvq08cC7QJUTwfN+uBc= X-Received: by 2002:a92:9a48:: with SMTP id t69mr3276536ili.114.1597323811599; Thu, 13 Aug 2020 06:03:31 -0700 (PDT) MIME-Version: 1.0 References: <159732268335.29656.5724379569570361825@ietfa.amsl.com> In-Reply-To: <159732268335.29656.5724379569570361825@ietfa.amsl.com> From: Barry Leiba Date: Thu, 13 Aug 2020 09:03:20 -0400 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , jaime.jimenez@ericsson.com, core-chairs@ietf.org, core WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 13:03:34 -0000 > 5.3.1. Registration Update > > The update interface is used by the registering endpoint to refresh > or update its registration with an RD. To use the interface, the > registering endpoint sends a POST request to the registration > resource returned by the initial registration operation. > > An update MAY update the lifetime or the base URI registration > parameters "lt", "base" as in Section 5. Parameters that are not > being changed SHOULD NOT be included in an update. Adding parameters > that have not changed increases the size of the message but does not > have any other implications. Parameters MUST be included as query > parameters in an update operation as in Section 5. > > The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as > "MAY NOT". In many cases, if the configuration is not too big then providing > the full configuration makes it easy to guarantee that the receiver has exactly > the correct configuration. I appreciate that there are many cases where from > an endpoint perspective it may want to keep the update small, but if I was > doing this from a CT, I think that I would rather just resend the entire > configuration, if it is not large. "MAY NOT" is not a BCP 14 key word, and isn't a clear phrasing anyway. The way to downgrade the strength here is to change "SHOULD NOT" to "should not". But keep in mind that this stuff is intended for constrained environments, and it might be more important than you think to keep message sizes down to a minimum. That's the reason for the BCP 14 "SHOULD NOT". Barry From nobody Thu Aug 13 06:43:54 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFBA3A0C5D; Thu, 13 Aug 2020 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LBT3mMqz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ttRXAEy2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52RBAk99sYoW; Thu, 13 Aug 2020 06:43:41 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1441E3A0C44; Thu, 13 Aug 2020 06:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4168; q=dns/txt; s=iport; t=1597326221; x=1598535821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S5oL4iNzgcR7i5SsZo6qNkeMnYk5aHs+U/48oonPiFI=; b=LBT3mMqz+DL+iXMo7uGRuWdEo5FGe8wz198U9aTlowXcPs5gDb+oktXQ Fsj5ITyBr/FQDVILQdGVOrTsl9G6YUlk28IyVUs8GA9d+pGPciDVZCbJE 4pTlkgEtFmeFHbkMxIS0jic3i5bSZUbi+TBmdrBwodjCCo1LfUMVGXUNh s=; IronPort-PHdr: =?us-ascii?q?9a23=3AD8lcQxIWa6WNz+izh9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv60/h1jMRZjH5ugCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS835YkXPvnCoqzkIFU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQARQzVf/4cNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYFRUQeBSC8sCoQsg0YDjVmYZ4JTA1ULAQEBDAE?= =?us-ascii?q?BLQIEAQGETAIXgikCJDcGDgIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQMBEhE?= =?us-ascii?q?RDAEBNwELBAIBCBEEAQEDAiYCAgIwFQgIAgQOBQgahVADDiABpmwCgTmIYXa?= =?us-ascii?q?BMoMBAQEFhSQYgg4JgQ4qAYJwg2CGQBqBQT+BEUOCTT6EP4MVM4ItkkM8hwe?= =?us-ascii?q?cJgqCYpo9gn6dF5QgnUoCBAIEBQIOAQEFgWkkgVdwFYMkUBcCDY4fN4M6ilZ?= =?us-ascii?q?0NwIGAQkBAQMJfI8bAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,308,1592870400"; d="scan'208";a="525651946" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 13:43:40 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DDhdiK015116 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 13:43:39 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:43:39 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 09:43:38 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 08:43:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M54MjZa323VHeh2vA7VorzlFSylulIWuKyWdzvwg5TW36tMXIHBSzyREHXoF5Tr44YlXDEntdNjqSU8NbgfzwVbxGEsSYuNUMdaUsc/UZqfEb2E2VTGKG4moe095YC3N7cRbsUbmvodWUKw8FEsTL7aELLeEAf/HBpIZuEgVH7xDactzhlw4TQ6NGz6uX5bFkO9u6PeEVh0WrpY/H2wRe3rwh9OmezzWF/gbnPikiK4UIwdNsp8Hj2MvRu3LBS5SPFDLlCq7kJjxIy6TrUWItHQ9NzPtQhgSqGBYiWne/t+yni7Zmf1LA/zXmRY3C3ns6grRlRxfbYgTYRGojGkGww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S5oL4iNzgcR7i5SsZo6qNkeMnYk5aHs+U/48oonPiFI=; b=D/eVV9d3ZvUnLwijo5SiE7xOu4l1x0/k4v4ExJzKlgqr8/fXKAt39g6qM0XU51hhBLiLbrgrjcUoJtoEy4mGKtuB+v4t7RgyF+XqjyiYuX+JzPnKvSIPLD8gQydK3mbBrK9f8N8nD/XMO1dM40F3kiN0zrGlP048qI8ly0nrBzEj1fmlK5Tpdq7DPT99+FT/hNSfHPafM8c39fkU59qP569uspheRQINjenUF0zxQeVeZsXdsy8b2MOJF0iD+96SFDbb/qJnsTGzHQBp5ICQW457X1S5BYbJnNfSxtZMGzasnfn7LTjUA1kKKV61uqrRH/qcwo6ezsbpKwXX0sMkNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S5oL4iNzgcR7i5SsZo6qNkeMnYk5aHs+U/48oonPiFI=; b=ttRXAEy2q/M9PHPpV4QjfDvuAxX0CW/hYpXIGfjMlRB8ktCmQA6WaNlG0rq3BxlJrG+Ohz4z5DbLkslqV5Eht3w9VDLoWvK/LMqbLXqWeYW/2RVAVtbpOQMt3cDoDF8P0ToxPRmQnP4s0DoT3tO3CL3Zbtqyd4KwaQXpq1RLYro= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB2964.namprd11.prod.outlook.com (2603:10b6:208:7c::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Thu, 13 Aug 2020 13:43:37 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3261.025; Thu, 13 Aug 2020 13:43:37 +0000 From: "Rob Wilton (rwilton)" To: Barry Leiba CC: The IESG , "draft-ietf-core-resource-directory@ietf.org" , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "jaime.jimenez@ericsson.com" , "core-chairs@ietf.org" , core WG Thread-Topic: Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) Thread-Index: AQHWcXI0XoZQoPbXNEekdIBmxeneMKk2A/9w Date: Thu, 13 Aug 2020 13:43:36 +0000 Message-ID: References: <159732268335.29656.5724379569570361825@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.25] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b39d0585-a634-442e-9b30-08d83f8ee158 x-ms-traffictypediagnostic: BL0PR11MB2964: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RJEop4GFeV4y37eLyQfvEQ2kAMheeNT5xG75lKTah2eeQD5hHetoxq/Yae5YRLJc5KyExARlm9tZ9f6mo2I067OBIQd2iaTR6KsvTjAdAy0iG1li6rCk6p1r7S9+eJLo/QyarGbwwnBr4tCrv4Oo4DnlfEmzTPDn+af8PkmMvG5ohT+FvvsPtLWbg/Wj2GhD6e7zXi99REjIznuKGdWt4BwrGSvsrjFq27pt4gMlv0WyVivAGXiv/PfdEIUsatLO4OobT5fQwpfsMlSoIP5EwzrcFMQ95foq7G0OFOCHa8fZ7sVJNSocExFg1ZXgkiDsFfkNjDkIecwf7vkdu4ZGvQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(9686003)(53546011)(6916009)(478600001)(8936002)(4326008)(316002)(6506007)(5660300002)(2906002)(186003)(8676002)(66556008)(66476007)(66446008)(52536014)(66946007)(76116006)(66574015)(71200400001)(86362001)(83380400001)(54906003)(7696005)(55016002)(33656002)(64756008)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0Z2e0zzIo2upGK/ZWRg7OfwZo/VoRYmVNi5cBB0QbmJxEweHqCms6dWmLJtmKXVZO3m+sr4b/q3WAf0os0/Prt7YH/0M3OJ+xJ3N/88Ad2cR6LBWUVDSFRTUXctwrTkvucaBq/YQYAoyDfb+089dyNGrSaEb7kfkV2UqoeBzEginwcFK9NS4G2SfL3O+cfAM/mvCRUNUXmkvouW3AJCqCdChCd6zs3iy2xk5Zn9GUV9v9vfCU5HvPG44MoI0oH1n+ALudwdTKeAIxrOfGxSuDetNrEh1ueOdRjIjTlDiTehsELoAu1zymsi2Y4qGokskpc3SSu+vR5dkRf7E/Si+LpgweJ333SkUhK6gZxH2Hs+eYgJH3GW04OD9JEEdnE5WIW+SR65J5u/XZFc9VBiNwt91DijRTr0gi2cA77WzawCE6vBsZ1q38mpv74Qbab7ONKaVaQjvhjhicXWSF0rRgIubUCMhPRG6NwVpnM4AIVmyzIm9OYcaReFbzrj4pcAobS8mDh0gLLNBVR669ShlgS9/wFmtDr7yznQ6OqAsWmBXGlewUTNqz2n3sdOKIx490y+D8qurZhyBMStyJ3gpsvODWSUD73C1nKteGs2TgNI6sXdkYLF9ECIApaHZRYTRyhwjDGhqSM7nmFMM3CVbjQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b39d0585-a634-442e-9b30-08d83f8ee158 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:43:36.8393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NKYYgK18Ra9ipXIEqGqAfC6UlNLYXGEKqv85bS4qhGgICSsJHibZoDmRELZ1PrFW5XcsiyZMYLRSsAT9RBgOyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2964 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 13:43:50 -0000 SGkgQmFycnksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmFycnkg TGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPiBTZW50OiAxMyBBdWd1c3QgMjAyMCAx NDowMw0KPiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KPiBD YzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtZGly ZWN0b3J5QGlldGYub3JnOw0KPiBKYWltZSBKaW3DqW5leiA8amFpbWVAaWtpLmZpPjsgamFpbWUu amltZW5lekBlcmljc3Nvbi5jb207IGNvcmUtDQo+IGNoYWlyc0BpZXRmLm9yZzsgY29yZSBXRyA8 Y29yZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFJvYmVydCBXaWx0b24ncyBObyBPYmplY3Rp b24gb24gZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLQ0KPiBkaXJlY3RvcnktMjU6ICh3aXRoIENP TU1FTlQpDQo+IA0KPiA+ICAgICA1LjMuMS4gIFJlZ2lzdHJhdGlvbiBVcGRhdGUNCj4gPg0KPiA+ ICAgICAgICBUaGUgdXBkYXRlIGludGVyZmFjZSBpcyB1c2VkIGJ5IHRoZSByZWdpc3RlcmluZyBl bmRwb2ludCB0bw0KPiByZWZyZXNoDQo+ID4gICAgICAgIG9yIHVwZGF0ZSBpdHMgcmVnaXN0cmF0 aW9uIHdpdGggYW4gUkQuICBUbyB1c2UgdGhlIGludGVyZmFjZSwgdGhlDQo+ID4gICAgICAgIHJl Z2lzdGVyaW5nIGVuZHBvaW50IHNlbmRzIGEgUE9TVCByZXF1ZXN0IHRvIHRoZSByZWdpc3RyYXRp b24NCj4gPiAgICAgICAgcmVzb3VyY2UgcmV0dXJuZWQgYnkgdGhlIGluaXRpYWwgcmVnaXN0cmF0 aW9uIG9wZXJhdGlvbi4NCj4gPg0KPiA+ICAgICAgICBBbiB1cGRhdGUgTUFZIHVwZGF0ZSB0aGUg bGlmZXRpbWUgb3IgdGhlIGJhc2UgVVJJIHJlZ2lzdHJhdGlvbg0KPiA+ICAgICAgICBwYXJhbWV0 ZXJzICJsdCIsICJiYXNlIiBhcyBpbiBTZWN0aW9uIDUuICBQYXJhbWV0ZXJzIHRoYXQgYXJlIG5v dA0KPiA+ICAgICAgICBiZWluZyBjaGFuZ2VkIFNIT1VMRCBOT1QgYmUgaW5jbHVkZWQgaW4gYW4g dXBkYXRlLiAgQWRkaW5nDQo+IHBhcmFtZXRlcnMNCj4gPiAgICAgICAgdGhhdCBoYXZlIG5vdCBj aGFuZ2VkIGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgbWVzc2FnZSBidXQgZG9lcw0KPiBub3QN Cj4gPiAgICAgICAgaGF2ZSBhbnkgb3RoZXIgaW1wbGljYXRpb25zLiAgUGFyYW1ldGVycyBNVVNU IGJlIGluY2x1ZGVkIGFzDQo+IHF1ZXJ5DQo+ID4gICAgICAgIHBhcmFtZXRlcnMgaW4gYW4gdXBk YXRlIG9wZXJhdGlvbiBhcyBpbiBTZWN0aW9uIDUuDQo+ID4NCj4gPiBUaGUgIlNIT1VMRCBOT1Qi IGZlZWxzIGEgYml0IHN0cm9uZyB0byBtZSwgYW5kIEkgd291bGQgcHJlZmVyIHRvIHNlZQ0KPiB0 aGlzIGFzDQo+ID4gIk1BWSBOT1QiLiAgSW4gbWFueSBjYXNlcywgaWYgdGhlIGNvbmZpZ3VyYXRp b24gaXMgbm90IHRvbyBiaWcgdGhlbg0KPiBwcm92aWRpbmcNCj4gPiB0aGUgZnVsbCBjb25maWd1 cmF0aW9uIG1ha2VzIGl0IGVhc3kgdG8gZ3VhcmFudGVlIHRoYXQgdGhlIHJlY2VpdmVyIGhhcw0K PiBleGFjdGx5DQo+ID4gdGhlIGNvcnJlY3QgY29uZmlndXJhdGlvbi4gIEkgYXBwcmVjaWF0ZSB0 aGF0IHRoZXJlIGFyZSBtYW55IGNhc2VzIHdoZXJlDQo+IGZyb20NCj4gPiBhbiBlbmRwb2ludCBw ZXJzcGVjdGl2ZSBpdCBtYXkgd2FudCB0byBrZWVwIHRoZSB1cGRhdGUgc21hbGwsIGJ1dCBpZiBJ DQo+IHdhcw0KPiA+IGRvaW5nIHRoaXMgZnJvbSBhIENULCBJIHRoaW5rIHRoYXQgSSB3b3VsZCBy YXRoZXIganVzdCByZXNlbmQgdGhlIGVudGlyZQ0KPiA+IGNvbmZpZ3VyYXRpb24sIGlmIGl0IGlz IG5vdCBsYXJnZS4NCj4gDQo+ICJNQVkgTk9UIiBpcyBub3QgYSBCQ1AgMTQga2V5IHdvcmQsIGFu ZCBpc24ndCBhIGNsZWFyIHBocmFzaW5nIGFueXdheS4NCj4gVGhlIHdheSB0byBkb3duZ3JhZGUg dGhlIHN0cmVuZ3RoIGhlcmUgaXMgdG8gY2hhbmdlICJTSE9VTEQgTk9UIiB0bw0KPiAic2hvdWxk IG5vdCIuDQpbUlddIA0KDQpZZXMsIHNvcnJ5LCBJIHdhcyB0cnlpbmcgdG8gZ2V0IHRoZSBjb21t ZW50cyBpbiBiZWZvcmUgdGhlIHRlbGVjaGF0Lg0KDQpJIHN0aWxsIHRoaW5rIHRoYXQgInNob3Vs ZCBub3QiIGlzIHByb2JhYmx5IGEgYml0IHN0cm9uZyBpbiB0aGUgY2FzZSB0aGF0IHNheSB0aGUg Y2xpZW50IGlzIGEgY29tbWlzc2lvbmluZyB0b29sLiAgUGVyaGFwcyBtYWtlIHRoZSBjb25zdHJh aW50IGNvbmRpdGlvbmFsIG9uIHdoZXRoZXIgYW4gZW5kcG9pbnQgaXMgZG9pbmcgdGhlIHVwZGF0 ZT8NCg0KV2hpbHN0IGxvb2tpbmcgYXQgdGhpcyBhIHNlY29uZCB0aW1lLCBpdCB3YXMgYSBiaXQg dW5jbGVhciB0byBtZSB3aGV0aGVyIHVzaW5nIGEgImNvbW1pc3Npb25pbmcgdG9vbCIgaXMgYSBv bmUgb2ZmIHRoaW5nIChhcyBjb3VsZCBiZSBpbXBsaWVkIGJ5IGl0cyBuYW1lKSwgb3Igd2hldGhl ciBpdCB3b3VsZCBhbHNvIHBlcmlvZGljYWxseSB1cGRhdGUgdGhlIHJlc291cmNlIGRpcmVjdG9y eSAodG8gc3RvcCB0aGUgcmVnaXN0cmF0aW9uIGVudHJpZXMgZnJvbSBldmVudHVhbGx5IHRpbWlu ZyBvdXQpPw0KDQoNCj4gDQo+IEJ1dCBrZWVwIGluIG1pbmQgdGhhdCB0aGlzIHN0dWZmIGlzIGlu dGVuZGVkIGZvciBjb25zdHJhaW5lZA0KPiBlbnZpcm9ubWVudHMsIGFuZCBpdCBtaWdodCBiZSBt b3JlIGltcG9ydGFudCB0aGFuIHlvdSB0aGluayB0byBrZWVwDQo+IG1lc3NhZ2Ugc2l6ZXMgZG93 biB0byBhIG1pbmltdW0uICBUaGF0J3MgdGhlIHJlYXNvbiBmb3IgdGhlIEJDUCAxNA0KPiAiU0hP VUxEIE5PVCIuDQpbUlddIA0KDQpZZXMsIGJ1dCBpcyBhIGNvbW1pc3Npb25pbmcgdG9vbCBhbHNv IHNpbWlsYXJseSBjb25zdHJhaW5lZD8gIEkgd2FzIGFzc3VtaW5nIHRoYXQgaXQgd2FzIHRoZSBl bmRwb2ludCBkZXZpY2VzIGFuZCB0aGUgbmV0d29yayBhY2Nlc3MgdG8gdGhvc2UgZW5kcG9pbnQg ZGV2aWNlcyB0aGF0IHdhcyBtb3N0IGxpa2VseSB0byBiZSBjb25zdHJhaW5lZC4NCg0KUmVnYXJk cywNClJvYg0KDQo+IA0KPiBCYXJyeQ0K From nobody Thu Aug 13 11:13:12 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC14F3A0F53; Thu, 13 Aug 2020 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njlbrZgiRUv3; Thu, 13 Aug 2020 11:12:56 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6343A0F70; Thu, 13 Aug 2020 11:12:54 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DICgtZ030517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 14:12:44 -0400 Date: Thu, 13 Aug 2020 11:12:42 -0700 From: Benjamin Kaduk To: Robert Wilton Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20200813181242.GA92412@kduck.mit.edu> References: <159732268335.29656.5724379569570361825@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159732268335.29656.5724379569570361825@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:12:58 -0000 On Thu, Aug 13, 2020 at 05:44:43AM -0700, Robert Wilton via Datatracker wrote: > 5.3. Operations on the Registration Resource > > An endpoint should not use this interface for registrations that it > did not create. This is usually enforced by security policies, which > in general require equivalent credentials for creation of and > operations on a registration. > > What happens if an endpoint is managing the registration and is upgraded to new > hardware with a different certificate? Would the updated endpoint expect to be > able to update the registration? Or would it have to wait for the existing > registration to timeout (which could be a long time)? Generally the authorization information in the certificate is just stored in the subject (i.e., subjectAltName) of the certificate, so a new certificate for the same name would pass the same authorization checks (i.e., be "equivalent credentials"). -Ben From nobody Thu Aug 13 11:18:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC1D3A101E; Thu, 13 Aug 2020 11:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=X0ZSD1FG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SFvOZf9T Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45tDP8tujmMC; Thu, 13 Aug 2020 11:18:45 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9A63A1002; Thu, 13 Aug 2020 11:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1540; q=dns/txt; s=iport; t=1597342725; x=1598552325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oV4Uhp02zsaGRlzhYG89YZqQ78Bcoay5+v1l1GkiLGg=; b=X0ZSD1FGpHS66Vbw5Fdo3YgE/HSrSL9szRkpeXlqyCX8l1Oa0ynkLjz1 sBSwSb6glpA4CnmcS1eT1MOuWoMKcMYQKqdLcssgPOIpqD2xsN8UjKIry tfow+2w0D+B18maipFjRK96KDLjQycfwGb5PWkTPIMkB2nhkHIWAn/S4q 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ARbfAFBY0/3TjhOUYBtawCPP/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD4Da97RJh/eF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGHcfiIVDevy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAQBggzVf/4kNJK1fDg0BAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgUqBUlEHgUgvLAqHcgONWphnglMDVQsBAQEMAQE?= =?us-ascii?q?tAgQBAYRMAoJAAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQQSKAYBATc?= =?us-ascii?q?BCwQCAQgRBAEBAR4QMh0IAgQOBQgahVADLgGndQKBOYhhdIE0gwEBAQWFLBi?= =?us-ascii?q?CDgmBOIJxiiAagUE/gRFDgk0+hC4Rg0iCLZJDh0OcJgqCYpo9gn6dF5QgnUo?= =?us-ascii?q?CBAIEBQIOAQEFgWojgVdwFYMkUBcCDY4fDBcUgzqKGD50NwIGCgEBAwl8jXK?= =?us-ascii?q?BMwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,309,1592870400"; d="scan'208";a="558565476" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 18:18:44 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DIIit0026175 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 18:18:44 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 13:18:44 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 14:18:43 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 13:18:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gpGNHGzbjIpjlPxcj01N4qSm3WNFDKnz84pg3EvAFKnwos7lmNBTX2smvqW28u1Zo8FtoRkA60r5dFFP9iFcvNTFShZ7D+4kigVYbu8h9q6+6S8lx5o+HlskeEvSLaH4MEDhsNVzJXTAZTh5XjvDDDyRV7SvD4IZrpmfoBdpuf5hBLpnDgbDVk1+MyDFtEUNpvOd3Z2EhOpeCBqiCxk6Xa9FxA7xiENSR94A49Xx02BWMCBr8WlODTE8q7LD0J0Tp/eZly4FEKycWmGf9BeoK+5ZGCriJZ8CUz5nzvLYcFLi6NEqSxY8aHYp5wPdH6UcYmkljApxljNU1vjCm9MOkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hr5MnSSE7geH5byLGgt+j9Q6kMzHEV1PVq00pzBbeMc=; b=YrUWL0+N39wU/dnj0PVdYqn34fmQHl1lWTRV/DQXLonPdWI390cleZgs7VtmuWE6BEMAXjL0JOZQTPEkpw0qZ4O5L0jF01xyTR20MWI7t14qbwQ3fi6DrknTJasjeTnCXxLmKZusQ29LsnLo2sRpYZzfn9G5EajnDBDC0j5Wd5zQYOr8WQr6FZAJCZIluwy5827elKMYFDCyuxoZgf+w+CbrP5HWps66VpzWCnde7V/ARxiOr/CAyIVTFnwILd4MyDQczmtJ49/Nz3Ako2PudEnIPRO7ff1a0HE2ucHWT3cRVhOXJJfb8nJbW0KIuB2id6hGR8UeA77GCYySkPC4gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hr5MnSSE7geH5byLGgt+j9Q6kMzHEV1PVq00pzBbeMc=; b=SFvOZf9TJaQKytxfQSeGi/tHb2I5cLtszBWTO/SL81GcNk0azk3rbVcdrKjN6VXdavbjaNdNawvjuTIgx6j17cwORIQKztoFIlaIh2MNCAUNBBgta+06pC4H83d3Film2QwjPjg7CNi7ZGaQEylvrXhVBvNWGFLmgkp0/R4MHJs= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4533.namprd11.prod.outlook.com (2603:10b6:208:264::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Thu, 13 Aug 2020 18:18:42 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3261.025; Thu, 13 Aug 2020 18:18:42 +0000 From: "Rob Wilton (rwilton)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-core-resource-directory@ietf.org" , "jaime@iki.fi" , "jaime.jimenez@ericsson.com" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) Thread-Index: AQHWcZ1fKy1c8KgRNU2XAzyuvxbg7ak2WQDQ Date: Thu, 13 Aug 2020 18:18:42 +0000 Message-ID: References: <159732268335.29656.5724379569570361825@ietfa.amsl.com> <20200813181242.GA92412@kduck.mit.edu> In-Reply-To: <20200813181242.GA92412@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.25] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49aca769-9883-42ad-d623-08d83fb54f5a x-ms-traffictypediagnostic: MN2PR11MB4533: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /gSTpNiBA9GmrByBt2GBWeDnL7QkP3+Fy0z2VMsf8Qk4+/t0m+/F/gHTfF4L0i0afQJj5+tl9b49QWT2N0ND32P1kmn/GrmuaWZqbdqILNjF2c5k4aNn9yAb7ZMQSgJqyZ2SS/GwMrHAdzDPzRoxJ0bdve2tMepY5yIU7VGwszu/iB3lnNBabsppdawI6MCe2RMJZ61K9AKCxnqPGjAVT+DBpmxIT4dTveJYXpoqUK0+W0s9Z7yUa5y1CPp5WuM9kJrPlXAfrPm/Wqsb3VjHiYDe4jKY5Q07ZxQ3kHzJjVyhmZte2iFLby4CtXeF/YVGLQQrRY/MoJ4XBrISeg8SIw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(376002)(346002)(366004)(71200400001)(7696005)(8936002)(9686003)(26005)(86362001)(54906003)(53546011)(64756008)(478600001)(6506007)(186003)(8676002)(4326008)(76116006)(316002)(66446008)(2906002)(66476007)(66946007)(66556008)(6916009)(52536014)(33656002)(5660300002)(83380400001)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WLVLIe4MjOPu8t8e/xS7NGomWqvZ68LZXGDyfw9NIVB+FTPZdREiu2WdQHYDpFhce6BnNqykYaW4jCYIju5LZQMrQxzBklv2VeVu3j8uZPqp6QGhVy+XnzR229LcAZQcWds++7hp8S+R/tGoLINkuUEPK91/yOZno4LYcT6nHNCq5n4MXC4DcHrjAVTiyNffACuoDIK0E/EZYs+5zCSopa9Qazbv82o3Jfoci7UIV8RUq1uExQyOt6pbE+rN4sTnvKuAHl+iBX0WIIOEGzIuI8UdydCjjXUGl0QVw6Fw/b0AoBf5YJLvZHyPGH/JxW/iSlhQUWc7axVJyDIv9q1Jtaa2wbTHIyzcl22MWX9gAtxIrpgzYB5lgz++JZtMXMPwxjrUqiqBIwhy47aKPZKvweACpuP8pMzUN2JSznOn69vV/HRVaTqpWU283QMJQdodiuZXhv60NayaxkFPlAsd9mgRTK7+LkSTVa/f+4A4ir9DxAx1fyuqwj+/HT3r+ROctzMDucQedBcQ8rUoCuLxJDN6M4yp8mKSJbv8NxHKmdILlRgljRFcocrndXFUO8ll8azkhEX4nRkSg3Krpic2GYzwfy/4SyY1zTsCejimr4hIsNtmwvbGGvUlb4172gu5UvuBab9nrng2LaZKPeDAFQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49aca769-9883-42ad-d623-08d83fb54f5a X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 18:18:42.3740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jNH2rQeYdoh88aGgV0OvHyG7atFAzdR5atNgAuUCtOCKYGEb5wbjY8OFRojSEur6P4No+mI/JJNqmQc3NJBRpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4533 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:18:48 -0000 Ben,=20 Thank you for the clarification/explanation. Regards, Rob > -----Original Message----- > From: Benjamin Kaduk > Sent: 13 August 2020 19:13 > To: Rob Wilton (rwilton) > Cc: The IESG ; draft-ietf-core-resource-directory@ietf.org= ; > jaime@iki.fi; jaime.jimenez@ericsson.com; core-chairs@ietf.org; > core@ietf.org > Subject: Re: Robert Wilton's No Objection on draft-ietf-core-resource- > directory-25: (with COMMENT) >=20 > On Thu, Aug 13, 2020 at 05:44:43AM -0700, Robert Wilton via Datatracker > wrote: > > 5.3. Operations on the Registration Resource > > > > An endpoint should not use this interface for registrations that > it > > did not create. This is usually enforced by security policies, > which > > in general require equivalent credentials for creation of and > > operations on a registration. > > > > What happens if an endpoint is managing the registration and is upgrade= d > to new > > hardware with a different certificate? Would the updated endpoint > expect to be > > able to update the registration? Or would it have to wait for the > existing > > registration to timeout (which could be a long time)? >=20 > Generally the authorization information in the certificate is just stored > in the subject (i.e., subjectAltName) of the certificate, so a new > certificate for the same name would pass the same authorization checks > (i.e., be "equivalent credentials"). >=20 > -Ben From nobody Mon Aug 17 01:23:03 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF05E3A140B for ; Mon, 17 Aug 2020 01:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 dBHQAzKjBb07 for ; Mon, 17 Aug 2020 01:22:59 -0700 (PDT) Received: from forward2-smtp.messagingengine.com (forward2-smtp.messagingengine.com [66.111.4.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F35E3A142B for ; Mon, 17 Aug 2020 01:22:58 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.nyi.internal (Postfix) with ESMTP id 7022F194080D; Mon, 17 Aug 2020 04:22:57 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute7.internal (MEProxy); Mon, 17 Aug 2020 04:22:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=JJynn1FQ/nnIRH2ynxWtdAK0XsIRjBwKtfSbyVGf6 i4=; b=jEBqnlgSBaziiR0+UXiJDFIUtP/a6FUmDCbqHcJdZYlQd2yPFbyMYTHsI rDPiZ4i0sV8L3eDnd/qp1CVJozwAsayjHPWVUl0a/7pZb1/VrqZsrGEQGOkvo4St zvvjdV1bC1mAAh4P4ytgYsA7xN2+8lxhl+wpcm03BVCxJnge9vrDpZOcTBYDdbNL LBcPxDE5hYg+5QifwkTS7q6PsV736RJ6m3zuISrnzqGM08OWeBZVXHOucCnKUr2M /fZLVPk//z0ck8PGQxGPI18LfGj9Qlc4aeGcuraEMoBbTYhL1NwpdVt2ozo7Iqfo FT+0lIYKnT3n+58obTSL632UbVMYA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtfedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghi mhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrh hnpeetffejffegvefhgeegfffhuefhiedvhfefleefvdetgfefleehudffgffggfdtuden ucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE7974E009F; Mon, 17 Aug 2020 04:22:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 17 Aug 2020 10:22:36 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Cc: "Marco Tiloca" , =?UTF-8?Q?Ari_Ker=C3=A4nen?= , "Carsten Bormann" , "Barry Leiba" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 17 Aug 2020 08:23:02 -0000 Dear all, We are now closing this call. As you can see there have been no comments= on this WGLC at all, which is odd. The document does seem mature and the chairs would be happy to close the= call and ship the document, however I'd like to check with the AD (Barr= y) to confirm that it's OK as we have gotten no feedback. We could exten= d the call, but I am not sure that'd bring more comments. Thanks! --=20 Jaime Jim=C3=A9nez On Wed, Jul 29, 2020, at 7:44 PM, Jaime Jim=C3=A9nez wrote: > Dear CoRE WG, >=20 > we would like to issue the WGLC for=20 > https://tools.ietf.org/html/draft-ietf-core-senml-data-ct-02 >=20 > This short draft specifies a new SenML field (=E2=80=9Cct=E2=80=9D) th= at indicates the=20 > content format of the data.=20 >=20 > The authors believe the draft is ready and we have discussed it on=20 > several CoRE meetings. I think it is a great opportunity to provide=20= > some last minute feedback so please, if you have a bit of time it is=20= > only few pages long. > =20 > We will close the call in two weeks, the 12th of August.=20 >=20 > Thanks! > --=20 > Jaime Jim=C3=A9nez From nobody Mon Aug 17 01:57:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC6C3A141F; Mon, 17 Aug 2020 01:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 fModHUQgbqnQ; Mon, 17 Aug 2020 01:57:45 -0700 (PDT) Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2883A1414; Mon, 17 Aug 2020 01:57:45 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.west.internal (Postfix) with ESMTP id 87578C85; Mon, 17 Aug 2020 04:57:44 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute7.internal (MEProxy); Mon, 17 Aug 2020 04:57:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vUcaOhzmWQ/a2duf51ZdxlUBL89Sp93b6pvO2J2jg Cg=; b=ef5kJMJ+lBKvU5ShpBdYvDIChB8qKvH0NgGW0Ov93xvZXKeMGzs0deIC3 kiXw6I3nitFYDMuHg/THY8YUUj/KsyPVYuWSGEEWF1kjHhviI6XN0KBGUungFUOl HD1YDHNYb7j6OPgEo/KZBATp8hx6YzhRUqzaJYpkDPknDY98fVqY9Q2kAi5iCjQ2 LFP1gGCLI9TXoF4IK6MW2JBx+LLJcmM5AIiHqx1pCpwAAIikg5gdLmUBElY1vwV+ DVrcY3jSK/kkNXuoy8km9pXRjzuvJvzaWKIvLC0NZA2ZJ8vodPaCGi4U5iXA8A5b ojP08UTz8cQgy75D0W0hEGMYXxejw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtfedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghi mhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrh hnpeeludeiffeiudetteduuedtudfhkefffedufeeugeegvdetvdffveduudehleekkeen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimh gvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 06C5F4E009F; Mon, 17 Aug 2020 04:57:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786 Mime-Version: 1.0 Message-Id: In-Reply-To: <26691_1596099467_5F228B8B_26691_30_6_787AE7BB302AE849A7480A190F8B933031508EA4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <7388_1596092178_5F226F12_7388_217_1_787AE7BB302AE849A7480A190F8B933031508D60@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <321601d6664e$16f97de0$44ec79a0$@jpshallow.com> <26691_1596099467_5F228B8B_26691_30_6_787AE7BB302AE849A7480A190F8B933031508EA4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 17 Aug 2020 10:57:20 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "mohamed.boucadair" , "Carsten Bormann" , "Jon Shallow (supjps-ietf@jpshallow.com)" Cc: core , "draft-bosh-core-new-block@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] WGA call on draft-bosh-core-new-block-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, 17 Aug 2020 08:57:47 -0000 Dear all, Thank you all who have provided feedback during the adoption call at IET= F session and on email. And also thank you authors for the extra IPR inf= ormation on it.=20 Marco and I agree that there is enough steam in the group to help move f= orward this document, we will help migrate the document to the CoRE Gith= ub repo. Thank you Jon and Mohamed for taking the time to present this and draw o= ur attention, welcome to the group! Ciao! --=20 Jaime Jim=C3=A9nez On Thu, Jul 30, 2020, at 10:57 AM, mohamed.boucadair@orange.com wrote: > Re-, >=20 > Nor I'm aware of any. >=20 > :-) >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=C2=A0: Carsten Bormann [mailto:cabo@tzi.org] > > Envoy=C3=A9=C2=A0: jeudi 30 juillet 2020 10:50 > > =C3=80=C2=A0: supjps-ietf@jpshallow.com > > Cc=C2=A0: Jaime Jim=C3=A9nez ; core ; B= OUCADAIR > > Mohamed TGI/OLN ; draft-bosh-core-new-= > > block@ietf.org > > Objet=C2=A0: Re: [core] WGA call on draft-bosh-core-new-block-04 > >=20 > > >> FWIW, I don't have any IPR related to this draft. > >=20 > > (Regression into long past chair mode: > > It would be more useful to state =E2=80=9CI am not personally aware = of any=E2=80=9D=E2=80=A6) > >=20 > > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > ______________________________________________________________________= ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= =20 > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les=20 > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deform= e=20 > ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privilege= d=20 > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and= =20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20= > been modified, changed or falsified. > Thank you. >=20 > From nobody Mon Aug 17 01:59:59 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1D23A1421; Mon, 17 Aug 2020 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 iW7OI8B6njEm; Mon, 17 Aug 2020 01:59:55 -0700 (PDT) Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA023A1414; Mon, 17 Aug 2020 01:59:55 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.west.internal (Postfix) with ESMTP id 1BFB69E1; Mon, 17 Aug 2020 04:59:54 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute7.internal (MEProxy); Mon, 17 Aug 2020 04:59:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=g3bzpRr0Ke0jV4x7quDuJ30DTjqBsZ34+zujEk5d8 nc=; b=l/emoLsW4j+JR/gwZw6ly1SXKSovG/qUsZNa690tw1Pi0VGRK+OgaeRDV +NAXNfGQzWLgHo9amFNJfeedGEq2pP1UvUiXtsQoFCf6d3gR1NvsFG7E3BboyqhA C8o4RgJFEzWFvjWHrIz0qGKIaMGo+RevXnuL36Mrf3ytzQSEUyxo/evmOCsXi5nY zwaoYZE6OxqeFAVprj84WoT9gtKYzbGTpRgbDqxnUQO/saaXP9FgM5jGaZwnofsi JgGeQ8L7H8wmTQddqpfle470NS5Qg0s4acCJJhQrvfJ1rAEqFrdrTgwLez/eN2lw h3pysX4CaE80zhfZqzSrJGu9psSUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtfedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghi mhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrh hnpeeludeiffeiudetteduuedtudfhkefffedufeeugeegvdetvdffveduudehleekkeen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimh gvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 773164E009F; Mon, 17 Aug 2020 04:59:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786 Mime-Version: 1.0 Message-Id: <4da05b4c-ceae-4989-b950-22703c0183a1@www.fastmail.com> In-Reply-To: References: <7388_1596092178_5F226F12_7388_217_1_787AE7BB302AE849A7480A190F8B933031508D60@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <321601d6664e$16f97de0$44ec79a0$@jpshallow.com> <26691_1596099467_5F228B8B_26691_30_6_787AE7BB302AE849A7480A190F8B933031508EA4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 17 Aug 2020 10:59:33 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "mohamed.boucadair" , "Carsten Bormann" , "Jon Shallow (supjps-ietf@jpshallow.com)" Cc: core , "draft-bosh-core-new-block@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] WGA call on draft-bosh-core-new-block-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, 17 Aug 2020 08:59:57 -0000 Forgot to add that the authors should resubmit the draft as "draft-ietf-= core-new-block" Thanks! --=20 Jaime Jim=C3=A9nez On Mon, Aug 17, 2020, at 10:57 AM, Jaime Jim=C3=A9nez wrote: > Dear all, >=20 > Thank you all who have provided feedback during the adoption call at=20= > IETF session and on email. And also thank you authors for the extra IP= R=20 > information on it.=20 >=20 > Marco and I agree that there is enough steam in the group to help move= =20 > forward this document, we will help migrate the document to the CoRE=20= > Github repo. >=20 > Thank you Jon and Mohamed for taking the time to present this and draw= =20 > our attention, welcome to the group! >=20 > Ciao! > --=20 > Jaime Jim=C3=A9nez >=20 > On Thu, Jul 30, 2020, at 10:57 AM, mohamed.boucadair@orange.com wrote:= > > Re-, > >=20 > > Nor I'm aware of any. > >=20 > > :-) > >=20 > > Cheers, > > Med > >=20 > > > -----Message d'origine----- > > > De=C2=A0: Carsten Bormann [mailto:cabo@tzi.org] > > > Envoy=C3=A9=C2=A0: jeudi 30 juillet 2020 10:50 > > > =C3=80=C2=A0: supjps-ietf@jpshallow.com > > > Cc=C2=A0: Jaime Jim=C3=A9nez ; core ;= BOUCADAIR > > > Mohamed TGI/OLN ; draft-bosh-core-ne= w- > > > block@ietf.org > > > Objet=C2=A0: Re: [core] WGA call on draft-bosh-core-new-block-04 > > >=20 > > > >> FWIW, I don't have any IPR related to this draft. > > >=20 > > > (Regression into long past chair mode: > > > It would be more useful to state =E2=80=9CI am not personally awar= e of any=E2=80=9D=E2=80=A6) > > >=20 > > > Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > > ____________________________________________________________________= _____________________________________________________ > >=20 > > Ce message et ses pieces jointes peuvent contenir des informations=20= > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez=20 > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les=20 > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, defo= rme=20 > > ou falsifie. Merci. > >=20 > > This message and its attachments may contain confidential or privile= ged=20 > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation= . > > If you have received this email in error, please notify the sender a= nd=20 > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that hav= e=20 > > been modified, changed or falsified. > > Thank you. > >=20 > > From nobody Mon Aug 17 04:04:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A063A14B3 for ; Mon, 17 Aug 2020 04:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mnW2AG6UltiP for ; Mon, 17 Aug 2020 04:04:42 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2143A14B0 for ; Mon, 17 Aug 2020 04:04:39 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1k7cwP-0003Q0-AQ; Mon, 17 Aug 2020 12:04:37 +0100 From: To: , "'mohamed.boucadair'" , "'Carsten Bormann'" Cc: "'core'" , References: <7388_1596092178_5F226F12_7388_217_1_787AE7BB302AE849A7480A190F8B933031508D60@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <321601d6664e$16f97de0$44ec79a0$@jpshallow.com> <26691_1596099467_5F228B8B_26691_30_6_787AE7BB302AE849A7480A190F8B933031508EA4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4da05b4c-ceae-4989-b950-22703c0183a1@www.fastmail.com> In-Reply-To: <4da05b4c-ceae-4989-b950-22703c0183a1@www.fastmail.com> Date: Mon, 17 Aug 2020 12:04:38 +0100 Message-ID: <02d201d67486$32f22ce0$98d686a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH/yNmVIrFZa/rp6/cbB0UYJn7a2AI0z7m2Ah5LSfECS7RN0gI9Px2JAo1kcy4Cbpqkl6h6n90Q Content-Language: en-gb Archived-At: Subject: Re: [core] WGA call on draft-bosh-core-new-block-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, 17 Aug 2020 11:04:45 -0000 Hi Jaime, Med and I had thought of "draft-ietf-core-quick-block" picking up on a = comment from a review by Christian. I can go with either naming convention - whatever suits you. I will = resubmit the draft later today (this will be the first time I have ever = done this, and Med is currently on vacation for the next couple of = weeks. Regards Jon > -----Original Message----- > From: Jaime Jim=C3=A9nez [mailto: jaime@iki.fi] > Sent: 17 August 2020 10:00 > To: mohamed.boucadair; Carsten Bormann; Jon Shallow (supjps- > ietf@jpshallow.com) > Cc: core; draft-bosh-core-new-block@ietf.org > Subject: Re: [core] WGA call on draft-bosh-core-new-block-04 >=20 > Forgot to add that the authors should resubmit the draft as = "draft-ietf-core- > new-block" >=20 > Thanks! > -- > Jaime Jim=C3=A9nez >=20 > On Mon, Aug 17, 2020, at 10:57 AM, Jaime Jim=C3=A9nez wrote: > > Dear all, > > > > Thank you all who have provided feedback during the adoption call at > > IETF session and on email. And also thank you authors for the extra = IPR > > information on it. > > > > Marco and I agree that there is enough steam in the group to help = move > > forward this document, we will help migrate the document to the CoRE > > Github repo. > > > > Thank you Jon and Mohamed for taking the time to present this and = draw > > our attention, welcome to the group! > > > > Ciao! > > -- > > Jaime Jim=C3=A9nez > > > > On Thu, Jul 30, 2020, at 10:57 AM, mohamed.boucadair@orange.com > wrote: > > > Re-, > > > > > > Nor I'm aware of any. > > > > > > :-) > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Carsten Bormann [mailto:cabo@tzi.org] > > > > Envoy=C3=A9 : jeudi 30 juillet 2020 10:50 > > > > =C3=80 : supjps-ietf@jpshallow.com > > > > Cc : Jaime Jim=C3=A9nez ; core ; = BOUCADAIR > > > > Mohamed TGI/OLN ; draft-bosh- > core-new- > > > > block@ietf.org > > > > Objet : Re: [core] WGA call on draft-bosh-core-new-block-04 > > > > > > > > >> FWIW, I don't have any IPR related to this draft. > > > > > > > > (Regression into long past chair mode: > > > > It would be more useful to state =E2=80=9CI am not personally = aware of any=E2=80=9D=E2=80=A6) > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > __________________________________________________________ > __________________________________________________________ > _____ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc > > > pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez > > > recu ce message par erreur, veuillez le signaler > > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > > messages electroniques etant susceptibles d'alteration, > > > Orange decline toute responsabilite si ce message a ete altere, = deforme > > > ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or = privileged > > > information that may be protected by law; > > > they should not be distributed, used or copied without = authorisation From nobody Mon Aug 17 08:39:56 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B333A119E for ; Mon, 17 Aug 2020 08:39:52 -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 QarOQP5pO-Pj for ; Mon, 17 Aug 2020 08:39:51 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41463A0CCD for ; Mon, 17 Aug 2020 08:39:50 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 08:39:37 -0700 From: Jim Schaad To: 'Klaus Hartke' , 'Carsten Bormann' CC: 'Core WG mailing list' Date: Mon, 17 Aug 2020 08:39:36 -0700 Message-ID: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZ0p1+Tj1q6rV/TRxOxlQ+TE3N4mA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Message correlation with observe 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, 17 Aug 2020 15:39:55 -0000 Klaus, Carsten, I am trying to figure out if there is a problem in my head, and thus in my code, or if it is in the design of the specs. Start by setting up an observe operation: C1: GET /temperature MID:10 Token: 0x4a Observe: 0 S1: ACK 2.05 Content MID:10 Token:0x4a Observe:12 Payload:22.9 S2: NON 2.05 Content MID:11 Token:0x4a Observe:44 Payload: 22.8 I now do a proactive cancel C2: GET /temperature MID:15 Token:0x4a Observe:1 I now get two responses back S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 As a human being, I automatically associate response S3 with request C1 and response S4 with request C2. However, my code base is associating response S3 with request C2 and then drops response S4 on the floor because it is an ACK to a message that has already received a response. My code however is doing something strange with the response S3 internally to deal with the possibility of needing to refresh the observe relationship automatically under the covers. Other than playing with the use of the observe option in the response to change the correlation algorithm, I believe that my code is correctly following the spec and I just need to fix things about the refreshing in my code. The one odd side effect is that the client is not going to get a response from the server that does not have an observe option in it, even if the proactive cancel operation is a CON. This seems to have cognitive dissidence. The observe relation is canceled, but there is no positive notification of the fact. I don't' believe that the use of OSCORE changes any thing in the above. The same thing is true for using a reliable transport since the MID is not really used for correlation here, the token value is used here. Is what my code does what the authors expected to occur? Jim From nobody Mon Aug 17 09:44:33 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2653A0D42 for ; Mon, 17 Aug 2020 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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.949, RCVD_IN_MSPIKE_H2=-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 cTUgBWS-IE_5 for ; Mon, 17 Aug 2020 09:44:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 CD7133A1200 for ; Mon, 17 Aug 2020 09:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1597682655; bh=8KfIqHB2WNo/31pOyiaiSO3ekxogJbIM61TvKzqB9pg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=OFalONVye8byShjecVTBPMHBzBCgyHk56Xmu3J8hGDAoyXA6MN9Ip9TDFZCgT8bO2 LHvLgp2drkm6AUrthEALxaznOaJk/gLZL8rAYIvaDt42yJSVMuvUmk8Aav1VxjCY6i AIS/zGPILD2tmKqBoXU1Dr1yhP4s/eJZlS9nRREc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.226.100]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJVDM-1kNBl103kO-00JoYV; Mon, 17 Aug 2020 18:44:15 +0200 To: Jim Schaad , 'Klaus Hartke' , 'Carsten Bormann' Cc: 'Core WG mailing list' References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> From: Achim Kraus Message-ID: <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> Date: Mon, 17 Aug 2020 18:44:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:z5qUidMD7XRlcRro98mpcmc2cYSi5mlrW3RE2wvzCgkXOX2S1YP 1qfXfojtOL5FV3zt3YgtKXq1pA18DGEq5aGWBRfuNGsBZ6mbpSAE6bWBOA8SOfar+MynpVp 2LDpa/wZgr/bf8k4eapA3pfh2qHwea3hg5aLwzO6IWgU1De4JWyaVJtS+PedqTwExq1k/QG BqpemKa257RsuVPln/Keg== X-UI-Out-Filterresults: notjunk:1;V03:K0:YS/v3LaLjA0=:xA3OIIFro+5gZ9npFWDGni QrOIEfDEzaqDRiEE9asBsm8CgIT/HeqfZy/ZAfWtfD8WtOZehavwoK1yjszDqDOkkk77i1GFE hPYDjVy+dY+bneC7fejtrZUCGQM+Msur2OyqsQjNYoFVsq+t9mFLP8fL9uX9fnzt+u/pgvIMT 7Eq9LSuWPCTQO5jBFtih3SA8Quu3CgQ8T0HmXFoO6Dh7MMD31K7CcP08dnxg1dhxW5x0H8ugW pl3gLLqohifx/cd5rfNJxlCefy+/1f+u4Kutdjt82GreZnsmskp1KdnFTUgZgLmmL23aRYvgA wAp3RI+HyY2RSQF4+vd4EBdmMaJZ+c36VVndAae6rscnlSlB/l0sOugMV1vfvK+7bwIOMCGYU 9G+Oz93beN5EKq4NUJLItfcYrzC/PSRQ3anfHtzPhBDIEjoWH3HWW/0yBO0o5Rxli2uvhkv1D 76VX6pebxwEUeJzq3rd/o3zwzUS4XWdD3PaflWKlGG9BWnd5tW0d0MYFEI4JrkCb0xBdVxyaM pjSVoKKGGcnO2l35xIjdXYm1PT/0qk5Y0X1s9YtqG9aJidV29ZcAY+KRvnycIC7bB2akzOHKZ TwRuv18TSqw/KNbzv2L5eZaoOgEodVPxBHYoE4SZGrFxBqk8pqxxx/bRaKWWVT7Bxb6+rYwDY 6ompkErHQt6YdPFg2y6i8r8RDsuLSn3GQMuFpZXOhBgVKbvI2TwyDX1vQ0rVqYeQFYyvb1gg/ Pvm+cDpdgxiAqAc7hwf6pbScDWKt3p+CU6MZTwAGvMmETAZbTJbS4De8tc18YiXmOV+MBQEqm uiSNMQm79MUpkxQmZijb26ScxpPP4wqnF/ZljdebjzoEIGMrBbb4B9askGOYlU/k2kQO0udpK uzVlybduvDtfwLK4IwqTbwkAZjz8HL7ECvrSBRVhsG2W9eN6W7J4Zwi6+JEtyTPxYFD+QnZfw p64dvIRcwS6mXu/YXAey5+HPF4e6+WSg+fZ0OnwL3khsu+kZOYUWnpU7/VtHH30MdUWH8lkiK qAomeqj04+HSvn0FW3pj9xfRn8DVAFv3+bLOcSMbDjQB/pCkbSzWxu9fFjlhk0BcLdjwSkvW+ NOqX2JlK1jOuFTaDkOhpWISf6qkKrhBBE3311rqqKMtmdGd5Jk3kBBfBOjNamKu93tsORsaf/ dvNl120V+SpX/kaWMxqc6J/GMfx16q+lhB18/qoX0JtClX83GrkOWj6VIg/NR3L1d5MNv7tMM /GLN4gcd/dxnjxFQxQgd2GYOIWBTAObM+uatWOw== Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 16:44:32 -0000 Hi Jim, yes, that's one of the pain-points of reusing the token. I'm not sure, if the rfc covers the processing of that scenario. So I would also welcome an answer from Klaus and Carsten. FMPOV, if someone, wants to cancel the observation, I wait for a response without the observe option. Sure, other implementations may also result in "acceptable behavior". =2D---- Californium, UdpMatcher, receiveResponse --------------------- if (type !=3D Type.ACK && !exchange.isNotification() && response.isNotification() && currentRequest.isObserveCancel()) { // overlapping notification and observation cancel request LOGGER.debug("ignoring notify for pending cancel {}!", response); cancel(response, receiver); return; } =2D------------------------------------------------------------------- best regards Achim Kraus Am 17.08.20 um 17:39 schrieb Jim Schaad: > Klaus, Carsten, > > I am trying to figure out if there is a problem in my head, and thus in = my > code, or if it is in the design of the specs. > > Start by setting up an observe operation: > > C1: GET /temperature MID:10 Token: 0x4a Observe: 0 > S1: ACK 2.05 Content MID:10 Token:0x4a Observe:12 Payload:22.9 > S2: NON 2.05 Content MID:11 Token:0x4a Observe:44 Payload: 22.8 > > I now do a proactive cancel > > C2: GET /temperature MID:15 Token:0x4a Observe:1 > > I now get two responses back > > S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 > S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 > > As a human being, I automatically associate response S3 with request C1 = and > response S4 with request C2. However, my code base is associating respo= nse > S3 with request C2 and then drops response S4 on the floor because it is= an > ACK to a message that has already received a response. My code however = is > doing something strange with the response S3 internally to deal with the > possibility of needing to refresh the observe relationship automatically > under the covers. > > Other than playing with the use of the observe option in the response to > change the correlation algorithm, I believe that my code is correctly > following the spec and I just need to fix things about the refreshing in= my > code. The one odd side effect is that the client is not going to get a > response from the server that does not have an observe option in it, eve= n if > the proactive cancel operation is a CON. This seems to have cognitive > dissidence. The observe relation is canceled, but there is no positive > notification of the fact. > > I don't' believe that the use of OSCORE changes any thing in the above. = The > same thing is true for using a reliable transport since the MID is not > really used for correlation here, the token value is used here. > > Is what my code does what the authors expected to occur? > > Jim > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Aug 17 09:54:24 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48F33A12A5 for ; Mon, 17 Aug 2020 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBgGwFJ7sfrG for ; Mon, 17 Aug 2020 09:54:20 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A193A12A3 for ; Mon, 17 Aug 2020 09:54:20 -0700 (PDT) Received: from client-0017.vpn.uni-bremen.de (client-0017.vpn.uni-bremen.de [134.102.107.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BVgB25gKnzysy; Mon, 17 Aug 2020 18:54:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> Date: Mon, 17 Aug 2020 18:54:18 +0200 Cc: Jim Schaad , Klaus Hartke , Core WG mailing list X-Mao-Original-Outgoing-Id: 619376058.206778-d701ebcbfbbdd7775e8c0267d2fc4ea1 Content-Transfer-Encoding: quoted-printable Message-Id: <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> To: Achim Kraus X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 16:54:23 -0000 Hi Jim, Achim, > On 2020-08-17, at 18:44, Achim Kraus wrote: >=20 > I'm not sure, if the rfc covers the processing of that scenario. > So I would also welcome an answer from Klaus and Carsten. I cannot remember discussing the race condition Jim has identified, when = we were discussing the fixes needed to be able to actively cease = observing. (I seem to remember most of this was done early 2014 in the CoAP-04 = interop in London, after IETF89.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 17 10:27:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A83A0D89 for ; Mon, 17 Aug 2020 10:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXX3NYSk9u9T for ; Mon, 17 Aug 2020 10:27:45 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194BD3A0D87 for ; Mon, 17 Aug 2020 10:27:44 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1k7iv4-0003el-L4; Mon, 17 Aug 2020 18:27:38 +0100 From: To: "'Carsten Bormann'" , "'Achim Kraus'" , "'Jim Schaad'" Cc: "'Klaus Hartke'" , "'Core WG mailing list'" References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> In-Reply-To: <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> Date: Mon, 17 Aug 2020 18:27:39 +0100 Message-ID: <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJguH2ha/bGHazvP+WART7aFcWd2gGdXCVqAxkiwZyoAkwxAA== Content-Language: en-gb Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 17:27:47 -0000 Hi Jim, With > C2: GET /temperature MID:15 Token:0x4a Observe:1 > .... > S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 > S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 As per https://tools.ietf.org/html/rfc7641#section-4.1 If the Observe Option in a GET request is set to 1 (deregister), then the server MUST remove any existing entry with a matching endpoint/ token pair from the list of observers and process the GET request as usual. The resulting response MUST NOT include an Observe Option. S3: therefore cannot be a match to C2: as it includes an Observe Option, = so that at that point the server has not acknowledged the deregister. As a deregister is in progress, S3: should not trigger an observer = refresh in any underlying logic and should be dropped/ignored (as per = Achim's solution). Alternatively, (but not for TCP) a RST can be sent = by the client on seeing S3: which may cause other confusion. Regards Jon > -----Original Message----- > From: core [mailto: core-bounces@ietf.org] On Behalf Of Carsten = Bormann > Sent: 17 August 2020 17:54 > To: Achim Kraus > Cc: Klaus Hartke; Core WG mailing list > Subject: Re: [core] Message correlation with observe >=20 > Hi Jim, Achim, >=20 > > On 2020-08-17, at 18:44, Achim Kraus wrote: > > > > I'm not sure, if the rfc covers the processing of that scenario. > > So I would also welcome an answer from Klaus and Carsten. >=20 > I cannot remember discussing the race condition Jim has identified, = when we > were discussing the fixes needed to be able to actively cease = observing. > (I seem to remember most of this was done early 2014 in the CoAP-04 > interop in London, after IETF89.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 17 11:08:13 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669F43A147A for ; Mon, 17 Aug 2020 11:08:12 -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 DSBFoXO6rFQw for ; Mon, 17 Aug 2020 11:08:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0863A1473 for ; Mon, 17 Aug 2020 11:08:09 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 11:08:00 -0700 From: Jim Schaad To: , 'Carsten Bormann' , 'Achim Kraus' CC: 'Klaus Hartke' , 'Core WG mailing list' References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> In-Reply-To: <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> Date: Mon, 17 Aug 2020 11:07:58 -0700 Message-ID: <015b01d674c1$587cc390$09764ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJguH2ha/bGHazvP+WART7aFcWd2gGdXCVqAxkiwZwDJ/xVxKfpG3QQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 18:08:12 -0000 -----Original Message----- From: supjps-ietf@jpshallow.com =20 Sent: Monday, August 17, 2020 10:28 AM To: 'Carsten Bormann' ; 'Achim Kraus' = ; 'Jim Schaad' Cc: 'Klaus Hartke' ; 'Core WG mailing list' = Subject: RE: [core] Message correlation with observe Hi Jim, With > C2: GET /temperature MID:15 Token:0x4a Observe:1 .... > S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 > S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 As per https://tools.ietf.org/html/rfc7641#section-4.1 If the Observe Option in a GET request is set to 1 (deregister), then the server MUST remove any existing entry with a matching endpoint/ token pair from the list of observers and process the GET request as usual. The resulting response MUST NOT include an Observe Option. S3: therefore cannot be a match to C2: as it includes an Observe Option, = so that at that point the server has not acknowledged the deregister. [JLS] That would be a change in the matching rules. You might reject S3 = at a higher level, but you have still matched it based on the token. = This would be a change in the match rules. As a deregister is in progress, S3: should not trigger an observer = refresh in any underlying logic and should be dropped/ignored (as per = Achim's solution). Alternatively, (but not for TCP) a RST can be sent = by the client on seeing S3: which may cause other confusion. [JLS] I don't understand why the RST would not be sent in the TCP case. = This is the defined way to do a passive observe cancelation. I don't = remember seeing anything in the TCP document that would change this. = You might still not want to send the RST, but given that you then need = to make sure that the active cancelation succeeds doing the RST might = still be the best idea. Jim Regards Jon > -----Original Message----- > From: core [mailto: core-bounces@ietf.org] On Behalf Of Carsten=20 > Bormann > Sent: 17 August 2020 17:54 > To: Achim Kraus > Cc: Klaus Hartke; Core WG mailing list > Subject: Re: [core] Message correlation with observe >=20 > Hi Jim, Achim, >=20 > > On 2020-08-17, at 18:44, Achim Kraus wrote: > > > > I'm not sure, if the rfc covers the processing of that scenario. > > So I would also welcome an answer from Klaus and Carsten. >=20 > I cannot remember discussing the race condition Jim has identified,=20 > when we were discussing the fixes needed to be able to actively cease = observing. > (I seem to remember most of this was done early 2014 in the CoAP-04=20 > interop in London, after IETF89.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 17 11:15:35 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8A03A14C1 for ; Mon, 17 Aug 2020 11:15:31 -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_H4=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 wc658xKKi6zU for ; Mon, 17 Aug 2020 11:15:29 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55BE3A14C4 for ; Mon, 17 Aug 2020 11:15:28 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BVhzf6T2mzytY; Mon, 17 Aug 2020 20:15:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <015b01d674c1$587cc390$09764ab0$@augustcellars.com> Date: Mon, 17 Aug 2020 20:15:25 +0200 Cc: supjps-ietf@jpshallow.com, Achim Kraus , Klaus Hartke , Core WG mailing list X-Mao-Original-Outgoing-Id: 619380925.680164-fd743b7b1d32c8711524440e12461e81 Content-Transfer-Encoding: quoted-printable Message-Id: <3458AAF2-918C-4419-A8C2-C9C5482ED00D@tzi.org> References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> <015b01d674c1$587cc390$09764ab0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 18:15:31 -0000 On 2020-08-17, at 20:07, Jim Schaad wrote: >=20 > [JLS] I don't understand why the RST would not be sent in the TCP = case.=20 That I can answer: You can=E2=80=99t. RFC 8323 does not have message = types. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 17 11:26:55 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9003A1556 for ; Mon, 17 Aug 2020 11:26:54 -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 UJvJ1Cp-vkRT for ; Mon, 17 Aug 2020 11:26:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67683A1551 for ; Mon, 17 Aug 2020 11:26:52 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 11:26:46 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , 'Achim Kraus' , 'Klaus Hartke' , 'Core WG mailing list' References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> <015b01d674c1$587cc390$09764ab0$@augustcellars.com> <3458AAF2-918C-4419-A8C2-C9C5482ED00D@tzi.org> In-Reply-To: <3458AAF2-918C-4419-A8C2-C9C5482ED00D@tzi.org> Date: Mon, 17 Aug 2020 11:26:44 -0700 Message-ID: <016501d674c3$f829ebf0$e87dc3d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJguH2ha/bGHazvP+WART7aFcWd2gGdXCVqAxkiwZwDJ/xVxALpG1O6AYRHpTGnxbfukA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 18:26:54 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Monday, August 17, 2020 11:15 AM To: Jim Schaad Cc: supjps-ietf@jpshallow.com; Achim Kraus ; Klaus = Hartke ; Core WG mailing list Subject: Re: [core] Message correlation with observe On 2020-08-17, at 20:07, Jim Schaad wrote: >=20 > [JLS] I don't understand why the RST would not be sent in the TCP = case.=20 That I can answer: You can=E2=80=99t. RFC 8323 does not have message = types. [JLS] So can I do a passive cancel of an observe? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 17 12:04:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A63A0A56 for ; Mon, 17 Aug 2020 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6kGVYayqbViL for ; Mon, 17 Aug 2020 12:04:42 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1953A16F0 for ; Mon, 17 Aug 2020 12:01:55 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1k7kO9-0003iB-RY; Mon, 17 Aug 2020 20:01:45 +0100 From: To: "'Jim Schaad'" Cc: "'Achim Kraus'" , "'Carsten Bormann'" , "'Klaus Hartke'" , "'Core WG mailing list'" References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> <015b01d674c1$587cc390$09764ab0$@augustcellars.com> <3458AAF2-918C-4419-A8C2-C9C5482ED00D@tzi.org> <016501d674c3$f829ebf0$e87dc3d0$@augustcellars.com> In-Reply-To: <016501d674c3$f829ebf0$e87dc3d0$@augustcellars.com> Date: Mon, 17 Aug 2020 20:01:46 +0100 Message-ID: <035d01d674c8$dab64d70$9022e850$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJguH2ha/bGHazvP+WART7aFcWd2gGdXCVqAxkiwZwDJ/xVxALpG1O6AYRHpTECPskuNaezydJw Content-Language: en-gb Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 19:04:46 -0000 Hi Jim, See inline Jon> Regards Jon > -----Original Message----- > From: Jim Schaad [mailto: ietf@augustcellars.com] > Sent: 17 August 2020 19:27 > To: 'Carsten Bormann' > Cc: supjps-ietf@jpshallow.com; 'Achim Kraus'; 'Klaus Hartke'; 'Core WG = mailing list' > Subject: RE: [core] Message correlation with observe >=20 >=20 >=20 > -----Original Message----- > From: Carsten Bormann > Sent: Monday, August 17, 2020 11:15 AM > To: Jim Schaad > Cc: supjps-ietf@jpshallow.com; Achim Kraus ; Klaus > Hartke ; Core WG mailing list = > Subject: Re: [core] Message correlation with observe >=20 > On 2020-08-17, at 20:07, Jim Schaad wrote: > > > > [JLS] I don't understand why the RST would not be sent in the TCP = case. >=20 > That I can answer: You can=E2=80=99t. RFC 8323 does not have message = types. > [JLS] So can I do a passive cancel of an observe? Jon> No. https://tools.ietf.org/html/rfc8323#section-7.4 For CoAP over reliable transports, a client MUST explicitly deregister by issuing a GET request that has the Token field set to the Token of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister). ~Jon >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Mon Aug 17 12:26:07 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569ED3A0A04 for ; Mon, 17 Aug 2020 12:26: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 u_I3810Z4wjs for ; Mon, 17 Aug 2020 12:26:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B223A09FF for ; Mon, 17 Aug 2020 12:26:04 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 12:25:57 -0700 From: Jim Schaad To: CC: 'Achim Kraus' , 'Carsten Bormann' , 'Klaus Hartke' , 'Core WG mailing list' References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <3e75e060-da69-3e6a-3dbe-f40a2a6d33f1@gmx.net> <7C6F38E2-B01C-4309-9420-3D971271B5C0@tzi.org> <035b01d674bb$b4be6010$1e3b2030$@jpshallow.com> <015b01d674c1$587cc390$09764ab0$@augustcellars.com> <3458AAF2-918C-4419-A8C2-C9C5482ED00D@tzi.org> <016501d674c3$f829ebf0$e87dc3d0$@augustcellars.com> <035d01d674c8$dab64d70$9022e850$@jpshallow.com> In-Reply-To: <035d01d674c8$dab64d70$9022e850$@jpshallow.com> Date: Mon, 17 Aug 2020 12:25:55 -0700 Message-ID: <016801d674cc$3c7c5560$b5750020$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJguH2ha/bGHazvP+WART7aFcWd2gGdXCVqAxkiwZwDJ/xVxALpG1O6AYRHpTECPskuNQG6fHlip6X+PpA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Message correlation with observe 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, 17 Aug 2020 19:26:06 -0000 -----Original Message----- From: supjps-ietf@jpshallow.com =20 Sent: Monday, August 17, 2020 12:02 PM To: 'Jim Schaad' Cc: 'Achim Kraus' ; 'Carsten Bormann' = ; 'Klaus Hartke' ; 'Core WG = mailing list' Subject: RE: [core] Message correlation with observe Hi Jim, See inline Jon> Regards Jon > -----Original Message----- > From: Jim Schaad [mailto: ietf@augustcellars.com] > Sent: 17 August 2020 19:27 > To: 'Carsten Bormann' > Cc: supjps-ietf@jpshallow.com; 'Achim Kraus'; 'Klaus Hartke'; 'Core WG = mailing list' > Subject: RE: [core] Message correlation with observe >=20 >=20 >=20 > -----Original Message----- > From: Carsten Bormann > Sent: Monday, August 17, 2020 11:15 AM > To: Jim Schaad > Cc: supjps-ietf@jpshallow.com; Achim Kraus ; Klaus = > Hartke ; Core WG mailing list=20 > > Subject: Re: [core] Message correlation with observe >=20 > On 2020-08-17, at 20:07, Jim Schaad wrote: > > > > [JLS] I don't understand why the RST would not be sent in the TCP = case. >=20 > That I can answer: You can=E2=80=99t. RFC 8323 does not have message = types. > [JLS] So can I do a passive cancel of an observe? Jon> No. https://tools.ietf.org/html/rfc8323#section-7.4 For CoAP over reliable transports, a client MUST explicitly deregister by issuing a GET request that has the Token field set to the Token of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister). [JLS] Sigh - yet another bug that needs to get fixed. ~Jon >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Mon Aug 17 13:04:40 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3F3A1055 for ; Mon, 17 Aug 2020 13:04:38 -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 KMBbsHWcRiUk for ; Mon, 17 Aug 2020 13:04:37 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D343A1051 for ; Mon, 17 Aug 2020 13:04:37 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id a5so18802549ioa.13 for ; Mon, 17 Aug 2020 13:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=484eOAxSW/W2H4/h+0OKL9KCXCjW/sH+5sjgpjb4EJ8=; b=kQF4UxczaP/l/LxzwGpVKptU3tWLSea11y9itOYPRKMLaISxdHWGd7GLNIeGvuwAyT 30sk2ZUFhjh3Fvnt/o96PJndIO8iDMuf/52eBkm7GOxTCf6m4E03wxdIfkPGKQgqI2XN OsKYdU3UmFaor4Hm9JRFgn+LPxyeyQVtH1TdXpsIBpcCSlMpHt3OEZLloZ0wOTxmD9qU it2RWMkVlO3w77/q/9HCy818M2Xk9JATyMkL03LiqCKXuwJpOBLh5u8sziAx0h8MnY63 gVp1DbET79aBADD3yAYQMQppisJyvU9wgeXs3rlOV5uB+mLJTb+BO9M1E1mwMMPPZFK5 YCNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=484eOAxSW/W2H4/h+0OKL9KCXCjW/sH+5sjgpjb4EJ8=; b=nNpNoQhjHdAFPxugbY6A94ezMwtkC918T2dy8OG/a1tQe1W6dGj8W4i4EkRxaD7T1E c57dYiIDDqMnywe3LHnXtfLp9W39nXVjzI7mnFMgHxWdpxaJOYk+ph+y1rMcagLK60Xi JzMpQ9goay+RlnBA3SWtqBCPP40M9mfHZtWBba60DRkP9uZQ7qiEnaEp1/PBL1QUlVzX Rl4IOEFL2EjYGIsbVCmrLQJ0CB47dOkx/BiETNkH5GkRrzu7kf/t86vmRkwjj/h7zDMN xfI0BsgwsNqs8vNiHsu0qRTLrmEEE5iJbGkoOfRQ/Y8JNdBnEaYPb8QyVn54NYiWAMTh plMg== X-Gm-Message-State: AOAM530F/ue/D5t0eop54V2VBnwUsaPgg15/D7DRFBuWTPfd3eysD4oH vkNG99uI2XRn9EvMzUnuOxWGqkPY0gQwp6WwN2w= X-Google-Smtp-Source: ABdhPJwx9P1trW6rbhV8124S9KELiw3O/2lM0PF7AFP9XCjO+exv7WXy7ivJATW4STHfLsFZGk1epQNuuX4NWMeR07I= X-Received: by 2002:a6b:5502:: with SMTP id j2mr13623504iob.204.1597694676354; Mon, 17 Aug 2020 13:04:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Mon, 17 Aug 2020 16:04:25 -0400 Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Carsten Bormann , Marco Tiloca , core@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4cb8b05ad18477b" Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 17 Aug 2020 20:04:39 -0000 --000000000000a4cb8b05ad18477b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I leave this to the chairs=E2=80=99 judgment, with this advice: I=E2=80=99m concerned more with how much review and discussion the document= has had throughout it=E2=80=99s development than with specifically the comments dur= ing WGLC. If you think there=E2=80=99s been enough of the former, be sure that= the shepherd writeup talks about that, and it will be fine. If it=E2=80=99s re= ally the case that the WG doesn=E2=80=99t have enough interest to have reviewed the = document in general, then that=E2=80=99s a different coloured horse. You could also, rather than directly extending WGLC, post to the working group that there have been no further comments and that the document is ready for publication... but that you would like (pick a small number) three reviews that agree that it=E2=80=99s ready. =E2=80=9CWho will volunt= eer to give it a final review before you send it to the AD?=E2=80=9D And see if that prompt= s a coupla participants to say, =E2=80=9CYep, I had a look: ship it!=E2=80=9D Barry On Mon, Aug 17, 2020 at 4:22 AM Jaime Jim=C3=A9nez wrote: > Dear all, > > > > We are now closing this call. As you can see there have been no comments > on this WGLC at all, which is odd. > > The document does seem mature and the chairs would be happy to close the > call and ship the document, however I'd like to check with the AD (Barry) > to confirm that it's OK as we have gotten no feedback. We could extend th= e > call, but I am not sure that'd bring more comments. > > > > Thanks! > > -- > > Jaime Jim=C3=A9nez > > > > On Wed, Jul 29, 2020, at 7:44 PM, Jaime Jim=C3=A9nez wrote: > > > Dear CoRE WG, > > > > > > we would like to issue the WGLC for > > > https://tools.ietf.org/html/draft-ietf-core-senml-data-ct-02 > > > > > > This short draft specifies a new SenML field (=E2=80=9Cct=E2=80=9D) tha= t indicates the > > > content format of the data. > > > > > > The authors believe the draft is ready and we have discussed it on > > > several CoRE meetings. I think it is a great opportunity to provide > > > some last minute feedback so please, if you have a bit of time it is > > > only few pages long. > > > > > > We will close the call in two weeks, the 12th of August. > > > > > > Thanks! > > > -- > > > Jaime Jim=C3=A9nez > > --000000000000a4cb8b05ad18477b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I leave this to the chairs=E2=80=99 judgment, with t= his advice:
I=E2=80=99m concerned more with ho= w much review and discussion the document has had throughout it=E2=80=99s d= evelopment than with specifically the comments during WGLC.=C2=A0 If you th= ink there=E2=80=99s been enough of the former, be sure that the shepherd wr= iteup talks about that, and it will be fine.=C2=A0 If it=E2=80=99s really t= he case that the WG doesn=E2=80=99t have enough interest to have reviewed t= he document in general, then that=E2=80=99s a different coloured horse.

You could also, rather than= directly extending WGLC, post to the working group that there have been no= further comments and that the document is ready for publication... but tha= t you would like (pick a small number) three reviews that agree that it=E2= =80=99s ready. =C2=A0=E2=80=9CWho will volunteer to give it a final review = before you send it to the AD?=E2=80=9D =C2=A0And see if that prompts a coup= la participants to say, =E2=80=9CYep, I had a look: ship it!=E2=80=9D
=

Barry

On Mon, Aug 17, 202= 0 at 4:22 AM Jaime Jim=C3=A9nez <jaime@i= ki.fi> wrote:
Dear all,
<= br>

We are now closing this call. As you can see there have been no = comments on this WGLC at all, which is odd.

The document does seem m= ature and the chairs would be happy to close the call and ship the document= , however I'd like to check with the AD (Barry) to confirm that it'= s OK as we have gotten no feedback. We could extend the call, but I am not = sure that'd bring more comments.



Thanks!

--
<= br>Jaime Jim=C3=A9nez



On Wed, Jul 29, 2020, at 7:44 PM, Jaim= e Jim=C3=A9nez wrote:

> Dear CoRE WG,

>

> we= would like to issue the WGLC for

> https://tools.ietf.org/html/draft-ietf-core-senml-data-ct-02
=
>

> This short draft specifies a new SenML field (=E2=80= =9Cct=E2=80=9D) that indicates the

> content format of the data.=

>

> The authors believe the draft is ready and we ha= ve discussed it on

> several CoRE meetings. I think it is a grea= t opportunity to provide

> some last minute feedback so please, = if you have a bit of time it is

> only few pages long.

&g= t;=C2=A0 =C2=A0

> We will close the call in two weeks, the 12th o= f August.

>

> Thanks!

> --

> Jai= me Jim=C3=A9nez

--000000000000a4cb8b05ad18477b-- From nobody Mon Aug 17 13:09:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA23A1057 for ; Mon, 17 Aug 2020 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv730YCn0vFJ for ; Mon, 17 Aug 2020 13:09:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEDA3A1055 for ; Mon, 17 Aug 2020 13:09:32 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BVlWG6HD1zyYN; Mon, 17 Aug 2020 22:09:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 17 Aug 2020 22:09:30 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= , Marco Tiloca , core@ietf.org X-Mao-Original-Outgoing-Id: 619387770.3887891-63b3a5b1916c66ac49df47f6415de0ab Content-Transfer-Encoding: quoted-printable Message-Id: <7D29EADF-5712-4F03-B6E6-2F47130F5A1C@tzi.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 17 Aug 2020 20:09:35 -0000 On 2020-08-17, at 22:04, Barry Leiba wrote: >=20 > You could also, rather than directly extending WGLC, post to the = working group that there have been no further comments and that the = document is ready for publication... but that you would like (pick a = small number) three reviews that agree that it=E2=80=99s ready. =E2=80=9C= Who will volunteer to give it a final review before you send it to the = AD?=E2=80=9D And see if that prompts a coupla participants to say, = =E2=80=9CYep, I had a look: ship it!=E2=80=9D I=E2=80=99m no longer a WG chair, but I would have considered this very = good advice. The underlying problem maybe is that we have a hard time reacting to = requests that are coming from implementers =E2=80=94 we may not be able = to import these people into the WG permanently, so we need to get better = in dragging them in when their requests are actually being handled. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 17 13:23:05 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696483A1064 for ; Mon, 17 Aug 2020 13:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=X2NYPcGM; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=X2NYPcGM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACfKWfNK2sOP for ; Mon, 17 Aug 2020 13:23:02 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2076.outbound.protection.outlook.com [40.107.20.76]) (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 3E9283A1083 for ; Mon, 17 Aug 2020 13:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qNBuZI4ww6qG1xfdbhqMF3OvKbtie/nD7CUF8goMW+Y=; b=X2NYPcGMil5mWnVEVULktdVkOm8TSsEE9tCVAoG8XHjoMqJqsJ68/zRbPS4MA+N+fifEHOXxHK0Ch4TNFwo0MCLfAYI5q/l1ZQscr3DrjPyjZXEM8ofHDPKBx7nu6iaBaXU3GmHzJl4oBszMHRv7GsIDVaVf/P+dG3HrV+PE4EY= Received: from AM6PR0502CA0053.eurprd05.prod.outlook.com (2603:10a6:20b:56::30) by AM6PR08MB4200.eurprd08.prod.outlook.com (2603:10a6:20b:a8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Mon, 17 Aug 2020 20:22:55 +0000 Received: from VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:56:cafe::57) by AM6PR0502CA0053.outlook.office365.com (2603:10a6:20b:56::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15 via Frontend Transport; Mon, 17 Aug 2020 20:22:55 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT023.mail.protection.outlook.com (10.152.18.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Mon, 17 Aug 2020 20:22:55 +0000 Received: ("Tessian outbound 7a6fb63c1e64:v64"); Mon, 17 Aug 2020 20:22:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: cb659493caef5369 X-CR-MTA-TID: 64aa7808 Received: from a276ca32f02e.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E088D139-877C-4F4C-A0AF-334B963C985C.1; Mon, 17 Aug 2020 20:22:48 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a276ca32f02e.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 17 Aug 2020 20:22:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z6arb2pGozVvROBUNVbsiALOR469EAGW9FQ0s6Bio1r96ZPBTASmHaL7Q/IUK1gb0jWORrN4hibzcDjQJTlx1qo/jkLo2ntJHUxSyys8B/+I6CE/hgp/VfJYWRxVPCqRkHLZSS7WGTFIGbHX4/xag9g0WSIpVUmgn6/HcBP5MuHTgWDjJPXDemUzMqTdHMZi7DThWVWoHM1aAHckp397c+uBwi2jGHqD7H+lmqd/XwLAaQw2ozQufqEwWOCFIOuCEncepGQnoSwzRRuZS1uttPj50XnwI8WKH9sO6S8vh3Q8o93f1swE7KvYNeZnrZIN82Ry4/0UfBJ6Ba9te9ylsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qNBuZI4ww6qG1xfdbhqMF3OvKbtie/nD7CUF8goMW+Y=; b=Lq4/6xwVDlWt6rA+ZS31t+8fWoiWlnp21TB1R+abss/FzapPYk+52tB+7EI8RPYIUhssQsJ3M/NRQKV7AzvQRDB9gqTpMULvNipTgFtNvfJofIdAzTGvzCuN+MpfchPeRbWESnyG5cCwg8FacSgwW5woTCp692a/cnshkUgD1hLzHQtBroLV3rIiCDCm9FgTmtSArrNA+V1R6GGTCYCQ/+suSH8+EnDxwuvHAFxGOUTVxnh51a65dWdUlqDhkUSY4HuVHD4w97pGXFAOMwJC+bSGyDS81P465m74Mr1hf7S9SsmuMP+5Fh0qEQO8WZbBuCtn5eqpGPDPwPytYia/6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qNBuZI4ww6qG1xfdbhqMF3OvKbtie/nD7CUF8goMW+Y=; b=X2NYPcGMil5mWnVEVULktdVkOm8TSsEE9tCVAoG8XHjoMqJqsJ68/zRbPS4MA+N+fifEHOXxHK0Ch4TNFwo0MCLfAYI5q/l1ZQscr3DrjPyjZXEM8ofHDPKBx7nu6iaBaXU3GmHzJl4oBszMHRv7GsIDVaVf/P+dG3HrV+PE4EY= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB2999.eurprd08.prod.outlook.com (2603:10a6:209:44::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Mon, 17 Aug 2020 20:22:47 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::459b:bcf3:b888:c906]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::459b:bcf3:b888:c906%6]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 20:22:47 +0000 From: Thomas Fossati To: Barry Leiba , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= CC: "core@ietf.org" , Thomas Fossati Thread-Topic: [core] WGLC on draft-ietf-core-senml-data-ct-02 Thread-Index: AQHWZdAsCa4rxFgqy0uqoB2vd/JsSqk8E38AgADEFoCAABXlgA== Date: Mon, 17 Aug 2020 20:22:47 +0000 Message-ID: <5BA90EBB-51BB-4941-B91E-BBF607B37446@arm.com> References: 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.39.20071300 Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 73b976f3-18b5-4edc-a742-08d842eb5356 x-ms-traffictypediagnostic: AM6PR08MB2999:|AM6PR08MB4200: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: fIZD8+bRBfbKf7VbKV2VNGZqheFFJwLkjOH5eZ3m67LjBzCR8B3QVqACGI7ZLbjfCL4rwAo6cLVXrHjFawP+PT7/K6YXhApVYWUsp0SOKq+ZZxvg4tulPMKakl66zYpb4Mt/SAR3WM7Hnvs3nr43PLZ0yc6FVUPkT/zjK7is6wX0btugYN3ocPaNqzCagdhy1RLCqsZQCyUV9JUgwkrFe+ElcOmXVFBaJ+jOol6osoE4aClFaBSSOVeq28EkU0n3x+420eTVkHZfL2UKzOaJjg22QiGFuUz+E0Hatnuc4oMPwn2IhXMxUBEuULT0DIXP X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(6506007)(8676002)(26005)(110136005)(33656002)(186003)(66476007)(8936002)(66446008)(2906002)(4326008)(53546011)(64756008)(66556008)(71200400001)(2616005)(83380400001)(86362001)(76116006)(5660300002)(66946007)(6486002)(91956017)(316002)(478600001)(6512007)(36756003)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ibJWEUQwmasc0/mbuG7C8b26f/2HnwepvHD10Qll/rOOQZy+ZBlpBF8NFRkr2xutuedbVYCNCLhmvcU9Rk/0N1iA4JS7/tDrEOcUKfKGqqzgac7zpv2MkRN04+OTL1h0MaO4tgQjMmpw3w8WUNY0a9eFij9jmNtpbEwHO8cGMGdt8/9uYkHHpJCDRPJflVxnKTEUHE9+jaugtLebMqWPHnNpqhafa92/JqL0MYk7Jrpp3oWxfWuQelY72zfFM1aXNx6RZcCHzXe9XsSNB7qWHsXzfSEzkzLm570PGYH88KFuGLS68oBp3yVQKBqARidFNH+J3si44EveLGuOsVYPEUmnMl0ap79fLYVJhUKe+VEqeLbkxhZEz1ZhoRS//MfsCLiCHufe9IYVRHIEkTHZdJ2zMWmvheygv2yUeB+fXk/hCzJCGLdbYHRMmxnuplPiBgsr0w8GYHzaeveC2sbzZU3Ww+dndJJ5kCaKgctqmz/0+ak8A7XFXnddgOctStjba3p8n2ZAOYHhqz/xwcdl2RJVWts2TcJjXXgPTl3YjwBl89EQ0FZks2XQR9Zfm/bMm/a2QCkFbbHy0l5kMDhnOeFk1a7KkD3QStF3sG/3OgIMrZNPorkAW3PyrzsR60AzxWZ0ovTONpQRE70f0KTEPg== Content-Type: text/plain; charset="utf-8" Content-ID: <774D2FC68600DB4497B85EF66D278E98@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2999 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: a388971d-53ee-473b-c2e6-08d842eb4eb0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OVQnW1WlajtgMj6n8fz4dAUslBjyxtxya0mRuFtfBppOmfm6xBhpF280v44WZDzua1of2clIU//z08L1FPQS/t2yk81LEP6/b4cwXTMhhRp0AQOg76fw4ZfXDM93VylBKVvC00sR9THnIBZAuGi8bdMM2e/KYXaQWwJC/DG+I16BxxZUqQZ5vDM/+wHSnPnSslke8bZfDkNM3KVMcUQa5vgoUWoMOhzj/NJwRr4G8eARg+0OtKRIb6osEy4pWIdhjAEmQDL2IoQbG184UEgqwX8k6aD3RHVWD4NWgU3vjo9cUYhjncmbEAx2Cw/XxmqBxwmudb4WPTWWPAGdwGb2ZEt4HcnT059eGaKDxDOyzDSOvE4Tn8N3tRZEDbsj29zeihhw5xBpaZcS6aT8Gzh+ew== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(346002)(396003)(46966005)(5660300002)(70586007)(4326008)(36756003)(70206006)(2906002)(8936002)(6486002)(83380400001)(54906003)(110136005)(6512007)(8676002)(316002)(33656002)(81166007)(36906005)(82310400002)(82740400003)(26005)(186003)(336012)(47076004)(356005)(2616005)(478600001)(6506007)(53546011)(86362001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2020 20:22:55.4721 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 73b976f3-18b5-4edc-a742-08d842eb5356 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4200 Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 17 Aug 2020 20:23:04 -0000 SGkgQmFycnksIEphaW1lLA0KDQpPbiAxNy8wOC8yMDIwLCAyMTowNSwgImNvcmUgb24gYmVoYWxm IG9mIEJhcnJ5IExlaWJhIiA8Y29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBiYXJy eWxlaWJhQGdtYWlsLmNvbT4gd3JvdGU6DQo+IFlvdSBjb3VsZCBhbHNvLCByYXRoZXIgdGhhbiBk aXJlY3RseSBleHRlbmRpbmcgV0dMQywgcG9zdCB0byB0aGUNCj4gd29ya2luZyBncm91cCB0aGF0 IHRoZXJlIGhhdmUgYmVlbiBubyBmdXJ0aGVyIGNvbW1lbnRzIGFuZCB0aGF0IHRoZQ0KPiBkb2N1 bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uLi4gYnV0IHRoYXQgeW91IHdvdWxkIGxpa2Ug KHBpY2sgYQ0KPiBzbWFsbCBudW1iZXIpIHRocmVlIHJldmlld3MgdGhhdCBhZ3JlZSB0aGF0IGl0 4oCZcyByZWFkeS4gIOKAnFdobyB3aWxsDQo+IHZvbHVudGVlciB0byBnaXZlIGl0IGEgZmluYWwg cmV2aWV3IGJlZm9yZSB5b3Ugc2VuZCBpdCB0byB0aGUgQUQ/4oCdDQo+IEFuZCBzZWUgaWYgdGhh dCBwcm9tcHRzIGEgY291cGxhIHBhcnRpY2lwYW50cyB0byBzYXksIOKAnFllcCwgSSBoYWQgYQ0K PiBsb29rOiBzaGlwIGl0IeKAnQ0KDQpPbmUgdGhpbmcgdGhhdCBtaWdodCBleHBsYWluIHdoeSB0 aGlzIGRvYyBtYW5hZ2VkIHRvIHNsaXAgdW5kZXIgdGhlDQpyYWRhciBpcyB0aGF0IGluIEF1Z3Vz dCBzb21lIGZvbGtzIChpbmNsdWRpbmcgbXlzZWxmKSB0ZW5kIHRvIGJlIG9uDQpob2xpZGF5LiAg VGhhdCBzYWlkLCBJIHZvbHVudGVlciBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdC4NCg0KY2hlZXJz IQ0KDQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Mon Aug 17 13:31:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B7D3A10D3 for ; Mon, 17 Aug 2020 13:31:49 -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 qOw0xFAXiqqH for ; Mon, 17 Aug 2020 13:31:47 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 3BD4B3A10BA for ; Mon, 17 Aug 2020 13:31:47 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id q14so15694771ilj.8 for ; Mon, 17 Aug 2020 13:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lyAdJe5RivCPe/12uStoh1Mdm6p+6bRhYDz1KOsejk8=; b=jpXD2TEYMfN5KvPAY24cQo5VDGNS1Ig+I+RFaOsciPPV/0rzdY1CosWq/61xdaMi2t Ufrv79OiLCMhqLjIdqYexBVmP/CjctnpgZ2y41CQ6DeffGYhP8quMY8+1Tt2V1jmIhGq 3vNqCcqxH6x0q9jszOyVFw/1manFG7rpzf9OadrGGUmoG8YrdrOt+0VAf4J7BuXWUUsC AqQIdPtOMecj+O27S39EQxGL9E0G2rgSqKWn8Oo4bAViftHzOxZi8KrcYlMDrnIuz0+K e63ItylRuckhTUpw7gjTy7klHdD2tkS1+/iukblCJzLqNCsktE/QymLUrrOTJtmL5b8U rMTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lyAdJe5RivCPe/12uStoh1Mdm6p+6bRhYDz1KOsejk8=; b=Z0qZKT5OWl8c+LpIIqw6HEkfVMC8hu8mefmARNhsIHByeAgSfb9ylUPcyFFVo2iIDL 2koRsvxGS5vTW1TxUS5QnvK8s5AycjnK1pFdE5J+mevsb8MEMLWVKVKh7hP68akCrHPB u9kVMk9S+uZahuYl3ZFU4kXVElZsHDI62cpTMxvBJgZc7IPPH75GXRgjdHfWUTxXUS5s fP1PcNZOKCn6NJlQiciIF+hWEeFMf9uCklmyNAvhTpslZjCDfzecC4HjphYopmlcInOf cj4SgzTTveqQj8i83SEBclqExOJNQzOaGWV/G07vfkWm3Wy0o16NEwTDjqvMcBYTHlxV sBlA== X-Gm-Message-State: AOAM530RhTRhHz7fEX40KR9eI1vg3i3DYsIqeuAzHtrzvZUoBfj5/fqt Jby0IPx66YM/Shi8w+U/5aC9ocpYii3K+Vf0YhU= X-Google-Smtp-Source: ABdhPJwix/E3bJxF1A/mzngimYnKaqn55gTygVFrQ1gyBABr0l5VqmhNPHfz/naQIBF4ILNqFs7CiwCv6NrA91B5ZEo= X-Received: by 2002:a92:9a48:: with SMTP id t69mr16156045ili.114.1597696306256; Mon, 17 Aug 2020 13:31:46 -0700 (PDT) MIME-Version: 1.0 References: <5BA90EBB-51BB-4941-B91E-BBF607B37446@arm.com> In-Reply-To: <5BA90EBB-51BB-4941-B91E-BBF607B37446@arm.com> From: Barry Leiba Date: Mon, 17 Aug 2020 16:31:35 -0400 Message-ID: To: Thomas Fossati Cc: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cb213805ad18a837" Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 17 Aug 2020 20:31:49 -0000 --000000000000cb213805ad18a837 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Thomas! And, yes, August is always a challenge. Barry On Mon, Aug 17, 2020 at 4:22 PM Thomas Fossati wrote: > Hi Barry, Jaime, > > > > On 17/08/2020, 21:05, "core on behalf of Barry Leiba" < > core-bounces@ietf.org on behalf of barryleiba@gmail.com> wrote: > > > You could also, rather than directly extending WGLC, post to the > > > working group that there have been no further comments and that the > > > document is ready for publication... but that you would like (pick a > > > small number) three reviews that agree that it=E2=80=99s ready. =E2=80= =9CWho will > > > volunteer to give it a final review before you send it to the AD?=E2=80= =9D > > > And see if that prompts a coupla participants to say, =E2=80=9CYep, I h= ad a > > > look: ship it!=E2=80=9D > > > > One thing that might explain why this doc managed to slip under the > > radar is that in August some folks (including myself) tend to be on > > holiday. That said, I volunteer for reviewing the draft. > > > > cheers! > > > > > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > --000000000000cb213805ad18a837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Thomas!

And, yes, August is always a challenge.

Barry

On Mon, Aug 17, 2020 at 4:2= 2 PM Thomas Fossati <Thomas.Fo= ssati@arm.com> wrote:
Hi Bar= ry, Jaime,



On 17/08/2020, 21:05, "core on behalf of Bar= ry Leiba" <core-bounces@ietf.org on behalf of barryleiba@gmail.com> wrote:

> Yo= u could also, rather than directly extending WGLC, post to the

> = working group that there have been no further comments and that the

= > document is ready for publication... but that you would like (pick a
> small number) three reviews that agree that it=E2=80=99s ready.= =C2=A0 =E2=80=9CWho will

> volunteer to give it a final review be= fore you send it to the AD?=E2=80=9D

> And see if that prompts a = coupla participants to say, =E2=80=9CYep, I had a

> look: ship it= !=E2=80=9D



One thing that might explain why this doc managed= to slip under the

radar is that in August some folks (including mys= elf) tend to be on

holiday.=C2=A0 That said, I volunteer for reviewi= ng the draft.



cheers!










IMPORTANT NOTICE: The contents of this email and any attachments a= re confidential and may also be privileged. If you are not the intended rec= ipient, please notify the sender immediately and do not disclose the conten= ts to any other person, use it for any purpose, or store or copy the inform= ation in any medium. Thank you.

--000000000000cb213805ad18a837-- From nobody Mon Aug 17 23:51:16 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5E3A17C2 for ; Mon, 17 Aug 2020 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4-kF9bn9f-yh for ; Mon, 17 Aug 2020 23:51:12 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2A23A17C1 for ; Mon, 17 Aug 2020 23:51:11 -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 E8434407A0; Tue, 18 Aug 2020 08:51:08 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 99462AB; Tue, 18 Aug 2020 08:51:07 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:702d:2d59:5547:e4e8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1C47364; Tue, 18 Aug 2020 08:51:07 +0200 (CEST) Received: (nullmailer pid 809350 invoked by uid 1000); Tue, 18 Aug 2020 06:51:06 -0000 Date: Tue, 18 Aug 2020 08:51:06 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: 'Klaus Hartke' , 'Carsten Bormann' , 'Core WG mailing list' Message-ID: <20200818065106.GA728308@hephaistos.amsuess.com> References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> Archived-At: Subject: Re: [core] Message correlation with observe 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, 18 Aug 2020 06:51:14 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, CoRE, On Mon, Aug 17, 2020 at 08:39:36AM -0700, Jim Schaad wrote: > S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 > S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 In follow-up requests on the same token as Observe introduces them (and I hope to generalize), an important theme is that responses that relate to a particular follow-up message must be distinguishable as such where it matters. If just a plain refresh is sent, it doesn't matter whether a response relates to the old or new request (especially, it's not necessarily newer than the second request). If the ETag set is changed (which is the only permissible alteration in 7641), it doesn't matter either (even though a new ETag clearly indicates its generation after the second request). If an OSCORE inner refresh happens, there is clear indication that it's a later one because it only decrypts with the newest request's Partial IV. And if the observation is cancelled, a response only fits that by not carrying the Observe option, as Jon pointed out. Programmatically (at least in my implementation), all those responses wind up in the same channel (which I call PlumbingRequest, but maybe token channel or token subsocket would be more suitable), and it's up to the requesting mechanism (observation) to sort them. If S4 happened to overtake S3 on the wire, S4 would already be recognized as a response to C2, "slamming the door" for everything that's not a response to C2 (just like a higher observe value would make it disregard lower value responses). By that time, any CON/ACK has already been handled as that's purely on the Message-ID layer. Kind regards Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl87elYACgkQOY0REtOk veFN0g/+MtTkPO4snaSWCYm0zlM+4HhamoKVJqPHwgMjzyl2OE09vVp0KL8pyvkk r+l3P1yDWTUzI7vXRXsqZ+ODs9wqAcDAAMtZN/XqhP1ATcStoKZCLKoZAGCeaDkD 7ld0onIylRWNf7SZaoqZ08j66T+woDRKs3gcGSiHT5A5XpbUS8Po3rHIPhF9JMFM 4q+t2sdUYwIUGBFsUESQDzuTI6CieON1nhRJD4aQ45R5HR+A9ybVAgIotq+f6nD6 1c6YWIin2ggMH7xxGanTj44CRsezf58+m0A69hcotWnqzU2RAnm7ZwIqp0Yan/G/ c3WD/MRTLEDc3H65UiWu36xt8kkMKzHKUlIi9ubwQzzpLYOhEq4dGkTCO6sRjdie ooEvC3KXbTR+Rq6rMvusXF927tPNomigvmL4BeDsaS96fOBKObbEgZKWNCMULJZT V3J2gzd0ttj2nqyIaptMeVeMAyUq43OWUbSGXMRKADFwzs9UZ5yTOxf4iTf1vxY4 yz+sp4AGUg8wN/xmCf/YGaMUP0RDl/PhtPoayCpLxXlY2LWT7VX8bgquMuiFtmDN lzOd36g+LwWHnpnf2nJuFGFRW4alx2NiscWSv/1JwIn7u/Stv9v+sZfm2rWn8AMx eA4sWc4qHWz2IQ7pcx2DOy5xyCmnqXplKSAnaPqCeo8xLfA+LGs= =JYue -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From nobody Tue Aug 18 02:57:26 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1EF3A03ED for ; Tue, 18 Aug 2020 02:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2p7UAdYfSf8 for ; Tue, 18 Aug 2020 02:57:22 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3602E3A0365 for ; Tue, 18 Aug 2020 02:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1597744641; d=isode.com; s=june2016; i=@isode.com; bh=/A9x3vHokFbo5EglEPZnoCuQEdt5dDVw4oaQupFUpHo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wMk6VoWsmGVj930R6isyn9E+vDbAKrwZHzsJfa+P4BhtGCu8FpoDD2aL8m+fCLCtQ4wAT4 oWNsyjolCKuNsdWb48dZiFxOsdZ0XZDPc1uib+7kNuDByVZriOV3K+MZkdcsU/xqjVabRw ePlnlivNdm8jHOJzTH3CrW2Q5oxeJsQ=; Received: from [172.27.253.188] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 18 Aug 2020 10:57:20 +0100 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , Barry Leiba Cc: core@ietf.org References: From: Alexey Melnikov Message-ID: <475655ce-6ffd-9cad-d0d2-220bba4d2b5a@isode.com> Date: Tue, 18 Aug 2020 10:57:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 18 Aug 2020 09:57:24 -0000 Hi all, On 17/08/2020 09:22, Jaime Jim=C3=A9nez wrote: > Dear all, > > We are now closing this call. As you can see there have been no comments o= n this WGLC at all, which is odd. > The document does seem mature and the chairs would be happy to close the c= all and ship the document, however I'd like to check with the AD (Barry) to = confirm that it's OK as we have gotten no feedback. We could extend the call= , but I am not sure that'd bring more comments. Sorry for the belated review. I think the document is nearly ready for=20 progression. I have a couple of minor related issues: 2.=C2=A0 Terminology =C2=A0=C2=A0 Readers should also be familiar with the terms and concepts di= scussed =C2=A0=C2=A0 in [RFC8428].=C2=A0 Awareness of terminology issues discussed = in =C2=A0=C2=A0 [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it=20 should be revived. (Or see below) =C2=A0=C2=A0 helpful. 3.=C2=A0 SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF=20 from draft-bormann-core-media-content-type-format-01, it should be=20 Normative reference. If not, I think you should just cut & paste the=20 ABNF into this document. Best Regards, Alexey From nobody Tue Aug 18 05:33:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688963A091D for ; Tue, 18 Aug 2020 05:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=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 P-iSyIshgfaj for ; Tue, 18 Aug 2020 05:32:58 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A18E3A092E for ; Tue, 18 Aug 2020 05:32:57 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BW9Ky3tZSz102J; Tue, 18 Aug 2020 14:32:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <475655ce-6ffd-9cad-d0d2-220bba4d2b5a@isode.com> Date: Tue, 18 Aug 2020 14:32:52 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , Barry Leiba , core@ietf.org X-Mao-Original-Outgoing-Id: 619446772.509203-a16d03db846eecc3ce0bd463487c89a0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <475655ce-6ffd-9cad-d0d2-220bba4d2b5a@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 18 Aug 2020 12:33:02 -0000 Hi Alexey, On 2020-08-18, at 11:57, Alexey Melnikov = wrote: >=20 > I wish the document has ABNF for the "ct" field. If you want to use = ABNF from draft-bormann-core-media-content-type-format-01, it should be = Normative reference. If not, I think you should just cut & paste the = ABNF into this document. This is a good point. Since data-ct needs almost all of the =E2=80=9Cnormative=E2=80=9D ABNF = in media-content-type-format, I think the right thing to do would be to = fully develop media-content-type-format and make it a normative = reference. (Note that media-content-type-format probably needs to be = run by httpbis and emailcore [?] soon and when it is nearing WGLC, and = there may be surprises there.) This course of action would probably delay data-ct a bit; we might = counteract the damage by early registration. Since data-ct only needs = an =E2=80=9CExpert Review=E2=80=9D registration, we could decide to do = this when we have processed the reviews that are now incoming. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 18 05:45:54 2020 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 EFD363A09A4; Tue, 18 Aug 2020 05:45:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <159775475393.3893.14203926983080034828@ietfa.amsl.com> Date: Tue, 18 Aug 2020 05:45:53 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-00.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: Tue, 18 Aug 2020 12:45:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-00.txt Pages : 23 Date : 2020-08-18 Abstract: This document specifies new Constrained Application Protocol (CoAP) Block-Wise transfer options: Block3 and Block4 Options. These options are similar to the CoAP Block1 and Block2 Options, but enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 18 05:56:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA86E3A09F5 for ; Tue, 18 Aug 2020 05:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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.949, 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 Fxxisu2AukUk for ; Tue, 18 Aug 2020 05:56:22 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::603]) (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 A8FA73A09EE for ; Tue, 18 Aug 2020 05:56:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MQemO8tnDukUqVtUS0bdBcJDkYEYpxbktxZAM8NizBolKUi8wSkxrEeNlqDp59WS5hB4bXw/OZPL7IHN7KlGtUDuZloTtx8AaqlSSujrpaPEj5a8aMP/fo1YOM1lMvhrFnLnXZhk0Q3vKcDnvl6s3Z2/cm26AMF+HtzRk0wC4ttS+soO3/AMDFSxRIFaxI8IQQ6aNe9c+Zv6oFqzApjUx+LZlrL2hj1GpTlproix1CNpta8P1R6kmbZdUKLQvYiEnXzLjfLqjxUDVPVImfo6ZhM3g6WfjO2CGXvyM0J7kA2sQtblFDs2VW1o42OoZ+fyFsYcoEap875lfNhCyMWJJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QYC6JuC8cuA+w9kbr6EBSE8FBtGU18kgC/pDKhpkYwk=; b=GBiweyRRO/zCfhC6Oa50hLIcT/W40vUb7sHD6QVnln4dScS3JZF7thBDaXH34BnN6f2PMjvmNJ10ptBK8W3NWDID4C7tojwFjsKI/36Ynj+ZxMBkjxCTUYKFqr3bc7EeXH5dptH1sIyHtgEAkD70zEV9SOTPlh/B/pKaWVCnZmRxvGhxAEQz7ViaOaDVmOHyb3u5trLYHhgpIFdKgGi5NL8zi01iaoCXebk8UHMk+elGm6jqVV5DKAEmqVw0u8lFONNFhlglLEhNDyX79iuQ8LaScFrGl/QSfJXzjZQIBcOFmKc1/Je9b73+0HCpp4Y312NzVnjspX8JBiR77HSFGA== 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=QYC6JuC8cuA+w9kbr6EBSE8FBtGU18kgC/pDKhpkYwk=; b=itovx810lNhr8wrdyYErBF+XaCE9yzKRVwJsvh1op75yM81/jNMum5/J5nZmPCbadIJ1H3xpX1Uo0jZeMFwKb3Xw+aVq5bOUpBDtYWZfwXmR1LHwFaIGs3PEk602uKu/42omUU+S/Y7RJQRaG+ZifZ6cWuBKjWXn+LvmgfmO3jc= 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 DB8P189MB0812.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:125::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.27; Tue, 18 Aug 2020 12:56:18 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%8]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 12:56:18 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <8d785827-99ba-ca7d-cd1e-bc4f03c71def@ri.se> Date: Tue, 18 Aug 2020 14:56:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2xcOZydDbARdzqh43nW6iONPRiNqmoHji" X-ClientProxiedBy: HE1PR0701CA0071.eurprd07.prod.outlook.com (2603:10a6:3:64::15) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.12] (91.132.138.228) by HE1PR0701CA0071.eurprd07.prod.outlook.com (2603:10a6:3:64::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.16 via Frontend Transport; Tue, 18 Aug 2020 12:56:18 +0000 X-Originating-IP: [91.132.138.228] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 89d43e89-7fa6-4ee2-1f8a-08d84376196e X-MS-TrafficTypeDiagnostic: DB8P189MB0812: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uGZeb2VkqU0/RexjKrBo0HGqTD4saS/rTrxAz6chvGRvZHLOpCXv6QdGjvDmWTwf7UyLBK2oBghnVMH4WT75PCissP49uhis6FwUAPrg4VgDll8iV+be/9tst90t9A/iAEidF2odpUaeD2ZjayI9aDuYHXKnsde100OWbQqbaufxkekgjtdg8u4pzJkbrxKbPSKJT5KBl4AmMKeygYqpvO/weyi7Px4PVY3Cop7d3hGhplY2RM42fFqyIdjjMdgaHVYTneUJur2DDlUrEnoFiaoDn4MtkGd0M5SpaZSwwqN1R+mwB9S1duNkT0OlJbcQKjvICMxt0OmzS0NhcGTy+Tsp24odIZTOoXN73KNZa3C8HdZejhEJuaG/5AzQ8f0W/b33AN4SEMCsnlFwLJDmp44sn72aWbtyH1fTBW4tZ1Vx1VkRjy46NNcT9Ot9GNeCAkxbm5NkA7I9pv1HK983Og== 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)(136003)(366004)(346002)(376002)(396003)(39850400004)(16576012)(33964004)(6486002)(86362001)(31696002)(53546011)(6916009)(956004)(316002)(44832011)(52116002)(66556008)(2906002)(6666004)(478600001)(36756003)(16526019)(66574015)(66946007)(186003)(5660300002)(83380400001)(966005)(8676002)(21480400003)(235185007)(8936002)(31686004)(26005)(2616005)(66476007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: R/JWGAO8zNsy5T7oX31vItzbOKE74Ggy9OxnI0rXxCJov4DD4OfHiGDENWYIKpyT7xV9sGNLHKMoxDWx4WuKGcYSDIc2JfXI1qu9dxtXpb0XBFeRc6wS/TFVtZaIc+iQTWITWVYHU/kXEqOnh+pr7bgIvGDi5oxHAqu/at+b1ralqung2T90AyWZZBwzLseUvCp6qjdSpzEYmucymBKtlQJ0tkeAot2rS7w7Ck+zR0kuypXnyrorQhW7YgBirvb2SMfKV86lKJ1QppI0h4bDWiPC5fvc5qnBHUHMvl6CRK9xFQOEYZbgPjg5Oi8pzjXte3hAFyS0msN6K9zoQgm9ib2bWeTwUqSb7LPg+z6SipMJ3GLlMTLT+TnIN8/OveCPsmh3FczBWSEKB4yat7DekWW8G+h/hhGAZQk7JaSD/FtILmFmG7oXL4t0JbQdKOn9SGEh8VYPBb6AG0nOffgryykW6spyVdkFuywfIHp+IsaWDdzpa4TwyWWtAJhSf0IXGiuAUENJ7dW8LrvL70c6wZXowpOzdWQ+wsOR+oT/4xmfuf+J18mFag1pqYKYM+BKhFRfPSH+VRLglBi2GGhvWRR1RKMfpNZMJ5pU/gQwmunQR/eeVm8l93dENrSUNCjDkLOrO4fNnrvTq2uANP8stg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 89d43e89-7fa6-4ee2-1f8a-08d84376196e X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 12:56:18.7014 (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: J1ad7SDxcuGNXIAmfod9clJtMnkKq3Nl4bpVkXjyh5MhSK1ej6lrg4dxR6Kaw6HsaWKNxCeCEvEN8B9qUsxoqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0812 Archived-At: Subject: Re: [core] CoRE interim meetings 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, 18 Aug 2020 12:56:32 -0000 --2xcOZydDbARdzqh43nW6iONPRiNqmoHji Content-Type: multipart/mixed; boundary="K4MUgAWCLGkmkNnsjKHaqKfznLcB7ZvMy" --K4MUgAWCLGkmkNnsjKHaqKfznLcB7ZvMy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a kind reminder, please fill the Doodle poll below by Thursday, the 20th of August, EOB. https://doodle.com/poll/cb9qshfymw6tdgna Thanks to those who have done it already! Best, Marco and Jaime On 2020-08-04 19:07, Marco Tiloca wrote: > Dear all, > > We are planning to schedule regular virtual interim meetings, recurring= > every other week, starting from the second week of September and until > the end of October. > > Please, cast your preferences at the Doodle poll below, by the 20th of > August EOB. > > https://doodle.com/poll/cb9qshfymw6tdgna > > The options in the Doodle refer to the week of the first interim > meeting. The following meetings will occur every other week on the same= > weekday and time, until the end of October. > > Best, > Marco and Jaime > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --K4MUgAWCLGkmkNnsjKHaqKfznLcB7ZvMy-- --2xcOZydDbARdzqh43nW6iONPRiNqmoHji Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl87z+oACgkQ7iZktA5Y 2kPh2Af/Y91MYjcR3cPtZYsMDXjWqnq5l71HgWgkP09L56LCLktWSuADhfSvFkLK 2UhlaJpMohicElqDHqIgnJXv4iLeMFgPaUU+8LtVW+4PI0vxCVcg+LTnRSXk5kr1 cbTiSJO21vgm4u6uXFFLKoJSXJzYgUHzlUqofhJiaSXMvC1abpniFuk2ebyDLDGy IMBSoPfHcCmvBV5Wlttc3S1wBZfFflTBv5gmbDV9BlPEDUBeY0u40jPWjlR0Lt1r +VMRWBPM9Pwo2PGz0KwhmVEwK6zyhxoeG9CbhBgSIDTXu64wWid9JpbfEH931mC4 gihcfqLcOUGtVtRhdZsffbAjXL9mgA== =G49R -----END PGP SIGNATURE----- --2xcOZydDbARdzqh43nW6iONPRiNqmoHji-- From nobody Tue Aug 18 12:29:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5496C3A0AD9 for ; Tue, 18 Aug 2020 12:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=RY/5brxu; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=RY/5brxu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoqKcYTkpclm for ; Tue, 18 Aug 2020 12:28:56 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40078.outbound.protection.outlook.com [40.107.4.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 5AFC43A0ABB for ; Tue, 18 Aug 2020 12:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31gMCn81NTrB5LzJ6zJKUmMeanGFSNGBZRf2rjEf+tw=; b=RY/5brxufGlzON69h6le5g2bKiNgOu8Nbse4/GSt8EAO+kv8ZvsblPo0PLHaMsjdnVvAEYB3IWDBa3D3VHNZ/RWtRulsPOtBBXOz920RfRhkPw4Uo7rGPZ7JxbmX2OCt3NQbDoW47UdK1ed6Xdu+IGhrPprVYm+kgXgP76r3yHU= Received: from DB8PR04CA0027.eurprd04.prod.outlook.com (2603:10a6:10:110::37) by AM6PR08MB5000.eurprd08.prod.outlook.com (2603:10a6:20b:e6::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18; Tue, 18 Aug 2020 19:28:53 +0000 Received: from DB5EUR03FT031.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:110:cafe::16) by DB8PR04CA0027.outlook.office365.com (2603:10a6:10:110::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Tue, 18 Aug 2020 19:28:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT031.mail.protection.outlook.com (10.152.20.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Tue, 18 Aug 2020 19:28:52 +0000 Received: ("Tessian outbound e8cdb8c6f386:v64"); Tue, 18 Aug 2020 19:28:52 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ad5f9b15bf3fbb85 X-CR-MTA-TID: 64aa7808 Received: from bd18fff71e55.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B5EA0DF4-3AB2-4C28-AC9A-1FE9BCFF79E3.1; Tue, 18 Aug 2020 19:28:47 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id bd18fff71e55.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 18 Aug 2020 19:28:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n2po2x0qzQBkIj7cy+JGSgLieUfCcUzKU/OdDr053pQ9mYIWWl5TbEKABjn0ZEYcDbVsDVMlrYJU3en9OLNPWzK9t5SmSwYATXs0UC0ore4DG1wAXh7jqgLYDJk1CbdAmbe1EYh+PBPEDtpNmLyH5n7oQjkfQ3IThSm9mR8I1n8t+nY/UN3f1zfK9UHfCWiptKimzcAlzmV8DkPYAJCPbhfh1uaWGmu75OY2250JIXwaoncND9oH13DQ3WGg/5Q7iwutD9EJ3yic2GgRXeaH9VvHhXWSzR3zdTfKKB7IN+oaCwKrOCMDtxcm23eoKX9TIpiT2ngYcVv36aqaKDngag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31gMCn81NTrB5LzJ6zJKUmMeanGFSNGBZRf2rjEf+tw=; b=hthZ3dLToxd5tqtFxkJQ1CAfvBquwdUZ6SwQ9hOW1EAtC4SuZPWg3oxJzOTAXH8avKBWDmvkbZghjAR59LLwvyvIV0hYfdvEuGywbUOeDnfUCV9fNnuH/9sFmnCiyC1QWZqZmrXYOqzdS5+zTrv1kimZEFRlHVIH/BiGeu4WhKLinB2wvP4Q7OSVbismra1/o1m18hjlW2wwnuXIFL/5MRG7hPNPj3NjGVVL2hmA99LbbsVjHgrC/L9t6hLr3ySHkc4HdjrEuaQJvBCX7t0I33wzdsFYFUQEkSAG0Lu0+ebuM/T2B4D9eGuO2CXjCipFbf+IB+cJvbz3I5BbyHgZOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31gMCn81NTrB5LzJ6zJKUmMeanGFSNGBZRf2rjEf+tw=; b=RY/5brxufGlzON69h6le5g2bKiNgOu8Nbse4/GSt8EAO+kv8ZvsblPo0PLHaMsjdnVvAEYB3IWDBa3D3VHNZ/RWtRulsPOtBBXOz920RfRhkPw4Uo7rGPZ7JxbmX2OCt3NQbDoW47UdK1ed6Xdu+IGhrPprVYm+kgXgP76r3yHU= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM5PR0802MB2562.eurprd08.prod.outlook.com (2603:10a6:203:a1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Tue, 18 Aug 2020 19:28:46 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::459b:bcf3:b888:c906]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::459b:bcf3:b888:c906%6]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 19:28:46 +0000 From: Thomas Fossati To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" Thread-Topic: [core] WGLC on draft-ietf-core-senml-data-ct-02 Thread-Index: AQHWZdAsCa4rxFgqy0uqoB2vd/JsSqk+cLaA Date: Tue, 18 Aug 2020 19:28:46 +0000 Message-ID: References: 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.39.20071300 Authentication-Results-Original: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8e03ff78-df3f-4390-0ff3-08d843acf102 x-ms-traffictypediagnostic: AM5PR0802MB2562:|AM6PR08MB5000: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: xaQvY9iVrarn9sIolpzHyyNXC1TmtHexfU0ZFjMyLZ43bWk4T0AV9MyX3/eoDCaPUgS0WEe7mj6/ck+JzIOXVN0jkVSHsCWBdU91Rlnh9alj7EMU/QVpKMO6lSd6czU39imSMj+L8XmfZRos4MaYni/4eiNFDpoBGbyn6mQMNnmUwP3jq7u8VNzITDP52Itubpw8p7lRRfJ+6zkNkqyo6Hjrjm65jv54yiXOO+HlWod/SXBFNPIKNoorZZ1j+6mEczYV4nWQmG6DV+p3c/5gG/sEigQWUTm4XFPpgRDlu+u405XXpUunIP1w9EI2bF8LkEVgizO8XSGzgv24PibKRQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(396003)(346002)(136003)(376002)(5660300002)(26005)(66574015)(86362001)(2906002)(4326008)(8676002)(71200400001)(2616005)(478600001)(186003)(6512007)(66556008)(6506007)(66476007)(66446008)(76116006)(83380400001)(8936002)(66946007)(91956017)(33656002)(64756008)(316002)(110136005)(36756003)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AhKsGPEPFBiDeVv4iCTQVAZQ+5fcWxaI0PV0TJkTPzK98RJynQ1JfdeJ887vBq045GakBx76FYf7fl1PybUcsTa7hk5laSSUjW76ihz7l/W9FJ74p6sWqPYlrNS3kMMkeAjQJGodH7Pw0YL+mLZY8WD8HG6iPdEVkdOI0AdU7rTorrPV/d2ku3SzUeYakV6dexIUpJyP7v58PbFKo57TyRbf39BUQbCBN7oRnapvGgJEpQQE9yW541wO9JpCuT+4EY3WnQ1s2WG8y1kwcOycL2rL9lmLnGRidD1eFDodSBGNxGXHh/eQaGHwt53Bjo+KUl4GMFVbiWYkKCM9RTgG1sAnw09Ke3t8zMohFLtY8a3KzRSF5XwGkyq0WT43as+QvtJNyhUpN5jQ2kNll/m5Z582kdTou1dCh5+3zQmLAtP7yr33h3lcnlw8bZ7VzkUkHvafZKCGdk2cd6BFdtzGhRrUr+Bf5OATs5knEHN+Uhwowdc8vbT/8vbPi44Ai9jiFYM30YEgisanj2GDI4knNDU+XcoTBV+jmwVuJfXXW0Dm+P67EcTnt/eSg6Zdhy++zL4Rl483nwv2Q3Cnegl4C175JzxVeSlbamLcGdmlpLQbpFEl4wsPXi6rC242C3mXTGux3rztUM+FzLS3zPqTRA== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2562 Original-Authentication-Results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT031.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d7b294f4-a2b6-4064-7ae8-08d843aced44 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WRPeeZiJhMeq3sDAwE5J3IWnL0Lavz3l3Qwww0fGqid0CH+r7RnQhk4vLTaaCTdYxoNCBINffKghynOZrsUKglfEESU5cRMgshYSEnX/UtgxL5t24L/j4E0j6S2a5ueNGvhZiwUBHo9LeFL8MqjaaD6TW9O9A39d/YhlXWm98FmTm+HfJ5d4VlIUKFox1aoblX4lXVOfehGslXcMP0kuh5U/qZtzKZjRHWRSqisHW1/ma74CmdaesVMxYEcpe81Zc/0tgsI3kzRBziErlGv0gTGaNiGnKsFkBtmuH7FEH3FKZd6uw81PnHsvnJPIyZVjjcqPqArkL+B++tTBaMDWGBQOV0bS21B76YiscePZRBYlR1rYci/rvr+VpgaHlOnLMNGBhQ1ajodmmy7C6BSTiA== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(39850400004)(376002)(46966005)(66574015)(316002)(33656002)(2616005)(110136005)(356005)(336012)(82310400002)(83380400001)(70206006)(5660300002)(8676002)(86362001)(70586007)(82740400003)(81166007)(4326008)(26005)(2906002)(47076004)(6506007)(478600001)(6512007)(36756003)(186003)(8936002)(6486002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 19:28:52.9745 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8e03ff78-df3f-4390-0ff3-08d843acf102 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT031.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5000 Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 18 Aug 2020 19:28:58 -0000 SGkgQXJpLCBDYXJzdGVuLA0KDQpJIGhhdmUgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1jb3JlLXNlbm1s LWRhdGEtY3QtMDIgYW5kIG92ZXJhbGwgaXQgbG9va3MNCmdvb2QgdG8gbWUuICBJJ3ZlIGxlZnQg YSBmZXcgYW5ub3RhdGlvbnMgYmVsb3cuDQoNCkNoZWVycyENCg0KKiBTZWN0aW9uIDEsIGZpcnN0 IHNlbnRlbmNlOg0KICAgICogT25lIG9mICJ2YXJpb3VzIiBvciAiZGlmZmVyZW50IiBsb29rIHJl ZHVuZGFudCB0byBtZS4NCiogU2VjdGlvbiAyLCBsYXN0IHNlbnRlbmNlOg0KICAgICogSS1ELmJv cm1hbm4tY29yZS1tZWRpYS1jb250ZW50LXR5cGUtZm9ybWF0IGlzIG5vdCBqdXN0IHZlcnkNCiAg ICAgIGhlbHBmdWwsIGl0IGFsc28gY29udGFpbnMgdGhlIGRlZmluaXRpb24gb2YgQ29udGVudC1D b2RpbmcNCiAgICAgIHdoaWNoIGlzIG5vdCBmb3VuZCBlbHNld2hlcmUgQUZBSUsuDQoqIFNlY3Rp b24gMywgZmlyc3QgcGFyYToNCiAgICAqIHlvdSBtaWdodCB3YW50IHRvIHJlb3JnYW5pc2UgdGhl IHNlY29uZCBzZW50ZW5jZSAoc3RhcnRpbmcgd2l0aA0KICAgICAgInRoZSBDb250ZW50LUZvcm1h dCBpbmRpY2F0aW9uIikgdG8gbWFrZSBpdCBtb3JlIHJlYWRhYmxlLg0KKiBTZWN0aW9uIDMsIHRo aXJkIHBhcmE6DQogICAgKiAiWy4uLl0gYXBwZW5kZWQgdG8gdGhlIENvbnRlbnQgVHlwZSBfdmFs dWVfIChtZWRpYSB0eXBlIFsuLi5dIg0KKiBTZWN0aW9uIDMsIGxhc3Qgc2VudGVuY2U6DQogICAg KiBNaWdodCBiZSByZXN0cnVjdHVyZWQgZm9yIHJlYWRhYmlsaXR5OyBvbmUgc3VnZ2VzdGlvbjog IklmIG5vICJAIg0KICAgICAgc2lnbiBpcyBwcmVzZW50IG91dHNpZGUgYW55IG1lZGlhIHR5cGUg cGFyYW1ldGVycywgdGhlIGNvbnN1bWVyDQogICAgICBjYW4gYXNzdW1lIHRoYXQgbm8gZW5jb2Rp bmcgdHJhbnNmb3JtYXRpb24gaGFzIGJlZW4gYXBwbGllZCB0byB0aGUNCiAgICAgIHJlcHJlc2Vu dGF0aW9uLiINCiogU2VjdGlvbiA2Og0KICAgICogTWF5YmUgYWRkIGEgbWVudGlvbiB0byB0aGUg cmlza3MgYXNzb2NpYXRlZCB3aXRoIGNvbXByZXNzaW9uDQogICAgICBjb250ZW50IGNvZGluZ3Mg KHppcCBib21iLCBldGMuKSINCiogU2VjdGlvbiA3Og0KICAgICogTm90IHN1cmUgYnV0LCB3b3Vs ZCBpdCBiZSB3b3J0aCBhZGRpbmcgYSBub3RlIHJlZ2FyZGluZyB0aGUNCiAgICAgIGZvcm1hdHRp bmcgcnVsZXMgKGkuZS4sIGFuIGV4cGxpY2l0IHBvaW50ZXIgdG8gU2VjdGlvbiAzKT8NCiogU2Vj dGlvbiA4LjE6DQogICAgKiBXaHkgaXMgQ0JPUiBub3JtYXRpdmU/DQogICAgKiBXaHkgaXMgdGhl IFNlbk1MIHJlZ2lzdHJ5IGEgbm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KDQoNCg0KDQoNCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Aug 18 13:12:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874173A0B34 for ; Tue, 18 Aug 2020 13:12:48 -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_H4=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 8pLVos1z2UsI for ; Tue, 18 Aug 2020 13:12:46 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D63A0AFB for ; Tue, 18 Aug 2020 13:12:45 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWMXX05h5z1058; Tue, 18 Aug 2020 22:12:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <475655ce-6ffd-9cad-d0d2-220bba4d2b5a@isode.com> Date: Tue, 18 Aug 2020 22:12:42 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , Barry Leiba , core@ietf.org X-Mao-Original-Outgoing-Id: 619474362.591797-9ba3fc86c37126cc04dd9bd115d910d4 Content-Transfer-Encoding: quoted-printable Message-Id: <7BB8A2E8-A85D-4DEB-9531-FC1CDE30DA22@tzi.org> References: <475655ce-6ffd-9cad-d0d2-220bba4d2b5a@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [core] draft-bormann-core-media-content-type-format-02 (Re: WGLC on draft-ietf-core-senml-data-ct-02) 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, 18 Aug 2020 20:12:48 -0000 On 2020-08-18, at 11:57, Alexey Melnikov = wrote: >=20 > It is expired and it is currently not a WG document. At minimum it = should be revived. Done. (I left one bug in, of course to check whether anyone reads this :-) Status: = https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-for= mat/ HTMLized: = https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-0= 2 HTML: = https://www.ietf.org/id/draft-bormann-core-media-content-type-format-02.ht= ml diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-media-content-type-= format-02 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 18 13:16:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD13A0B80 for ; Tue, 18 Aug 2020 13:16:43 -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 GDX2LAIYcjza for ; Tue, 18 Aug 2020 13:16:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A2E3A0B79 for ; Tue, 18 Aug 2020 13:16:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E939389BD for ; Tue, 18 Aug 2020 15:55:49 -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 fm0ztd_4I1uS for ; Tue, 18 Aug 2020 15:55:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AFA5F389B4 for ; Tue, 18 Aug 2020 15:55:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6C097B for ; Tue, 18 Aug 2020 16:16:39 -0400 (EDT) From: Michael Richardson To: 'Core WG mailing list' In-Reply-To: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Message correlation with observe 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, 18 Aug 2020 20:16:44 -0000 --=-=-= Content-Type: text/plain having read the rest of the thread... Jim Schaad wrote: > C1: GET /temperature MID:10 Token: 0x4a Observe: 0 > S1: ACK 2.05 Content MID:10 Token:0x4a Observe:12 Payload:22.9 > S2: NON 2.05 Content MID:11 Token:0x4a Observe:44 Payload: 22.8 > I now do a proactive cancel > C2: GET /temperature MID:15 Token:0x4a Observe:1 > I now get two responses back > S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 > S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 It seems to me that the new C2 operation, not being part of the original Observe, ought to expect and match the MID:15. C2 is new transaction, even if it really cancelling C1. I understand that the MID would otherwise be ignored. I can also see a client, upon seing S3, might assume C2 got lost, and retransmit C2. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl88NycACgkQgItw+93Q 3WXAJAgAjUPdLddiNkV9617RnYeQQ7Q3cGFC2rBnxIcL4HsQclb0unCtlz09opfm 2X77kT6JpYC4lC+sIJxv2xn0aXM+GVk9wbIKCikx5HjMDMvevzoiMcxVCApf2tNK rl7yMd0K0yBPes4T1QpxyzLvB9cVK/b7393MbO1x5lzFzbOCq59Xqd54RIeTRxub g3wwMjkEc9RDd4YIBxZgRrzPwTI8qIED3l9/5OIRFNjkVu1lGOibgSdMMWXZiGgd Boo5ZZoVAVhC88l83j2he1zkKgVE4Zym9AVlwID/HX+fJe6voGUGHIKuLI5M9Svz O12xlpFQ1Z7CDXGtUv55m3SnQ61BXw== =64c4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 18 13:54:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6843A0C55; Tue, 18 Aug 2020 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b1D5P_rzmBUb; Tue, 18 Aug 2020 13:54:38 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518263A0C45; Tue, 18 Aug 2020 13:54:38 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Aug 2020 13:54:26 -0700 From: Jim Schaad To: CC: 'Core WG mailing list' Date: Tue, 18 Aug 2020 13:54:23 -0700 Message-ID: <01c401d675a1$c2f5a030$48e0e090$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZ1kli3yS7o6MmQTO6FHLZDoKj6KA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Review of draft-tiloca-core-oscore-discovery-06 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, 18 Aug 2020 20:54:40 -0000 In the previous review response you indicated that there was a switch to security group through out the document. This was not true for the introduction or abstract. Section 2.1 - wording cleanup OLD: Therefore, in the RD defined in [I-D.ietf-core-resource-directory] and based on Link Format, possible values registered as a string that looks like an integer, e.g. the string "-10" in the 'Value' column of the "COSE Algorithms" Registry [COSE.Algorithms], are not supported by this approach. Therefore, they MUST NOT be advertised through the corresponding parameters above. NEW: Therefore, in for RDs that return Link Format, string values which look like an integer are not supported. Therefore, they MUST NOT be advertised through the corresponding parameters above. Section 4.1.1 - Add the lookup to get the auth server as well Nits: This is pure bike-shedding I find the ".mbr" of the rt slightly confusing although I recognize this is not really for human readable, but ".gm" might be better. From nobody Tue Aug 18 19:30:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDC93A1103 for ; Tue, 18 Aug 2020 19:30:06 -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 L_Qbd-6GP_fS for ; Tue, 18 Aug 2020 19:30:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9803A10EB for ; Tue, 18 Aug 2020 19:30:04 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Aug 2020 19:29:58 -0700 From: Jim Schaad To: =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= , CC: 'Barry Leiba' References: In-Reply-To: Date: Tue, 18 Aug 2020 19:29:57 -0700 Message-ID: <01db01d675d0$a309e3b0$e91dab10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKJSILIXo3Sjo0LlmpzZnykvLzT7wG8MiFop8stIQA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 19 Aug 2020 02:30:09 -0000 For the most part it looks good. However, I am not sure that I = understand what the correct behavior for=20 {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","vs":"7.1","ct"= :"0"} {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0= "} Should the ct be ignored if the value is not "vd"? If it is present but = does not make sense what should happen? Jim From nobody Tue Aug 18 20:36:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD32D3A10F9 for ; Tue, 18 Aug 2020 20:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pCZhvpNWCTV8 for ; Tue, 18 Aug 2020 20:36:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1306D3A10CE for ; Tue, 18 Aug 2020 20:35:59 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Aug 2020 20:35:52 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= CC: 'Core WG mailing list' References: <013401d674ac$9e3504c0$da9f0e40$@augustcellars.com> <20200818065106.GA728308@hephaistos.amsuess.com> In-Reply-To: <20200818065106.GA728308@hephaistos.amsuess.com> Date: Tue, 18 Aug 2020 20:35:51 -0700 Message-ID: <01de01d675d9$d78eeeb0$86accc10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJguH2ha/bGHazvP+WART7aFcWd2gJMhrV2qBfaIGA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Message correlation with observe 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, 19 Aug 2020 03:36:02 -0000 -----Original Message----- From: Christian Ams=FCss =20 Sent: Monday, August 17, 2020 11:51 PM To: Jim Schaad Cc: 'Klaus Hartke' ; 'Carsten Bormann' ; 'Core WG mailing list' Subject: Re: [core] Message correlation with observe Hello Jim, CoRE, On Mon, Aug 17, 2020 at 08:39:36AM -0700, Jim Schaad wrote: > S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2 > S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1 In follow-up requests on the same token as Observe introduces them (and = I hope to generalize), an important theme is that responses that relate to = a particular follow-up message must be distinguishable as such where it matters. If just a plain refresh is sent, it doesn't matter whether a response relates to the old or new request (especially, it's not necessarily = newer than the second request). If the ETag set is changed (which is the only permissible alteration in 7641), it doesn't matter either (even though a new ETag clearly = indicates its generation after the second request). If an OSCORE inner refresh happens, there is clear indication that it's = a later one because it only decrypts with the newest request's Partial IV. And if the observation is cancelled, a response only fits that by not carrying the Observe option, as Jon pointed out. Programmatically (at least in my implementation), all those responses = wind up in the same channel (which I call PlumbingRequest, but maybe token channel or token subsocket would be more suitable), and it's up to the requesting mechanism (observation) to sort them. If S4 happened to = overtake S3 on the wire, S4 would already be recognized as a response to C2, "slamming the door" for everything that's not a response to C2 (just = like a higher observe value would make it disregard lower value responses). By = that time, any CON/ACK has already been handled as that's purely on the Message-ID layer. [JLS] I guess I have some re-writing to do around this. Is there = anything other than an Observe that is going to get this behavior? I currently = can't think of anything at this time, but perhaps some blockwise stuff might = end up here. My implementation currently creates a new silo for every = request and just shifts to the new silo for token matches, but that means that history at the top of the silo has been lost such as in this case. The approach works fine for the request-ack-response world, but they did not think hard enough about observe when then grafted it in. Jim Kind regards Christian -- I shouldn't have written all those tank programs. -- Kevin Flynn From nobody Tue Aug 18 21:46:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AB33A1181 for ; Tue, 18 Aug 2020 21:46:51 -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_H4=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 Hs6YjkXJTyUq for ; Tue, 18 Aug 2020 21:46:49 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1032C3A117E for ; Tue, 18 Aug 2020 21:46:48 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWZxf6J4NzySM; Wed, 19 Aug 2020 06:46:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <01db01d675d0$a309e3b0$e91dab10$@augustcellars.com> Date: Wed, 19 Aug 2020 06:46:46 +0200 Cc: Core WG mailing list X-Mao-Original-Outgoing-Id: 619505206.50858-c67a3239a5b04de4734f730e60cb0388 Content-Transfer-Encoding: quoted-printable Message-Id: <9962B184-4943-4CEC-B819-279D62525988@tzi.org> References: <01db01d675d0$a309e3b0$e91dab10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 19 Aug 2020 04:46:52 -0000 On 2020-08-19, at 04:29, Jim Schaad wrote: >=20 > = {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","vs":"7.1","ct":= "0"} > = {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0"= } Right, this would be what you easily get if you do a =E2=80=9Cna=C3=AFve=E2= =80=9D resolution of =E2=80=9Cbct" base fields. (However, Section 4 says that you only copy them to records with = =E2=80=9Cvd=E2=80=9D fields.) > Should the ct be ignored if the value is not "vd"? If it is present = but does not make sense what should happen? I think that it would be good to do the same thing with =E2=80=9Cna=C3=AFv= e=E2=80=9D resolution, i.e., ignore =E2=80=9Cct=E2=80=9D if there is no = =E2=80=9Cvd=E2=80=9D. But I don=E2=80=99t have a strong opinion. Section 3 says: When a SenML Record contains a Data Value field ("vd"), the Record MAY also include a Content-Format indication field.=20 In logic, it simply doesn=E2=80=99t say anything about records without = =E2=80=9Cvd=E2=80=9D. In English, it does seem to imply that the MAY does not apply to them. (But then it doesn=E2=80=99t say what is supposed to happen.) Now https://github.com/core-wg/senml-data-ct/issues/1 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 19 06:17:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6323A09B3 for ; Wed, 19 Aug 2020 06:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmgCo2Vsiucv for ; Wed, 19 Aug 2020 06:17:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAA33A09AD for ; Wed, 19 Aug 2020 06:17:30 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWpGq0V77z108r; Wed, 19 Aug 2020 15:17:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Aug 2020 15:17:22 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org" X-Mao-Original-Outgoing-Id: 619535842.609917-3866c305dfc83d83b3dd8cc6a9bde46e Content-Transfer-Encoding: quoted-printable Message-Id: <31BB7A98-FEA8-464C-A9FA-8E0F93B71808@tzi.org> References: To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 19 Aug 2020 13:17:34 -0000 Hi Thomas, Thank you for the light-speed review! > * Section 1, first sentence: > * One of "various" or "different" look redundant to me. They mean various different things to me :-), but one would be enough as = well. Fixed on github in https://github.com/core-wg/senml-data-ct > * Section 2, last sentence: > * I-D.bormann-core-media-content-type-format is not just very > helpful, it also contains the definition of Content-Coding > which is not found elsewhere AFAIK. Now https://github.com/core-wg/senml-data-ct/issues/2 > * Section 3, first para: > * you might want to reorganise the second sentence (starting with > "the Content-Format indication") to make it more readable. Split up.=20 > * Section 3, third para: > * "[...] appended to the Content Type _value_ (media type [...]" Nice! > * Section 3, last sentence: > * Might be restructured for readability; one suggestion: "If no "@" > sign is present outside any media type parameters, the consumer > can assume that no encoding transformation has been applied to = the > representation." Not sure we need to bring in the consumer, now says: If no "@" sign is present outside the media type parameters, the Content-Coding is not specified and the "identity" Content-Coding is used =E2=80=94 no encoding transformation is employed. > * Section 6: > * Maybe add a mention to the risks associated with compression > content codings (zip bomb, etc.)" Yes. So I tried to point to/steal from RFC 7230; this risk is not = discussed there. The last time I wrote a security considerations = paragraph about this was in RFC 7400, but this isn=E2=80=99t very = stealable either. I don=E2=80=99t think the risk is very specific to = data-ct, so referencing something is better than writing another = description, which is what I did for now. > * Section 7: > * Not sure but, would it be worth adding a note regarding the > formatting rules (i.e., an explicit pointer to Section 3)? The registry has no place for this information, and the reference should = include the other sections, so I don=E2=80=99t see a good way to add = this.=20 > * Section 8.1: > * Why is CBOR normative? Fixed. (CBOR stays indirectly normative via RFC 8428=E2=80=A6) > * Why is the SenML registry a normative reference? Because this specification registers =E2=80=9Cct=E2=80=9D in that = registry. (I think we can discuss whether that is normative, but I believe you = need to understand this registry to understand the registration. Previously, people just haven=E2=80=99t referenced a registry they = registered in, which I consider an omission.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 19 06:31:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013AF3A09F4 for ; Wed, 19 Aug 2020 06:31: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=jCUlP4vP; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=jCUlP4vP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aC1PvstC7t6 for ; Wed, 19 Aug 2020 06:31:54 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20070.outbound.protection.outlook.com [40.107.2.70]) (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 B50FA3A09F0 for ; Wed, 19 Aug 2020 06:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7IVtOdolgngOOAcNoR4Jp1MWo+G6Gs+aKlMRRp17vPc=; b=jCUlP4vPTpVq6S4UJD01y4W61ObAFUz5rscTifpyK5Jkk4MTi2O5hze+kvHkbobz2CJI2p4KgZo1GI/WWCEyG8VgSYw4eyigyJv1s2ajTAlOtRC4uvXP1YJMhLLfGEz0Uzl84O4541zUY04QqbkbYXToFPuE6Nh7H3nJBfeiGXQ= Received: from AM6PR0202CA0057.eurprd02.prod.outlook.com (2603:10a6:20b:3a::34) by AM0PR08MB4547.eurprd08.prod.outlook.com (2603:10a6:208:140::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Wed, 19 Aug 2020 13:31:50 +0000 Received: from VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:3a:cafe::af) by AM6PR0202CA0057.outlook.office365.com (2603:10a6:20b:3a::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Wed, 19 Aug 2020 13:31:50 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT058.mail.protection.outlook.com (10.152.19.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Wed, 19 Aug 2020 13:31:50 +0000 Received: ("Tessian outbound e8cdb8c6f386:v64"); Wed, 19 Aug 2020 13:31:49 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: aca3ce7a25915536 X-CR-MTA-TID: 64aa7808 Received: from dac27534ef3b.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 96089758-BBC9-4C6A-935F-0F8E0F83A5E4.1; Wed, 19 Aug 2020 13:31:43 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dac27534ef3b.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 19 Aug 2020 13:31:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JLbu9kI6SReTxvB/h3VW9l6WpE7IutbUBjJrNT0wnBIz/bMWqPoYOOxzDyAjD5+So6VldwATf6PfNG7njhq2emfqxc9HMT0bM7IQ4fuvZhfp/24XYkopu6Wm4Er2mJbh1GudPlTiFwU+8tnRhLnjkFfcuChO29f2kuDT2fPSX4xPjCdOfVXZ0QTAg+xrjN1yGrh/64/M9qgpwkdfVGgZYEn4JEyNPXfSTFcuYeIod83/Y+43aE+GeHN5fdU+W0++fKH7znigPw2fXxibuiEeBLUppgUaXC6C8CyNA2I9nl0tdGMDbZIXDdgVZfX1eNR7flMT901V5MolJbOuj98OGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7IVtOdolgngOOAcNoR4Jp1MWo+G6Gs+aKlMRRp17vPc=; b=NFN6PPM5XWk2Dmp0tnYBnaCjSEpGCYpMC0/HcV/P/+X7RkwDv02Q1Hjdm6HY3f+VTJqlOV9scW3hKtOI8gSVzzVZpmtLMDrv0XhpkP+Bzs8rcLfqtBBBoa7XINlxbo2el6tNHnYmjcpoR17Lvao8Vut/c2d9riV6oBFieQcJDwNLXSg3l2a8QDnBThS4ZQbsAfY225hzR4zqnmHIFabGwbmao0md5zcmlTULN5pwcUit5o1j+JVm0Qwqi1VntSTYKAswN/xnGxUK+7Ig83zW+90KxXnCDrAwbPp9+gDKYW3G0ckyFlkSMCCWjto6AvTetDtqr79AbrPpA8lfQaMViA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7IVtOdolgngOOAcNoR4Jp1MWo+G6Gs+aKlMRRp17vPc=; b=jCUlP4vPTpVq6S4UJD01y4W61ObAFUz5rscTifpyK5Jkk4MTi2O5hze+kvHkbobz2CJI2p4KgZo1GI/WWCEyG8VgSYw4eyigyJv1s2ajTAlOtRC4uvXP1YJMhLLfGEz0Uzl84O4541zUY04QqbkbYXToFPuE6Nh7H3nJBfeiGXQ= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM5PR0801MB1746.eurprd08.prod.outlook.com (2603:10a6:203:3b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Wed, 19 Aug 2020 13:31:39 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::459b:bcf3:b888:c906]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::459b:bcf3:b888:c906%6]) with mapi id 15.20.3305.025; Wed, 19 Aug 2020 13:31:39 +0000 From: Thomas Fossati To: Carsten Bormann CC: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" , Thomas Fossati Thread-Topic: [core] WGLC on draft-ietf-core-senml-data-ct-02 Thread-Index: AQHWZdAsCa4rxFgqy0uqoB2vd/JsSqk+cLaAgAEZzgCAABTBgA== Date: Wed, 19 Aug 2020 13:31:39 +0000 Message-ID: References: <31BB7A98-FEA8-464C-A9FA-8E0F93B71808@tzi.org> In-Reply-To: <31BB7A98-FEA8-464C-A9FA-8E0F93B71808@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.40.20081000 Authentication-Results-Original: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5e16a6c1-97b9-4248-f73f-08d844443a96 x-ms-traffictypediagnostic: AM5PR0801MB1746:|AM0PR08MB4547: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: E1TFuwD93NZD6jve6sOP1b/O/c3cEkycR89D5dCudOSFdpQNhxDpHQHYsWWJge6iBIgRJEI/aVc0gwmyh4g5OpAobgqHqJ8X8Cz9DYvP2sK00IS+T1rcdZUQXmXr4+DLH15Wou2IvmvT7D85eb76294IkE3bEsYrbw5U6EJjnGpzDEt3vgas9TRLkKpG30vzCChpkdtG3s64BAfSf8OumlaCYnR3SKF7tjcq7/SWJ6TeM8SvHGGULU7f6bG3Dmj5Ay55EryJR7gZT5lqRxL+n0dZ8w2UY9VGi2XZYPoTTreQewdQFDqe3GCcgPd+T6/RhSrSBOhqsGzVOOrAN+IMyy1FYwuLCmA30IXh04vyOtrogQE/7PIwczEp7GvehfRWxyAScD0dcAQjfPMsM7jb9Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(39860400002)(396003)(136003)(346002)(91956017)(54906003)(8936002)(6486002)(53546011)(478600001)(6506007)(5660300002)(316002)(6512007)(33656002)(36756003)(83380400001)(86362001)(71200400001)(6916009)(26005)(66476007)(66446008)(64756008)(66946007)(76116006)(2616005)(8676002)(186003)(2906002)(966005)(4326008)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1hBskNGdp/sVM3uSwV9i6qByTf9HvjjN9Tui1+9dy07I2LXiBjnjOaZpDVR5txtHdQDtuvPwWhSnYJTSfB113vBUhBM0k5QAcjMcQ2WuNkhLrge3Z5DYm/HBCDh8nEO48H2m0HIMbl42Xn0yis8MJaLFxLbW7vLo00Tq8xHx70Di2J2v+tX4msXQdwtDaLw/ai+SjIFGH3GU53UM+NZALG7syCl3HIqj7GHKfOgGtVDWIvkY2eJxTVjsCLiq09bzomj+BrXucF77NeB0NLrv2Ml6eHb5uY28zJZ52xmOMgIp4O61DTJbmrPxdJSvjYcDF/TIX8T7Wa8BKZxIpcfTN9qnCMIGhqCB9u3d9RswH6BeqW1ZN7enlIhOL/StQ/Z+dHHPSHviWqcHqtkChGNHp8W/ALjgxc/DrDnm3//M9dgizB3sQaBk6awps/IOnrTh9SDyh6f+YNItScRjfbpyUIP3osF/P3ciGWQV2aZ+vXI35EzH2LPhus5OIlm/HrJeGPM37gkROl39iTjCNOUDa7O18hp9VAQQmmnX/cCOWeWmGWZVOERbmcbT9wzcioGg4qy/Hp2bENfraXlyqLwckEMkDxkdK8aPwBdsjSvzyMUAh8AsZqkoQ5dJrUkqRbRoG8MPVCfx82ME7IV1nmtPNA== Content-Type: text/plain; charset="utf-8" Content-ID: <10BBCF271CA5414387F314AA75F542EA@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1746 Original-Authentication-Results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: eb239079-feb4-4eae-aa88-08d844443448 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LHBVGMJ3j0AE0xE0IFBVbhsv+mkygXv7udLw9vBULpEQeF2E3ju3m2srEHqZRJ5R7Wbtzv9J0/kz/EVe/N75df0NV+eO6yAATbBsqSFU8ikAGeti1Y+1e6Ga9QYNyIl5KPmlo8Z0XFQOgRL7F9A8gOwJ1TEQMMIyGQ4ra7hdzG990BNKHig5qkebuJIh7sgxVMKsbalVlVsNhyryDSXoS34FdQMlBRr3/2NdwoEa4S8in3ntfrffxTqKPDvjeDFAlpGDrNji59vm7CZ0tlc0M2TiSmLvdPMprg/6TXVUF5PBiSc8KYcorUuQxnYlxuDaaPiPinkQhGIsdE+XbvyDQ/fV9iczQz7NruDEXNXxAs/Ofaqa8PdiZ9120vxVqUCWYeq1G5RD4m6rTaDNmTtBQppLJwCTk6ua7wYNFksxtZygKBzsc4Ed6pJJaDnGLp7ahRFdBU7L4lel/XVEYSZa3RJDnEY+RIhecK70q9LbozE= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(46966005)(54906003)(86362001)(4326008)(6486002)(81166007)(70586007)(82740400003)(53546011)(356005)(6506007)(70206006)(82310400002)(36756003)(316002)(26005)(8936002)(36906005)(33656002)(478600001)(6862004)(2616005)(83380400001)(8676002)(2906002)(966005)(5660300002)(47076004)(336012)(6512007)(186003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2020 13:31:50.3252 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5e16a6c1-97b9-4248-f73f-08d844443a96 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4547 Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-senml-data-ct-02 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, 19 Aug 2020 13:31:56 -0000 WW91ciBjaGFuZ2VzIGxvb2sgZ3JlYXQuICBKdXN0IGEgY291cGxlIG9mIGNvbW1lbnRzOg0KDQpP biAxOS8wOC8yMDIwLCAxNDoxNywgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3Jv dGU6DQo+ID4gKiBTZWN0aW9uIDc6DQo+ID4gICAgKiBOb3Qgc3VyZSBidXQsIHdvdWxkIGl0IGJl IHdvcnRoIGFkZGluZyBhIG5vdGUgcmVnYXJkaW5nIHRoZQ0KPiA+ICAgICAgZm9ybWF0dGluZyBy dWxlcyAoaS5lLiwgYW4gZXhwbGljaXQgcG9pbnRlciB0byBTZWN0aW9uIDMpPw0KPg0KPiBUaGUg cmVnaXN0cnkgaGFzIG5vIHBsYWNlIGZvciB0aGlzIGluZm9ybWF0aW9uLCBhbmQgdGhlIHJlZmVy ZW5jZQ0KPiBzaG91bGQgaW5jbHVkZSB0aGUgb3RoZXIgc2VjdGlvbnMsIHNvIEkgZG9u4oCZdCBz ZWUgYSBnb29kIHdheSB0byBhZGQNCj4gdGhpcy4NCg0KSSBub3RpY2VkIGEgIk5vdGVzIiBjb2x1 bW4gaW4gdGhlIHJlZ2lzdHJ5IFsxXSwgdGhhdCdzIHdoeSBJIHN1Z2dlc3RlZA0KdXNpbmcgaXQg dG8gb2ZmZXIgYSBtb3JlIGdyYW51bGFyIHBvaW50ZXIgaW50byB0aGUgc3BlYy4gIEJ1dCBzaW5j ZSB0aGUNCmRvY3VtZW50IGlzIHZlcnkgY29tcGFjdCwgdGhlIFJGQyByZWZlcmVuY2Ugd29ya3Mg YXMgd2VsbC4NCg0KWzFdIGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Nlbm1sL3Nl bm1sLnhodG1sI3Nlbm1sLWxhYmVscw0KDQo+ID4gICAgKiBXaHkgaXMgdGhlIFNlbk1MIHJlZ2lz dHJ5IGEgbm9ybWF0aXZlIHJlZmVyZW5jZT8NCj4NCj4gQmVjYXVzZSB0aGlzIHNwZWNpZmljYXRp b24gcmVnaXN0ZXJzIOKAnGN04oCdIGluIHRoYXQgcmVnaXN0cnkuICAoSSB0aGluaw0KPiB3ZSBj YW4gZGlzY3VzcyB3aGV0aGVyIHRoYXQgaXMgbm9ybWF0aXZlLCBidXQgSSBiZWxpZXZlIHlvdSBu ZWVkIHRvDQo+IHVuZGVyc3RhbmQgdGhpcyByZWdpc3RyeSB0byB1bmRlcnN0YW5kIHRoZSByZWdp c3RyYXRpb24uICBQcmV2aW91c2x5LA0KPiBwZW9wbGUganVzdCBoYXZlbuKAmXQgcmVmZXJlbmNl ZCBhIHJlZ2lzdHJ5IHRoZXkgcmVnaXN0ZXJlZCBpbiwgd2hpY2ggSQ0KPiBjb25zaWRlciBhbiBv bWlzc2lvbi4pDQoNCkZhaXIgZW5vdWdoIDotKQ0KDQpDaGVlcnMhDQoNCg0KDQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Fri Aug 21 06:19:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC14A3A0821 for ; Fri, 21 Aug 2020 06:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.949, 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 QMJyPF3evWZw for ; Fri, 21 Aug 2020 06:19:49 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2048.outbound.protection.outlook.com [40.107.20.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 DD1923A081D for ; Fri, 21 Aug 2020 06:19:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RM9psKZJnn5rd67AIXSpvxRam+zYTK+SmYm4Y+QXOScvHQ9Xqhx1x8o+x0F77aP/EnZ3Ii4XTwBqSFNos9hzfLpx+2cSAqu1KO+kzRagnZ+cGlQp9fLWjPX3DoUn/yQVY9+RrlvtztXIfrSaIvckXbBiOEv2GtXODUROuoxnxt1RpW06Mu3zR3HOM/N3MXCFd7RVOfI+o2TwXC1OhbAtSrp9ZiBZNMeGEwMjufuEu9PExg2OKJnXGHu3QbIAPczI6ADFoHyRFEEV8cQSB25Sa/ZuCeJRi/uH2bedW6fFXpRrzm2NSvMoM86YPpBgPcCZGvAstU7rY2e0bHKRZ9Xf9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kVQrQaJScN1tD3IZ9A9+qJOEACr3RKC8w/kVPUPEg8o=; b=MVkcGtk+9Hx/wM7FybsokW8lJYQcCRQaZia5MoURzuYBFbZCW2tfh714W52LUJsXpSPTX6FmsjSALXXkW1OuJ5uWngX4P1pZ1NsqGMEDpDtKw3X65boYpPLTTc7ZbWB3Kifav7XKinjJhk/68w0r4Xllzux49SXmHBvb/H5qj7SbgxZXKQveX+Kz5+hbE7fok131BL32GJh5X/DQi5v8o0uBbJK4gOwkrgNWQgKEXsmOFZ8cj6vEYsM2UAnlfzR5J+z3zXJiP1PyYSwXTi9PQrhLfs+wtLlOFcfogqfOeGvhbe5DemYoo74fJF+P4lT91JuPyTBfg7sU8gaQKKtYpQ== 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=kVQrQaJScN1tD3IZ9A9+qJOEACr3RKC8w/kVPUPEg8o=; b=GtCOxApLmzEbJPA53+e148eygt15KCHH48AEpML5Nn7g608vz4MPx4SyxtSF0wP3Z7p9feX60hYN/rpod+15rgQ0BOIcpHMuFQHwmKAjvxHi8RrI7r2F/EKpsuK1BloX7RGRZLkTOlqVX/y6OIThdDo2qh5MDEy48BZROzUDbTM= 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 DB6P18901MB0165.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:25::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Fri, 21 Aug 2020 13:19:45 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%8]) with mapi id 15.20.3305.025; Fri, 21 Aug 2020 13:19:45 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <8d785827-99ba-ca7d-cd1e-bc4f03c71def@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <5a53638c-14c3-252f-1cf1-592c61698546@ri.se> Date: Fri, 21 Aug 2020 15:19:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <8d785827-99ba-ca7d-cd1e-bc4f03c71def@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SmFuslwAurRFzpslsZKnjSM0EJ088lLu2" X-ClientProxiedBy: HE1PR0501CA0017.eurprd05.prod.outlook.com (2603:10a6:3:1a::27) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.10] (185.236.42.107) by HE1PR0501CA0017.eurprd05.prod.outlook.com (2603:10a6:3:1a::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Fri, 21 Aug 2020 13:19:44 +0000 X-Originating-IP: [185.236.42.107] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0eb4dc52-c2e1-42dc-deed-08d845d4def8 X-MS-TrafficTypeDiagnostic: DB6P18901MB0165: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: da/89tBsJmBnGXJarG11k2ErTJSN/wam7oQlNGkBp+YGabshJ6sJNPtawR92UXms+3bLO+Vz5Ai4VFjeHG/D47OWYmNF3OOEtEmovqzqt4VPpRWK2IKssi5g3AW406GQoIUyCIYLLQH/Rc2IA9L+3NQqDBXJAZJ+HKyXmb2rRXmxP3uvgVx/jYNdswXsh4F/t3wF81Ie3cBqupE2rE5/3y9nkKjxACh7M2HPQAJcJRJtTajLWlaKjJnxUMo8S1mxM2YT1YMktk3hibbKiWXtQTUUUkKUeXO6xj2+f5i4vKffOYPEwMET4Jifz/NoDUsbCYO15rPMMzpcoq0qAjiwumY3mNSegov6KJtzwxqo4d4n0Kh72HLFvoWX8PnKgv4ac29qJvaOyzQ49cS4TbWlegBtp1xuXdg1bntbPK5f9iweJQMk+MIvkaBYRjUXRPIu/HD7nNhNGZPYewOKRvvmwg== 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)(136003)(39860400002)(346002)(396003)(376002)(31696002)(16576012)(966005)(33964004)(2906002)(5660300002)(52116002)(235185007)(478600001)(316002)(31686004)(16526019)(26005)(8936002)(83380400001)(8676002)(21480400003)(86362001)(6486002)(53546011)(66946007)(66556008)(66574015)(6666004)(66476007)(956004)(36756003)(6916009)(186003)(44832011)(2616005)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: j6qabpHdKesiGOyEWm/2PzVhdOVBkdmNfoVywRNFgd7pDbzdKiOcpVs5EJe18uzu+Fk7BtJXJvhv4U3IiDzB898AxARrZUScjextfk6qOeGz9uAeP7NiKHS6vRyJ0sgFaSIURDw46FdYWr13HsMSyXhDzQRy7x3/a9wPfd11lN/xHFUGVeOA1UOR1ksGWlvW9v30Oa/GmDcf2mhaS2velefN6ZUPm7GpSnb6aJbs2dEYIWcEN0MdJgz+bt1P8wFOz79oKV5wrcUOWqAxkefDI4xpIZYgcm1UWnVPZNOkMVExeXRD9JnHx/PB1DTBKSBpv+u4gR4SwVQnEJnBjsNw17uaIG+WUAgXANgu15a5M5MMYN1YZgbkX7dbbtBSN8Io5FW0cbQsk2OvidqklFUOnn1LJcPrl4kj5JkH8dwwft1oFoHbmm1IOkYTlLLQH2uY1zbhtdWwfrd7XgmuyAgrTHtHSuTcZtoxU/4zajrogubB92g361WVTy7IMTR4cuN3n5hxMWC8A7L1CtPfuTSF2QOVlaPgqvzvJcbmi7FKglEQ2SATC1RK0R4TbTfg12JDkpTF2jxOKy62dg9PR6B8pK9MtqnzdeXToCVsxmvxS8e2hLuq71hMCvusznkU5f8h9FS78bDZCJLUu6yFK2yfjg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 0eb4dc52-c2e1-42dc-deed-08d845d4def8 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2020 13:19:45.2684 (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: Yq2yhK7ey6qWi8JGOdcDb+ahufXPgKU1FR0I62em+4Tgwr33AWWPNMuIXivzSFE6Ezm6nPK55ehDLVKjQhDE4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0165 Archived-At: Subject: Re: [core] CoRE interim meetings 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, 21 Aug 2020 13:19:52 -0000 --SmFuslwAurRFzpslsZKnjSM0EJ088lLu2 Content-Type: multipart/mixed; boundary="s6c1ahLz97SiwpHwhQ6x47IyeZnm7eVRf" --s6c1ahLz97SiwpHwhQ6x47IyeZnm7eVRf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, Based on the Doodle poll, we are going to have our virtual interim meetings at 14:00 - 15:30 UTC every other Thursday, starting from the 10th of September. Best, Marco and Jaime On 2020-08-18 14:56, Marco Tiloca wrote: > Dear all, > > Just a kind reminder, please fill the Doodle poll below by Thursday, th= e > 20th of August, EOB. > > https://doodle.com/poll/cb9qshfymw6tdgna > > Thanks to those who have done it already! > > Best, > Marco and Jaime > > > On 2020-08-04 19:07, Marco Tiloca wrote: >> Dear all, >> >> We are planning to schedule regular virtual interim meetings, recurrin= g >> every other week, starting from the second week of September and until= >> the end of October. >> >> Please, cast your preferences at the Doodle poll below, by the 20th of= >> August EOB. >> >> https://doodle.com/poll/cb9qshfymw6tdgna >> >> The options in the Doodle refer to the week of the first interim >> meeting. The following meetings will occur every other week on the sam= e >> weekday and time, until the end of October. >> >> Best, >> Marco and Jaime >> --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --s6c1ahLz97SiwpHwhQ6x47IyeZnm7eVRf-- --SmFuslwAurRFzpslsZKnjSM0EJ088lLu2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8/ye8ACgkQ7iZktA5Y 2kPMRAf+N42QEa4vyX/PTzhhZdfhoQ/YR5T4GULHnCw1nH/p/I2+daOoTf1Bpu51 aHkNtJ8IW+oANpOup23+wlv9KfpxrykiW65nhiC7jkimNFU5GSCRsutRg7ygo34y 5FBtt9QOnAJJRyrgNfyETik5jhDMlUgeQdKbUhfFNZl2k+5r87/qfzibmUkcQvUG NZOngEtPO/iFI+SEkkF1f8/lO4rmUtHQz6xxiVxLj9XDhGTZzcmDO8bACzDvkMuB oKMRg6YX7akfp4OvdxEvuzuVmqKY2ggpZCcltPXcC2FsCXn3RIsxQh0FDWlWIAjM pIBZOM0txGrt8Sxucu33d0yzRTrzGg== =lAWD -----END PGP SIGNATURE----- --SmFuslwAurRFzpslsZKnjSM0EJ088lLu2-- From nobody Fri Aug 21 07:20:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484CA3A08A5 for ; Fri, 21 Aug 2020 07:20:46 -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_H4=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 0xJgnOg8sN-u for ; Fri, 21 Aug 2020 07:20:43 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69E93A02BD for ; Fri, 21 Aug 2020 07:20:42 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BY3Zx2vpNzyXh; Fri, 21 Aug 2020 16:20:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <5a53638c-14c3-252f-1cf1-592c61698546@ri.se> Date: Fri, 21 Aug 2020 16:20:40 +0200 Cc: "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 619712440.494269-e016b3e63c3fe52bd32ba1d1593a31a5 Content-Transfer-Encoding: quoted-printable Message-Id: <3B38FF4B-15BA-470F-AC43-D482997CA32D@tzi.org> References: <8d785827-99ba-ca7d-cd1e-bc4f03c71def@ri.se> <5a53638c-14c3-252f-1cf1-592c61698546@ri.se> To: Marco Tiloca X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] CoRE interim meetings 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, 21 Aug 2020 14:20:46 -0000 On 2020-08-21, at 15:19, Marco Tiloca wrote: >=20 > Signed PGP part > Hi all, >=20 > Based on the Doodle poll, we are going to have our virtual interim > meetings at 14:00 - 15:30 UTC every other Thursday, starting from the > 10th of September. Note that this means the meeting on 2020-11-05 will be at different time = in Europe than the ones before that. (Not a problem, but worth = mentioning.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 21 08:20:40 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A747D3A0A4F for ; Fri, 21 Aug 2020 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.949, 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 SZnwGoc0iG50 for ; Fri, 21 Aug 2020 08:20:35 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10087.outbound.protection.outlook.com [40.107.1.87]) (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 911D73A0A4D for ; Fri, 21 Aug 2020 08:20:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H4hyJpPEKa6ePQ5zzx+18VT7eA5TKumw38ZUHWhMJgW9+VlVJzyT9jKR9iDoIrgnjKWOd02kmQVK2UqEVwCqfbEBBqn6nS7q+kyLV+ZTa2GQqFQUQH9bnIzA8QRkF7zTG9VdAUyBJV05mIjkLTimKN4V1Y5ZI+vncUd07uppSmz0XG47/bYbAbG8EEUIy5xMYOZINlr8KJvDNYbe8FFltSYgJJCrGlcRfwODFfOvdV/39V7vVwMYrMEpFTQ8u+8Im77nmVW+cGo7pTD0eY2xucqKiZPvf5zTaNH2Xo6MLYHjf3Id/rAPEZuGtTO0QsaCSqbHVLqdKPYOdP//HqdtzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=issHa2njC4Z9iR7FqPu6WEtd8qRtzIH2lxXazl4Fi3o=; b=kTwUjxaHWaiQUo7GfunPw3SMtZX4kfxBoJeKtmWmIAOTz7sml6BqfFOQ3QwF6CtVJOGXd6JHGxO+F5HL0+8v9HZdEQnjQKWGaNL6tQZyD0/a5xwQauxpMoodqbs+zdtCajgif5ylHMDEGgoJCeM3oto6FN39m0sFDrHyay7wOWWIavbpZKL5eFyNt0fUXd+3F5FaM6wa1DNqqeKYkYyP+FDFtWwEI5NV4as62CcTDPNuUdDqDD5HbpssvC/5k5DLIZM6ntaT1PUtmiKH/ra8uE8HmHvupKiiZoY6qUL+SFqAbkVrmA3OoC5s5iYUy89zTackM7Cu9sNagBA/cEIb1Q== 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=issHa2njC4Z9iR7FqPu6WEtd8qRtzIH2lxXazl4Fi3o=; b=f02+3FpcBsJHu3LP0p5d96e4R1luYZ/T51DMTlpWVmEBsxvn6vut6vUhiYS7tmEhMjcrK1mzTr3QMrkC6d12/9X3dv5inAsW+QPP1QUbLMmJFFo28OdWxej8SzqzzV95oDwke/PHyDWqCe5vDh/FpHFVQgLAhp5/NNSj5eo33SQ= 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 DB6P189MB0551.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Fri, 21 Aug 2020 15:20:27 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%8]) with mapi id 15.20.3305.025; Fri, 21 Aug 2020 15:20:27 +0000 To: Carsten Bormann Cc: "core@ietf.org WG (core@ietf.org)" References: <8d785827-99ba-ca7d-cd1e-bc4f03c71def@ri.se> <5a53638c-14c3-252f-1cf1-592c61698546@ri.se> <3B38FF4B-15BA-470F-AC43-D482997CA32D@tzi.org> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <26c88cb2-c548-34fb-10f1-588ac95c291c@ri.se> Date: Fri, 21 Aug 2020 17:20:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <3B38FF4B-15BA-470F-AC43-D482997CA32D@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Wir5FdvqgA90eheLPbbE8789OjJyw82rN" X-ClientProxiedBy: HE1P195CA0015.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::25) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.10] (185.236.42.107) by HE1P195CA0015.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Fri, 21 Aug 2020 15:20:26 +0000 X-Originating-IP: [185.236.42.107] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 178b75f6-8a7d-4d32-02a3-08d845e5bb72 X-MS-TrafficTypeDiagnostic: DB6P189MB0551: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4pVfNxSRy73493ZCIFIQP5iKWNaIKAQPK1v4E3DI4nUGHXN1VmL4PM/+WxivBBOezA/vRzne65ws96nVFgvhcTs566obi1FD8MnK7VuKDkDYXMP1PB4918uKqEkUfyV1iEkGivaS5sLYLRzvPO5X0jxoiF8qoMuZ/DUTCnrlhmm199suBnCXn5Ho3SWWI14OKvo84uA+PysBtMkB8gdHE1Kyv1POugqLaVFzJQYQ6vfACkgnswf/69xr9H1l8v6vWoCfGgx/WRx8qoJizBxW08ugLIqCSXVHYIITlpxJQYpgLCiI688KiKW7LJ9W/0mgatUoNnOba7cnHqwAS7ivFpq4R7ftOtEup0PPH330N1LymoTa9HjzclJdZlJJ1y7ZkRyjRfriyx4we5Z3ZuV+XmOvVYjU9vu9dwAiDgJmyPDbIv71dj1OrfRTCvY7uRbSvvi6rnPXzMxv5ohxvQHMhA== 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)(39860400002)(366004)(136003)(376002)(396003)(2616005)(66476007)(33964004)(235185007)(66556008)(26005)(86362001)(16526019)(186003)(956004)(53546011)(8936002)(31696002)(6916009)(5660300002)(31686004)(21480400003)(44832011)(66946007)(966005)(6486002)(2906002)(52116002)(8676002)(36756003)(4326008)(6666004)(316002)(16576012)(478600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: wNLTgf0DNVIkVvgyjJgWrDT6U/L23KGkOVaDyCkmTHvspqCxILP7GRAcAPb14UUx4rRiGpwCd5dSKLZbHklFp1HjGvSAuEGDIgXSFOPMGhTjfUR95Uw5fv1NJEYDS/Sz7ItFUvEZ/QWama86GxtJ11ibbV0V5A0VQCMsd/sGvz/ZffqqxIVkzwv3a+M5KzURR8VE6nK5Jr9GbJkp1Wr2d2oBTe7IuIAxCcwf6bkUoC+LivJbhkV6jNVtitt6SASvyy0UbPOp980+Au8Qox6P0KfVRlYIPB8J8GlU4eKuZMSKuZjuFdalrnep+kSGA7tNRHS3LyqAy+2RVQf2G6ufUqqFKrU/pVrvjT5HchL2UGbcS1ciUMRvG6RpkFLe33ZFD9lErgmoanW6rXxc//3EdeQVlp6Yrq4U4+n75ZxS0HTgAa8yRK/jUg6t3YK/iXLQWWZzd/Q/w38SVn3gVLMbwuwX5E3ptssoDIjA9qcDzF6KvRnQG+L3iD0wV88IcQagUp0FT5nwij6DqYvQnmOUCNIR1vMcRNi86K5wjRvNOFojamujt0FY3H1h9Xc3ZJvuWXNZSNWc0FlpYXnbPsACwHfSFBur8Tg7d/4SBvzmzxkvKccDw6NndWzPEC0r9wcf6y+1BEojUQPJ7tGF9VsdBg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 178b75f6-8a7d-4d32-02a3-08d845e5bb72 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2020 15:20:26.9286 (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: xZtFkjM2z/MThsKDIAlQibPluCMThokEuyXpmMsNk2W1PkzE41kXYi5954D4L3x5D1r1eNqlYPMtKuRugpHCwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0551 Archived-At: Subject: Re: [core] CoRE interim meetings 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, 21 Aug 2020 15:20:39 -0000 --Wir5FdvqgA90eheLPbbE8789OjJyw82rN Content-Type: multipart/mixed; boundary="Pat78Uh9GfO0pHIFMpotEJNJCkosAWcml" --Pat78Uh9GfO0pHIFMpotEJNJCkosAWcml Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Carsten, On 2020-08-21 16:20, Carsten Bormann wrote: > On 2020-08-21, at 15:19, Marco Tiloca wrote: >> Signed PGP part >> Hi all, >> >> Based on the Doodle poll, we are going to have our virtual interim >> meetings at 14:00 - 15:30 UTC every other Thursday, starting from the >> 10th of September. > Note that this means the meeting on 2020-11-05 will be at different tim= e in Europe than the ones before that. (Not a problem, but worth mention= ing.) =3D=3D>MT Thanks for pointing it out. To keep times homogeneous, the 2020-11-05 meeting will actually be from 15:00 UTC to 16:30 UTC. Best, /Marco <=3D=3D > Gr=C3=BC=C3=9Fe, Carsten > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --Pat78Uh9GfO0pHIFMpotEJNJCkosAWcml-- --Wir5FdvqgA90eheLPbbE8789OjJyw82rN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8/5ioACgkQ7iZktA5Y 2kMVDAf+LmuKK/8CNp+lSnRT1AsZ777oSwY69qR+lXRZBeldnTOiuv8on36B9ZaJ XpdtTbOO6M2S6sLXWEcG6CRZFsxMhqdnpCAechLoQerq1Hqh7A4TWqSzgUKMxHjp O/tbgNT2Xt/pZKMzKd/WdbDzKcPR5HbGy+W5GbT3vg9WMBgOoRty519k/e4hzDD4 GOsbt++ceOgeWhpBwCKX27HBjTfEyWUBhl/EITRH0r0D4o3X8G1DfIv/EIe9JXot amzo7v0lv+C2ErDPmiQPLdEZR4ojBzZGi1hR2ycZX0Tf494OhtWB6EODYdUHFwuG n+VIHe/P6+PRg8UbtQfFSGFSQ8JPtQ== =emH0 -----END PGP SIGNATURE----- --Wir5FdvqgA90eheLPbbE8789OjJyw82rN-- From nobody Fri Aug 21 08:33:59 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A8D3A0A5E for ; Fri, 21 Aug 2020 08:33:57 -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_H4=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 qDKJaViWm3Gm for ; Fri, 21 Aug 2020 08:33:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17BC3A0A22 for ; Fri, 21 Aug 2020 08:33:54 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BY5CM00mvzyZ6; Fri, 21 Aug 2020 17:33:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <26c88cb2-c548-34fb-10f1-588ac95c291c@ri.se> Date: Fri, 21 Aug 2020 17:33:50 +0200 Cc: "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 619716830.19174-1a64916b14e43129c1d8fb70523fbdb4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8d785827-99ba-ca7d-cd1e-bc4f03c71def@ri.se> <5a53638c-14c3-252f-1cf1-592c61698546@ri.se> <3B38FF4B-15BA-470F-AC43-D482997CA32D@tzi.org> <26c88cb2-c548-34fb-10f1-588ac95c291c@ri.se> To: Marco Tiloca X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] CoRE interim meetings 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, 21 Aug 2020 15:33:57 -0000 On 2020-08-21, at 17:20, Marco Tiloca wrote: >=20 > To keep times homogeneous, the 2020-11-05 meeting will actually be = from > 15:00 UTC to 16:30 UTC. Nice. The fall week of confusion (Europe has Winter time, US still has = DST) is W44, 2020-10-25 to 2020-11-01 this year =E2=80=94 no CoRE = meeting falls in this week. =20 (But it is still moving an hour later in Shanghai or Bangkok.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 21 11:45:57 2020 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 8C79D3A1047; Fri, 21 Aug 2020 11:45:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159803555435.22725.9973384812930028770@ietfa.amsl.com> Date: Fri, 21 Aug 2020 11:45:54 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2020-09-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 18:45:55 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2020-09-10 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mb93d5310059df95f1f25734c1b973f5d From nobody Fri Aug 21 11:46:27 2020 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 0CCEF3A1086; Fri, 21 Aug 2020 11:46:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159803557115.13642.2865449326632669719@ietfa.amsl.com> Date: Fri, 21 Aug 2020 11:46:16 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2020-09-24 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 18:46:22 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2020-09-24 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m77b4ee5ef9869f87a24a3aa57f2c30f5 From nobody Fri Aug 21 12:42:37 2020 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 5A1543A10D1; Fri, 21 Aug 2020 12:42:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159803895113.25811.10359263277944682078@ietfa.amsl.com> Date: Fri, 21 Aug 2020 12:42:31 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2020-10-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 19:42:32 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2020-10-08 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mb3ef6f63cca8d4c20803296e5f07702f From nobody Fri Aug 21 12:42:57 2020 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 69B2D3A11AA; Fri, 21 Aug 2020 12:42:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159803896539.22725.11056821635654874991@ietfa.amsl.com> Date: Fri, 21 Aug 2020 12:42:45 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2020-10-22 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 19:42:52 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2020-10-22 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m500e0dee578ce618c4ffcf26ca3aedd9 From nobody Fri Aug 21 12:43:08 2020 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 767893A124C; Fri, 21 Aug 2020 12:43:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159803898144.18484.12289346019896061394@ietfa.amsl.com> Date: Fri, 21 Aug 2020 12:43:01 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2020-11-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 19:43:07 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2020-11-05 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m42a6113960b3434a699fc514e176a5a5 From nobody Sun Aug 23 22:21:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750C43A0A34 for ; Sun, 23 Aug 2020 22:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=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 NQkuQkcit8aI for ; Sun, 23 Aug 2020 22:21:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F343A0A2D for ; Sun, 23 Aug 2020 22:21:28 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BZgTL6t3zzyXj; Mon, 24 Aug 2020 07:21:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann Date: Mon, 24 Aug 2020 07:21:26 +0200 X-Mao-Original-Outgoing-Id: 619939286.462364-4e659618c1979a9e419290846e3eb422 Content-Transfer-Encoding: quoted-printable Message-Id: <9105A6A0-4C53-4FA1-8E3B-C404417313C0@tzi.org> References: To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [core] Fwd: [OPSAWG] some comments and thoughts on mud-sbom and sbom-type 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, 24 Aug 2020 05:21:32 -0000 I fished the below out of conversation in opsawg. The objective is to say =E2=80=9Chere, but with coaps:// scheme=E2=80=9D. We can say =E2=80=9Cwith the current scheme, but elsewhere=E2=80=9D as //elsewhere.example/.well-known/sbom But we can=E2=80=99t say coaps:///.well-known/sbom out of a resource accessed with coap:// Food for thought. (I know, use CoRAL :-) Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Eliot Lear > Subject: Re: [OPSAWG] some comments and thoughts on mud-sbom and = sbom-type > Date: 2020-08-18 at 15:18:42 CEST > To: Michael Richardson > Cc: opsawg , Brendan Moran , = Henk Birkholz > Archived-At: = = > Message-Id: >=20 >> 1) It seems that just putting coaps:///.well-known/sbom in the URI = might work as well. >> If necessary, then maybe: coaps://127.0.0.1/.well-known/sbom or = https://[::1]/.well-known/sbom >> CoAP does have a Content-Type for returned content, but it is true = that >> there isn't as much negotiation by default in the form of Accept: >=20 > I don=E2=80=99t think /// is a real construct. There are two issues. = We don=E2=80=99t know the hostname and we don=E2=80=99t know the scheme. = But the MUD manager does know the hostname, and we need to be provided = the scheme. There is no convention for ME without a pre-existing = context. That might be something to work on, but it would hav to happen = in coordination with the COAP and HTTP working groups, and I don=E2=80=99t= know how big a job it would be. Thus what=E2=80=99s there. From nobody Wed Aug 26 18:11:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B33A0C32 for ; Wed, 26 Aug 2020 18:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=taitradio.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 ZFYc8MvnTij4 for ; Wed, 26 Aug 2020 18:11:22 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 D26833A0C23 for ; Wed, 26 Aug 2020 18:11:21 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id a21so5429207ejp.0 for ; Wed, 26 Aug 2020 18:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taitradio.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=opVTWemTTcV1Ta57xQ8oc3NLpfcL+nyO2/H1GvmJjes=; b=C4ZDrIgVOGJKuQvv0Xxqs9OBwSzPXC3USh+LbJL8zQw0P2cPeBdLCTKRcxIqrDs4MZ C0vzmcvPjcQRJ2jHCp1DpLpUdqAFheE6azr05CHxSbYejIqZefd2wWWX7e03e/UoPQI4 2lm2BeyR3WAR8Drhixb+lVatnsCiw0b5tniiE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=opVTWemTTcV1Ta57xQ8oc3NLpfcL+nyO2/H1GvmJjes=; b=aiTIq4cGmjLwE8KtUxcXWCVz/ywtmXM60KZNM4YefIdSrHen+4Jrzow6PBLB1czFPJ fTOFD1RPxvPB1cv7uN1opIpqGYtSRIE6rWPkYLySbNYY97RjInDBAnY6NFqwj1vmz/La bxuXsofpjkLYuiFL1smrZ5qumCdQe5CjNMpSMzJ0yq+JGFPNuM30jEeScrSZM1Z17T1X M70gTqVlYl7yhGyhYYM4F4hCS0Et4GoztOAkb3CHfzh3TLBd5Of4WZ5fuYkZvW0kHQMI VAxXQZL5M75HqpgjUeRosH388glYAWV3zf4hG7my1qZLCU8miBR90K0mylGa2rUqNAXO 7YjA== X-Gm-Message-State: AOAM530lT7k4zT4cjbivaP3T0zDLAvh6++WIYbn+IJD/m/nd4RwO2sSm 45vwV12ACeRddvzdOoicEhGd8rgtmWKgVwYlNtQs2I7823/QzCJC0UAHTZWzHAKqVg58ape08fM 6zwtFWJSsUKk5K/c4Whlo X-Google-Smtp-Source: ABdhPJyy25cYmvKimO6l3u86Sv+gle5QSPdtw+TRDUMJXzr6/8USXfBM/hPHdBrp/vYH4zZIVJVokPNhmLkaDqEZ6Gc= X-Received: by 2002:a17:906:3399:: with SMTP id v25mr17992348eja.383.1598490680163; Wed, 26 Aug 2020 18:11:20 -0700 (PDT) MIME-Version: 1.0 From: John Carter Date: Thu, 27 Aug 2020 13:11:08 +1200 Message-ID: To: core Content-Type: multipart/alternative; boundary="0000000000002b1b0e05add19d9a" Archived-At: Subject: [core] Alternative Observe lifetime models such as Stubbornness(tm) 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, 27 Aug 2020 01:11:28 -0000 --0000000000002b1b0e05add19d9a Content-Type: text/plain; charset="UTF-8" This is mentioned in https://tools.ietf.org/html/draft-ietf-lwig-coap-06#section-2.4.1 Any further details or references on what this may be? -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer --0000000000002b1b0e05add19d9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is mentioned in https://tools.ietf.org/html/draft-= ietf-lwig-coap-06#section-2.4.1

Any further details = or references=C2=A0 on what this may be?

--
John Carter
Phone : (64)(3) 358 6639
Tait Electronics=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
PO Box 1645 Christchurch
New Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--0000000000002b1b0e05add19d9a-- From nobody Thu Aug 27 19:05:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB6B3A14DC for ; Thu, 27 Aug 2020 19:05:41 -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 tozqBHLHOUAA for ; Thu, 27 Aug 2020 19:05:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC79D3A14D9 for ; Thu, 27 Aug 2020 19:05:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 451DD389CF; Thu, 27 Aug 2020 21:44:39 -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 qnGHVe5K93qr; Thu, 27 Aug 2020 21:44:38 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4D142389C9; Thu, 27 Aug 2020 21:44:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B9A71931; Thu, 27 Aug 2020 22:05:37 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: "core\@ietf.org WG \(core\@ietf.org\)" In-Reply-To: <9105A6A0-4C53-4FA1-8E3B-C404417313C0@tzi.org> References: <9105A6A0-4C53-4FA1-8E3B-C404417313C0@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] Fwd: [OPSAWG] some comments and thoughts on mud-sbom and sbom-type 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, 28 Aug 2020 02:05:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > I fished the below out of conversation in opsawg. > The objective is to say =E2=80=9Chere, but with coaps:// scheme=E2=80= =9D. Yup. > We can say =E2=80=9Cwith the current scheme, but elsewhere=E2=80=9D as > //elsewhere.example/.well-known/sbom > But we can=E2=80=99t say > coaps:///.well-known/sbom > out of a resource accessed with coap:// Maybe you have a suggestion. rfc6570 has been suggested. > Food for thought. > (I know, use CoRAL :-) Could we easily, in a YANG module? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9IZnEACgkQgItw+93Q 3WUjqQf/X1hWVeVAn/seeMA+vj7ikOi7PzWgbIKm5u+bOgUnmuJNsLGdTwPy+o/Z Po1ecwSWS98cw77vfJwgJd49Oa/in2QBNy5zkInsk3cL3ncObA2mp+cw84UTypfr IrvfzU2Nv0Hz7qv9ftnR695P/rVLC0IXL+xCNwwo5H2GB8y1G3rPUDOfRELEkuG6 T4Eg7wE63Q7WeHBTuZ9VN8bEHHXDpxEH6/fQUfblIS5DQ5CJ26O9eB8RILNBpj5/ 5K2Hv2fPZagych0URLZlTEwlMj3dsV4LObT9+Ym7k4pMSWaNPlrcGzdhUVIC6m0o 1wOaJ6pAyWBwVD7iIrtgHyjLxwDvkg== =u8E/ -----END PGP SIGNATURE----- --=-=-=--