From nobody Mon Jan 2 10:27:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601FC129424 for ; Mon, 2 Jan 2017 10:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lobaro.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHAuvT88WMqk for ; Mon, 2 Jan 2017 10:26:58 -0800 (PST) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [108.178.24.173]) (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 BBD641293F4 for ; Mon, 2 Jan 2017 10:26:58 -0800 (PST) Received: from ns1.am20.siteground.biz ([107.6.152.202] helo=am20.siteground.biz) by se3.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1cO7Ju-0008Gf-Kl for core@ietf.org; Mon, 02 Jan 2017 12:26:57 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lobaro.de; s=dkim; h=Content-Type:To:Subject:Message-ID:Date:From:MIME-Version; bh=DxSK98fn9VDBPdSkyQetafF8GdOyUrZcB7Z8/EejGbo=; b=jZk5cPxpnUjNgJJPbhEWiUc0ZN 1EL7mWAEWqcNQF2/SRFha5tW49/+DFos/OP5gfdDtyYE61oihjAVk5A4M37ilZ6e67M8+FyNkVEsC BrX31QNQUafRo22auzmq/zKwi2gTN2tP4MPVcsTniJSXpJSyjPM3K/ZKIqs9KCtbrujM=; Received: from [209.85.161.180] (port=33219 helo=mail-yw0-f180.google.com) by am20.siteground.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1cO7Jt-0007MF-Dh for core@ietf.org; Mon, 02 Jan 2017 19:26:53 +0100 Received: by mail-yw0-f180.google.com with SMTP id r204so272853750ywb.0 for ; Mon, 02 Jan 2017 10:26:53 -0800 (PST) X-Gm-Message-State: AIkVDXJbmNq5SDO7dslQTh8LNfZv8fKt4DTziYXsF3N+nS0Y/AuqUaA6pHIvPE2nZt+raNAuyQQd96k5HEKLEA== X-Received: by 10.129.153.5 with SMTP id q5mr53371082ywg.256.1483381612413; Mon, 02 Jan 2017 10:26:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.173.40 with HTTP; Mon, 2 Jan 2017 10:26:51 -0800 (PST) From: Tobias Kaupat Date: Mon, 2 Jan 2017 19:26:51 +0100 X-Gmail-Original-Message-ID: Message-ID: To: core@ietf.org Content-Type: multipart/related; boundary=94eb2c0bda26132917054520b22d X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - am20.siteground.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lobaro.de X-Get-Message-Sender-Via: am20.siteground.biz: none X-Originating-IP: 107.6.152.202 X-SpamExperts-Domain: am20.siteground.biz X-SpamExperts-Username: 107.6.152.202 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=107.6.152.202@am20.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.24) X-Filter-ID: s0sct1PQhAABKnZB5plbIdH40z9tliyPtpXyyHKT/m4RjSEj2nYPqqWQeUf53awN/bPom7IVowNb jNmNSGjlJJS31NqWy1r8mVG8NckVYvJ4fwnza0AjOF3X1ZlT7L/Ft4lP0GR8jfSinTz1pajzuyEb xxLK3QENjMlUnGz2Ts9nABDFwnaHjqbqjUbcxfPPXE40W9d0p7O4rbrYaLqwACOV/mGuOO4+DLa0 3VcixZRm4zuNRcgRKiGg7nXFaZTx//tFQAs3zDmNrc3GnFYNqhjZPju8Yrl97OtSGugEjk4URvWx 0knMZb70Q77PCeyNejx+ZEH83D3uT7G9vVxSoDnlKnN5EY5Xdpjv88dVSAvrjuU3A3io6xJmD59i FVkbFIc8h94caA+NPqtxRqOTvif6OC2JfWwXCnj8ISEr5W1QfHuHaxfQuSMwbOTNEn0sTypGxHgW C4XTyiSMgbf1OY713u8sUg7qYoWrd2yUM98XKu1VbgppFJRGoXLED7mHiE8E38RbdBtd0b9yL+aO NlaplafOirH+W3GOYf6wZShQJdtkddTPDvOO+kGbv+2LNIob0OsCEDoNvkVifa0KPWeupYYdzPm7 YfRDaULOU2kSpt+d87cfMcGsNXCp7ARssXBCClSYNCe3q3XFvJn9q3McN6qoXPjenLhIOF1oeRZY LC/SyqBNA1frz8ZHfOk8XuZcsN/wm1toCWhZrJhDIIcrMB/seAvHoK8kqFxnN0jcjS5E9AV2NsX6 VLjvFnXJB22niq1/gWQDVBnGJw2WMseOVuodnLVvldfhMjBky8VSLaTZh1EReo2BAQ7GpEsP4jX2 BkfNHJBioY9NgVkMhVNT/sjdakyzO5YcNFZ1BaY= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com X-Recommended-Action: accept Archived-At: Subject: [core] CoAP Observe over serial X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 18:27:00 -0000 --94eb2c0bda26132917054520b22d Content-Type: multipart/alternative; boundary=94eb2c0bda26132914054520b22c --94eb2c0bda26132914054520b22c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I just implemented a basic observe request for my Go CoAP Client over Serial. (Code @ https://github.com/Lobaro/lobaro-coap) I have some thoughts where I like to get *confirmation or feedback*. CoAP by default restricts a Client to have 1 open interaction at the time. Would you also recommend this for Observes? Due to simplicity I implemented it the way, that there can be only one Interaction, which means I can not do any request als long as the observe is running. Another implication is, that I can not observe 2 resources at a time. But since I need to be able to send requests while observing, what would be a good alternative? What comes to my mind is: - CoAP pub/sub (I have not looked into it yet) - Allow for multiple parallel interactions on client side (makes code more state-full / complex) - Polling multiple endpoints (maybe the worst solution) I guess implementing parallel transactions would be nice in any case. Since we have no concept of connections or ports, mapping from CoAP messages to Interactions must fully rely on MessageID and Token? Or do all server responses carry the Token? I'm also a bit afraid of loosing resource updates. For some resources I must be sure not to loose any update. Maybe that's a reason for pub/sub over observe? Enough questions for now ;) Cheers, Tobias --=20 Lobaro UG (haftungsbeschr=C3=A4nkt) Tempowerkring 21d 21079 Hamburg 040 / 22816531-0 www.lobaro.de info@lobaro.de USt.-Identifikationsnr.: DE297198645 WEEE-Reg.-Nr. DE18824018 Gesch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde Sitz der Gesellschaft: Hamburg Handelsregister: HRB 134264 Amtsgericht Hamburg --94eb2c0bda26132914054520b22c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I just implemented a basic observe = request for my Go CoAP Client over Serial. (Code @=C2=A0https://github.com/Lobaro/lobaro-coap)

I have some thoughts where I like to get confirm= ation or feedback.

CoAP by default restricts a= Client to have 1 open interaction at the time. Would you also recommend th= is for Observes?=C2=A0
Due to simplicity I implemented it the way= , that there can be only one Interaction, which means I can not do any requ= est als long as the observe is running.

Another implica= tion is, that I can not observe 2 resources at a time. But since I need to = be able to send requests while observing, what would be a good alternative?= =C2=A0

What comes to my mind is:
- CoA= P pub/sub (I have not looked into it yet)
- Allow for multiple pa= rallel interactions on client side (makes code more state-full / complex)
- Polling multiple endpoints (maybe the worst solution)
=
I guess implementing parallel transactions would be nice in = any case. Since we have no concept of connections or ports, mapping from Co= AP messages to Interactions must fully rely on MessageID and Token? Or do a= ll server responses carry the Token?

I'm also = a bit afraid of loosing resource updates. For some resources I must be sure= not to loose any update. Maybe that's a reason for pub/sub over observ= e?

Enough questions for now ;)
--94eb2c0bda26132914054520b22c-- --94eb2c0bda26132917054520b22d Content-Type: image/jpeg; name="lobaro_logo.jpg" Content-Disposition: inline; filename="lobaro_logo.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 8457dcfce885091a_0.1 /9j/4AAQSkZJRgABAQECWAJYAAD/4QCKRXhpZgAATU0AKgAAAAgABwEaAAUAAAABAAAAYgEbAAUA AAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAQAAAAclEQAAEAAAABAQAAAFERAAQAAAABAABcRlES AAQAAAABAABcRgAAAAAACSe+AAAD6AAJJ74AAAPocGFpbnQubmV0IDQuMC45AP/bAEMAAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB Af/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAf/AABEIADsAyAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0 4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery 8/T19vf4+fr/2gAMAwEAAhEDEQA/AP64v+CQUss3/BKf/gm7LNJJLK/7Dn7LjPJK7SSO3/CmPB3L OxLMfckmv0Wr85f+CP3/ACij/wCCbf8A2Y3+y5/6pjwdX6NUAFFFfEf7Tf7RHxS8PfEHwF+zB+y3 4Y8H+Lv2mvih4e1nx3NrXxIbWG+EfwA+Dvh/UbPQ9X+MvxXsvDd1p/iTxN/aPiPULXwn8L/hboGr +HNa+KPiiPXFj8VeFPCvgvxt4r0AA+3KK/N5P2Pf2zL+L+19c/4KxftLWXi0gSnTvAP7PP7CXh74 Rw3H3nt7TwV40/Zn+JnxG/shnyq22o/GzU9Zjt8Rr4h88fajpfCL46ftB/CL45+FP2Vv2zLrwJ4z 1L4rad4kvv2Z/wBp/wCGXhnUPAPhb4yan4J0mfxF4x+EHxK+GWo694sX4bfHfQfB1nqHj3SD4e8U 6z4F+K/grQfG3iDw3ZeCNQ8Fa14QiAKvx/lkX/gpJ/wTojWR1jl+FP7eXmxqzBJNmh/s5snmKDtf Y3K7gdp5GDX6M1+MP/BR39oTQ/2Zv2zf+Ce/xI1Lw5rvjzxBd+BP2z/Anwz+F/hM2Y8YfFn4s+P0 /Zn8L/Dv4beFzqE0Gn22oeJvEeoWkN9rWpzQaH4T8Pw6z4w8SXVj4c8P6vfW3uGk/s6f8FBvivaw +KvjX+374g/Zx1rVEF6Pg9+xT8Hv2eb3wb4HWUboPD2ofFX9q/4MftB+MfijqOmrtj1Lxjpvhj4Q 6Xrt2JZ7HwFoFm0VoAD9LqK/Kbxp47/a/wD2BbSL4pfHP4y2X7ZP7HmlXVpH8ZvH+v8Awx8HfC79 pf8AZy8MXNxHa3Pxq1k/CLT/AA18IfjJ8IfB/mx6l8VdM0T4WfDDxr4B8Hwax8QNMu/Hdjot/wCG Yf1IvdY0nTdIu9f1DU9PsdCsNOn1i+1m7vLe30qz0m1tnvbnU7nUJZEtINPt7ON7qa8llW3itkad 5BGpYAGjRX5UeBvEf7aP7eGkW/xf+Gvxqk/Yd/ZS8Up/aPwQuPCnwp8C/ET9qn40eA7rLaH8Y/Ee ofHLQ/Gnwn+C/hDx3p4g8Q/Dz4dy/B3x744uPCOp6P4k8Z+JvCetalc+ANC6XWfgJ/wUO+C9nP4w +Cf7b2rftZXujRtf3PwL/bN+FvwB8L2Pj+1gHmXXhvwr8b/2WfhB8B9R+FfiPUEV49E8VeLfh78Y PDtjfNDDq/haTT5ZLyyAP0yorwn9mz9oDwl+058HvDHxe8I6drvh1NWuNf8AD3ivwN4ttYLDxt8M /iP4H8Qan4M+JXwv8c6bbXF3b2HjH4eeONC13wn4ghtLu806e+0t77R7/UdHu9P1C6/Ib9j/APbG /bP/AG7Ph1F8OfgN4z8DeGNb+GXi74oeGf2pf2yPiF8PrLxjZeE/F1v8V/HK+CPgP8EPhF4cvfAv hTxd8WtF+EqeBPEHjvxl4s1KLwR8N9H8R+DhqHhn4neMfEet6T4dAP3vor83Zv2QP20tJhOr+FP+ Cr37RWq+LkUyrpnxd/Z1/Yd8X/CG6uh80cGoeDPhj+zp8D/iUNID4je20f43aNq0luSra4bnF0PT f2WP2kPiH498WfEv9nb9pLwf4Y+Hf7U/wRsvDOveKrDwNfapffC74ufC7xtNrNn4E+PXwYuPEAHi GLwX4k1Xw14m8M+JfB3iCS+8S/C/x54c1jwprGreItJm8J+NfF4B9q0V8cftU/tG+OPhhq3wy+CP wB8FaF8Tf2pfj3N4m/4Vn4X8W6pf6L8PPA/gnwPHo7/En47/ABi1fSLe71uy+F3w2bxL4V0ubS/D 9tJ4m8d+OvGPgj4f6BJpc3iS78S+HvJIP2RP21tdhGs+Nv8Agqx8f9B8XSqJ5NH+BX7On7E/gn4P 2N23zyW+meEvjF+z7+0N8TpdIV/3UUGufGzWdT+zqP8AibLcs1xQB9hfH5viGvwb+IDfCv8AtX/h ORoTf2SfDyaTJ4rW0+1Ww8QP4Jj8QBvD0nj5PDf9rv4Cj8RK3h2TxiuiJrytpDXgP56f8Et0/aqg 0Lxdb/tA3XxbvtPj8P8Ag6W4uPi/F8XC4+Id1DdXetwfD+/+PFjovxV1LSrfTLi2tvF5v/DmheAN K1C38M6F4BbxZremfEr4heMfSPA/xo/aU/Zu+M3w4+A37Y3iHwT8XvAHxy1i88HfAH9rPwP4Nk+F 93cfFGz0bUvEtr8E/wBoT4bR614h8M+HvGXi7w9o2vX3wy+JvgPVdL8E+PtU0HUPBV/4E8A+Lbrw haeOP0joA+d7r/hIvjJ4u8VaJZ+Jdc8IfDDwHq3/AAi+pz+E7+TRvE/jzxfDZ2l9rdmviO3xqnh7 wt4cW+tdLlbQZbDWdX15NTi/ta0sdNEN9ZvvgYmhQPqfwn8Z+NfBfim1Uz2a61428Y+OvCGs3EY3 LY+KvDfjHXNdhubG75gudQ0d9K8QWyym5s9TWWMI8Xwz1S18FeO/iF8LdflTT9V13xp4k+JPgWa6 YQw+LvDni+ePWtYj0maTat3qvhbxFcarp2saZGWu7TTTo2pGM2d+ki+w+LPFvh3wPoGoeJ/FWq2u jaLpkRluby6fG5jxDa2sKhpry/u5NtvY2FpHNeXty8dtawyzSIjfKYTB5bjcHicfmbhLG062LWNx latKliMpqUKtS9DC4nnhUyyjhKSg6U8NOgq1Llxs5VZ4mder+AcP8PcFcTcOZ1xZxzLDVeJsHmfE seJuI8wzOpl+b+H+KyrMMYqmV5FnccTh8XwTl3D+X08K8BicmxGVQzLL1h+KMVVx2IznE5pjsb4Z +NT8QPBumeI5tPbRtUM+qaN4i0OSUTvofinw5ql5oHiXRzMoXz47DW9NvYLa5KRm7tFt7sRos4Ud 5X5eWXx/+Kn7JWr6r40/aa8E6ZpX7J3xd8Vat47tfjN4YtdTXVf2Vte8aapLeHwx+1ToM95qS2Xw 5v8AzbW9i+P3hoWnhX4e6rfX3hr4u+HvCnh/Sbf4o679QeKf2vPhRo3iS+8GeDrLx/8AG7xdpEVn P4g0P4FeBta+JcXheLULWK+09fFPifSI4/BPhu+v7GeC+sdH1nxPZ63eWM0N9babLZyxzt9Nw7hc 1zbL8C44bEYrGPAYfEYtxoOEoJwpqeIxUVGNPCKU5xdVVPZ06NWoqTadkfoHCPEdWlwDwbm/GWOj g81zLIMmnjKmZUoZdjcdmWIy6nXm55YqdGdDM8XGM8Xicpw+GVTB1XXw8aMY4eXL9R0V4H8Lf2k/ hl8V9f1HwTpsnijwd8SdH09dX1T4XfFDwf4h+HPxBt9GaZbca7Y+H/FFjYt4j8Oid4oJPEnhS413 QIbmaG1m1OO6lSEld2KweKwNZ4fGYethqyjGfs69OVOThNc1OpFSS56dSLUqdSN4VItShJxaZ9lg MywGa4ZYvLcZhsdhnOdP22FrQrQjVpS5atGbg37OtRmnCtRny1aU04VIRkml8w/8Efv+UUf/AATb /wCzG/2XP/VMeDq/Rqvzl/4I/f8AKKP/AIJt/wDZjf7Ln/qmPB1fo1XMdoV+cf7LGNd/bt/4Ki+K tSH2nWvDfxC/ZT+CWkXknzS2fw88Kfsq+A/jJo2gwO2Wjs7fx9+0J8T9cECbY/tfiC6mKmSR2P6O V+cf7IXy/tm/8FYkbh2/aX/Z1nVTwzQP+wP+y5AkwB5MbzWtzErj5TJBMgO6NwAD9HK/OT/gqAq6 V8BPhB8Q7NRH4n+F37eX/BOnxD4S1AfLLYXXjP8Abe+BPwW8XxRyD544/EXwu+Kvj/wdqJjZWl0j xJqFuSUmdW/Ruvzn/wCCqALfsoeH4lBaWf8AbY/4JhQQRqCXmmk/4KYfsjrHFEgyzyOeERQWY8AE 0Acb+1P4I8O+Lv8Agp1/wSr1bXtPgv7v4deF/wBvnxv4XaeNZVsPET/DT4PeCl1CNXBUTw6J4z1u KCTG6GWdZoyskaMv6lV+cH7QciJ/wUp/4Jwq7qrS/Cz9vaOJWIBkceHv2dpSiA8swjjkkKjJ2I7d FJH6P0AYfifw3oXjPw14h8H+KNMtdb8M+K9D1bw14i0a/iE1jq+ha7YXGl6vpl5C3yy2t/p91cWt xG3Dwyup4Nfj78BPhr8T/wBrr/ghZ8D/AILaJ4xsrHx18Zf2IvhZ8H9Y8ZeKtQ1a0W/8MX/hLQPA fjy81bVdGsNT1ZNb8SfD238QQG/s7N5X17U0uGe1jZ7iD9nq/A/4YfE/xn8IP+DeH4b+Pfhvq8vh zx9/wxJ4K8PeAvFsGTJ4R8TfEyz0vwF4W8eW+GVZB4R1DxbY+L7diwglTS0Z28hy1AH2Tc/tnfEv 4g+I/Efw5/YE/ZZsf2gPDfwu1vUPhz4m+NvxD+K9j+zf+ypovi7wlcvoOu/D/wAB+NdM+H/xh+In xQ1TwJqFjd6B4rufhl8F9b+HnhrXdNvPB9x46TxVpWs6FpVPW/2sf23fgVZzeLf2pP2GPCmo/CXS ozeeLviJ+xL+0R4h/ae8QeA9EQFr3xN4i+CvxE/Z6/Zr+JfiDQdEiButZh+EVn8VfGS6ek95pvgv UhbzRL92fB/4T+BfgR8Kvh38F/hjokHhz4ffC3wb4e8CeD9GgCkWWg+GtMt9L09Z5QqNd300NsLn UtQmButR1Ca5v7uSW6uZpG9HoA/Lf9gLxx4M8X/tE/8ABR+++FHiXRfFfwd8b/Gr9nf49eAta8M3 9vqfhfVT8bP2NfgTf654i8NXto8ltLpHjGbwxZeMJWtn8m713Xdb1dh9r1W7d2/8EafA/h3wP+wP 4Gi8PafBZP4p+Mn7WfjjxBcRxotxq3iPxN+1d8Z7y+1C+lUB7meO3Wy0u2klLPDpem6fZKRDaRKv mf8AwTQ+B3hr9nn9sL/gr38PfBD/AGfwNd/tQ/Br4h+FfDqSs1n4Nh+K37OXgj4k+I/C+kWgbyNI 0Cy8c+KfFd54e0Oxjt9O0bRNQsNPsLaC0t4o196/4JM/8mG/Cb/sdv2kP/Wn/jLQB+jlfKHxB+An ibxB+2B+zb+0r4V1TQNJsPhh8L/2hvhD8UbO7m1GHXfF/gv4uT/CjxR4X0/TYbTTrjT9QHhrx98K dL1ffrF/YNpNpqGr/wBkGeTV9Rt5vq+igD84vhIB4i/4KmftrazqwF1d/Df9kv8AYd8A+DDJyuha J418c/td+OfGn2FekNx4s1nT/Cv9uSrze2/gvwvFJxpkVfo7X5x/An5f+CnH/BQ5G4dv2fv+Ce86 qeGaB7v9sSBJgDyY3mtbmJXHymSCZAd0bgfo5QB+c3/BWSNbb9gf43eLoB5Wv/Cu9+E/xp8Fainy 3Wi+Pvg38Z/h78S/BOs2U64lt7iw8SeGNOkZ4mRpbY3FrIWguJo3/Rmvzq/4K1c/8E5P2r0HLy/D q3giX+KSe48VeHYIIUHVpZppI4okGWkkdUUFmAP6K0Acv4t8E+EvHmljRvGPh7S/EOnJPHdwQalb JM9neRZ8m+0+5G2602/hyfJvrCe3u4dzeXMu45+Dv2F/C2h+L9J+MXjHxfaS+LvE3w+/bB/au+HH gjWPFV/qPiO68K+Dfhz8a/FnhLwXpOh/21d30WnyaH4d02y0yPVbeNNZvIoTLqOoXlzLNNJrSaLr v7ZXxT+Kuk+IPF3i/wALfsw/BPxpc/CiPwX4C8Ta14H1n45/E7QtP068+IOq+OPGPhi90vxXa/DX wVqGqp4H0nwV4f1fSYvFHiXSfFGp+LLrUNHtdG0h9bUv2BPhL4Q0+61n9mG61/8AZh+KVo9xqWh+ MPh54h8SS+G9S1lma58j4m/DbVdZvfBPxL8Pate7D4htfEOkSa7PE01xo3iDRdX8rUovGq4TB4uu sc8nwGLqUpJU8XXpUHjH9Xm+WWHlUw83aE1J0JTxFFN+9FxhKM39fmngf4Of2zlWI8RMbkuF8Rqm EybHQxtTwyyzijCcKvF0KOZZHh+I+Laua4biLLsbl1LE4fG5nhuG+GuJa/D/ALZ4enDE57hsflGD 9o/a18d6p8Mv2X/2gfH+h29nc614T+EHj/WNIj1G1ivdMXU7bw1qH2G41SzuI5re70u0umiutStp 4nhnsYbiKVfLdq6H9n74HfD/APZv+D3gL4MfDLRdO0Xwn4H8P6fpNsmnWVtZf2rfRW0S6n4gv0tU SKXVNdvhNqWoT4w09wUjCQRwxJ+d+n/FH9qb9v3wRr/wR8O+Abf9mjwHZr4q+DH7XPx18T2nh7xh qeoeMtFmv/BvxZ+E37Jvw+1k61putxy3MWpWF78b/jHpTeEPCVpfW+neHfhz8V/EKa5L4M+iPBvj j47fs26LYfDD4m/CX4lfHrwh4UtYdE8A/HD4QW/h7xT4h13wtp6La6FY/Fn4fahrugeKNL8eadps dvY6t4j8K2Xinwx4qntm16WXw3eX82i2/wBxl3/CpkX1LAVqMMT9fWPrYatXo4WeZYaphaVLBuk8 ROlCrWyyosX/ALJz/WZLNJzoUakaWJlS/M+MMqxvAviBmNDijBV1LKcPjOF6mIwdGpmtDIc3y7Ns T/bEZ1cuhirYLPIwwDp5tRU8snHIaPtsXT+tYD6zt/t4aXaaT8Bdf+OWmxJZ/Ej9msp8Z/hv4ht1 Eeq2moeF5re68ReFIrlcSzaJ8SvC8eqeBPEmiuz2erWGtJ5sDXlnp89sVia7YfFn9rbUfD3hvxN8 L/EvwP8A2b9G8SaB4t8ZWnxHu/D8fxU+NV14U1a01/w94KtvCHhfWvEdt4G+HD+ItM0/U/GN/wCJ 9Zh8WeKbCwi8L23hfStJ1TU9Ucr7/hvP+EOGcsjlvGPDlHizHfWK2IwsaGNoVo5PhKqpXwUsRTqT oupWrxr4uphaNScMNKs3V5MXWxNKn+Jca8JeInG+eSzvw34zxPAGV/VMPhMfPFZbi8NU4kx+HlVa zSGDrUKddUcNhJ4fLqOPxFKlUx9PDpUVVy/DYHEVvDP+CRvxg+Eulf8ABLH/AIJzaZqnxR+HWm6l p/7En7Mdnf6ff+NvDVnfWN5bfBzwhDcWl3aXGpxz21zbyo8U0E0aSxSKySKrKQP0P/4Xf8F/+ivf C/8A8L/wp/8ALavB2/4J0/8ABPl2Z3/YT/Y3Z2YszN+zD8E2ZmY5ZmY+CCSxJJJJyTyab/w7n/4J 7/8ARiP7Gv8A4jB8Ev8A5h6/IT+ij6a8O/EPwB4vu5rDwn458H+KL+3tzeXFl4d8TaLrd3BaLLFC 11Nbabe3M0Vus00MRndFiEssUZbdIoP53fHPV9S/Yn/ap179sK88O+JNf/Ze/aB+Hngj4d/tV6j4 P0HVvFer/An4g/CK68Rf8Ko/aL1XwtoFpqXiHVPhj4g8G+LtX+GPxs1vRNP1C68BWvg74ReML/TY /BWn+P8AxDoP2J8Kv2Uv2XPgTr994r+CH7NnwC+DfijU9Hm8Pal4k+FXwd+Hnw81/UNAub2w1K40 O+1jwj4d0jUbvR59R0vTL+bTJ7mSylvdOsLp4GntLeSP32gD5z8PfthfsleLfB8PxC8L/tQfs8+I fAc9mNRi8Z6N8aPhzqPhZrFoxL9qOvWviSXTEgWM7nd7lRGM79pBA+JNQ+KPh7/gpD8c/gp4d+A1 3/wnP7G37NvxW0X4+/Fz9oXSo5ZPhf8AGn4yfC+S6vPgZ8Ffgh4odP7L+KmkeCPiU+lfGv4n/Enw ZJq3gjw9rPw18CeAtM8Rar4g8ReKbPwp9p67+xj+x74o8Vy+PPE37KH7NfiLxxPdm/m8Z678Cvhf q/iua+aTzWvZfEWoeFrjV5LsykyG4a8MxkO8vu5r6NtbW2sba3srK2gs7OzgitbS0tYY7e2tba3j WKC3t4IlSKCCGJFjiiiRY441VEUKAAAfh1/wVF0746Qftu/8EwfiP+znpp8W/E/4IWP7aPxZh+FP 22x0s/G7wZpfhP4IeF/ib8IrHVtVuLbSNI8V+K/hz4t8USfDjU9amh0Kz+J+m+C5ddutP0cX2pWf 6E/Bf9vv9kH476VPdeDPjt4C0nxPpDfY/G3wq+Imu2Hwz+NXww16JFa/8LfFL4Q+OLjQ/H/gHxJp khMV3p3iLQrIShReafNfabPa3s/1Vd+HfD9/rWj+JL7QtGvfEXh221az8P6/d6XZXOtaFaa8tiuu 2uj6rNA99pltrS6Zpq6tBZTwRaiun2IvFmFpB5flnxS/Zp/Zy+ON1Z33xr/Z/wDgn8YL7T4lgsLz 4pfCrwJ8QLqxhRmdIbO48WaDq81tErszLHC6IrMzAAkmgD4n/aU/bZ8O/FHT/E37J/7CPxC8L/Gn 9rb4kaVceCxrnww1Wy8e+Bv2T9E8Twy6VrXx8+PvjDwzdXvhrwNB8PdIuLzxH4J+Hms6xZePPi14 ws9B8J+E9CnstQ1jX9B+l/Ev7Hnwn179im//AGELWHUdF+DMn7OMX7M2ivZTL/b3hzwVpvw+h+Hn hzVtLvUWAReJPDdhaafq2lajGsLwa3p9tfR+XJGpX33wN8PfAPww8PW3hL4a+B/B/wAPPClk7yWf hnwN4Z0Xwl4etJJAoke20XQLLT9NgeQIgdorZWYIoYnaMdhQB+aP7On7enhPSIdE/Zy/be8aeC/2 ff20vA+mw+HfGHhz4i6xp/w/8I/H59CSLTf+F6/s1+IfE02l6F8TPht8RUii8Uf2L4X1DUvFnwu1 DVLnwH8RNH0TX9GY3nsPxr/4KBfsk/Ayxt4dd+MnhLxt8QdcLWngD4G/CLV9M+Knx7+K2vvGxsfD Pw0+Efgy91Txh4n1W/mEcBu4tPt/D+ixy/2p4n1vQtDt7zVLb6W8f/DP4b/FjQJPCnxT+H3gj4l+ FppVnm8NeP8AwpoPjLQJZ0VkSaTRvEVhqWnPKiO6rI1sXVXZQQGIPI/Cz9nT9nz4GPev8E/gT8Gv g8+pR+TqL/Cz4YeCfh89/DvWTyr1vCWh6QbqPzEWTZOZF3qrY3AGgD8qv+CTmhfG/Tv2jP8AgqT4 m/aOSy034z/FL49fAT4qeLvBmmahb6xp/wALLHxl+zX4IuvA3weg12zLWXiK7+E3w6g8I+ANe8Ta ex0vxL4l8P6zr2kCPSdRso0+nv8Agkz/AMmG/Cb/ALHb9pD/ANaf+MtfoHYeHfD+lapruuaXoWja brXiiewuvE2sWGl2VnqniK50rT4NJ0y413ULeCO71efTtKtrfTLCbUJriSz0+3gsrdo7aKONTQPD vh/wppUGheFtC0bw1olrLez2ujaBpdlo2lW0+pX1zqmozQafp0FtaQy6hqd7eajeyRwq91fXdzdz mS4nlkcA2aKKKAPzU/aeh8Ufsw/tK+FP28PDfg/xZ48+FOt/Ci0/Z3/bI8NfD/QNU8XeO/Dvw58K +K9f8ffA/wDaB8PeCtAtrvxF43034I+KPHHxY0L4jeGPDOn6x4sk8AfF3UPGehaVqR+Hlzo+rfSv gb9s79kT4m+EYPH3w/8A2of2fvF/gye2+1f8JHofxf8AAN9pdtGF3Sx6jPHrx/su7tCGiv7HUhaX un3EcttfW9vcRSxJ9LV85eMv2PP2R/iL4pl8cfEH9ln9nLx341nuPtc/jDxl8EPhn4n8UzXW7f8A aZfEGt+GL7VpLjd83nPdmTdzuzQB8MfFD4xeDv8AgpH468A/s3fs06zZ/FP9mvwV8WvAXxR/a7/a N8JTLrHwXvNP+CXjLSPiP4P/AGZvhv4/si/h34ofEH4ifFDwt4Qj+LEHgfVNa0H4efCXRvGmheNt T03xZ4y8KaFf/rpVDS9L0zQ9OsdH0XTbDR9I0y1hstN0vS7O30/TtPsrdBHb2ljY2kcNtaWsEarH DbwRRxRIoREVQBV+gD4D+C/jDRv2efjf8Yf2e/ibfWvhVPi58X/Gnx0/Z78Ua1NHp2gfEzTvilcW 3iTx74D0nVblksH+I/gP4hXHiSS68JPdLrGpeDNZ8M6/pNldWi6sdP8AqX4x/G34a/AXwdd+Nvib 4ktdD02NhaaTpsYN94m8Xa5OVj03wp4I8NW2/WPFvizWbp4bLR/D+iWt3qN9dTxokQTfInSePvh1 4A+Kvhm+8F/EzwT4U+IPhHUthv8Aw14z0DS/Emh3TxbvJml0zV7W7tDcW5YvbXAiE9vIfMgkjkAY eR/DX9kD9mD4P+JI/GPw3+Bnw58MeL7eF7ax8VW/h61vfEml2kqsktno2u6oL7VNFspY3aOWz0m6 s7aWMhJImUADijTxVGLpUXRdO8vZ1Kjmp0Yybai6UYctZU7tQ/e0W4KMZNyTnL9ex3EHhvxVi8Px PxbS4ywvEKw2Ap8QZJw/hsmrZVxbjsvwlDCVM0o8SZhmNLG8HYnPIYeGIzeH+rHGNGlmtXHZjl8a ODxeGyTLMj9jzwF4x8E/ByTU/iLpJ8O/EL4sfET4ofHPxn4W8+K5Pg7Vfi9461vxrZeCpZ4C0E17 4N8P6novhnVriCWaC61jStQureeWCaNz9TUUV00qao0qdKLbVOEYJveXKkuaVrLmlu7Jatn59xPx Bi+KuI884kxtHD4bFZ5mmNzOrhcHGpDB4N4yvOtHBYKFWpWqwweDhKOFwlOpWq1IYelThOpOScmU UUVoeEFFFFABX53X3x9+LPhT4q/FvwV4S0PTfiNrnjT9uzw18BfAmm+NPF1/4Z8N/DzwxL/wTt+F /wC0Lreqx3NhoHiO8uNM03WPDvi/XZPDdnZW0utan4k1BYdT0+5uhcD9Ea/NBLG1/wCGpJp/K/e/ 8PLxfb98n/H1/wAOc4tN83bv2/8AHl+52Y8v/lps8395QB6Gn7TnxW+3zfCj/hA/AFz8dF/aPm/Z 4hvIvFHiGD4V+Vbfs46N+1HefE27d/D0/i230+y+Hut2nh0eCoba7u734iy2Wj/8JZZeF7y48Z6X x3wS+NvxQ0X4vfFLwb8UPDumnxB4+/b3X4JiPRvGGra54U8MaBpH/BNb4c/Hmw8QeCjq2kWN9Hpn iO98ByT3/hK5stLGg+IfGniZ/wC1PEMumjWvEny9+3T4q1/4RfCH9tT48fDvUG8OfFf4P/tt/Bjx d8OvFscFrqMnh7X/ABZ+yl+yt8G/EN22j6xBqHh/WINU+G/j7xZ4cm0zXtJ1TSkOpx6xBZRa/pmk 6pYfG0vxr+KOjf8ABNP4k/tlWHi68X9pO0/bK+H3xTtviVc2elahJB448T/B34P/ALO2s6rH4V1C wuvA62dx8GfEWseCLbw8PDP/AAjemWl0mqaXpFlr9pZarbgH7L/FT9rTxZ4P1j4g6PpPhPwpoeh+ AP2gLH4NeJ/i7491LxRJ8NvAOg3f7Nfwy+PUPjv4g/8ACLeHr248O6dqGtfESL4fW9/r+q+GfA2l SW9vrWv+PNP1C/0bwrrdrwh8afjtrnx78S6DOPgvqvwn0D9mH4I/GC4uPCPibXdffUda+IGrftAW d7qvgnxEPDVjaa54f1l/hz4dGmyX7xW0WhqNTs2uLzUJoh/PB4n/AG6P2q/g5+ydo/xu+HfxavNF +KHx7/a08T6l8WPFN74W8C+JZPFN1afspfs6x2QTSvFXhfW9C8PWtjDpenWthp/hfTNFsLGytIbG 0tobRfIP3B4W+IfjD4Y/FD/gl5ovgXVl0DSv2qv2PPElx8erGLTtKvIfHcmhaFcfFbR8DUrG8bwt Hp3j34y/ErW7WHwW3hyGOPxNJowj/sHTNF0vTQD9K/h98d/if4+8P/sU/EX4leDtH8Cx/tG+PtL1 Twz4O8F/EPxFdz+D9D8RfsifHv4tx6d8UL06RpeifEG6t4vC9rBc+G7Wyg8M6L4puNP1zT9X1+68 E6PrGs+BfGf9svUvGHws/ao+Hui+KfhJrl9efsO/tcfGbwP4/wD2ffiP4j8UReEJvhR4f8NeHJtO ufFUnh7Q9P1fVpLz4o+HdY0Hxb4R1CyexvtE1qxvND06a30zUb70tfDGh+I/gd/wTH8MazY/bND1 BtE0W7svtN5bebpup/8ABOn9prRb22+02lxBeR+dpl9dW3nRXCXEXm+dDLHcJHKn4i/sc/HH4q/t K/CX9pjVfjZ4wvPGt18LP+Cb37Y3wv8AASfYdI8OafoHgnWfD3wMn1PS10jwnp+haVqN5dv4V0BX 8QavZX/iNINOjtotWS3muYpgD+lj9pzxN4g8K+EPhze+HNXvtGutT/aO/Zo8M6hcafO0Et34f8Uf HHwNoPiLSJ2Xl7HWdGv73Tb+A/LPaXM0TfK5ryG2/ad+JF9pOhfFe7+H3hCP9njxh8b9I+Bel3Fl 4z19Pi7HbeMfjTB+z14J+KR02Pw5b+GzpXiX4japoN2/g+DX7HXPDvw71hfGcvia68U6fc/Dgep/ tUwRXHgz4ZrMm9U/aa/ZcnUbmXEtv8evAM0LZUqTskRW2nKtjDBlJB/GHwl8UvHt7/wVtvv2G7rx DLN+yt4Z+Lut/GLRPhI1lpg0+y+IOn+DU/aa0vVv+EkWyXxrc6do/wAdL5/iDovhW88S3HhHRtQt dJ0zS9CtNA0PRtJsAD9MPhh8GfD+k/tdfFvQIvHP7Q2oaB8N/hd+zf448I+H/Ef7Vf7TnizQbTxJ 4x8U/tD2Xia61XRfFHxd1jS/FFlq9r4G8LQXGieKbTWtCRNL/cabEb3UTd6f7Rdtr9h8XG8S/FGx /aJ1T9me3+F/h230a+/Zu8Z/FDw/qPw9+Jtp4m8dXHxE8RfE3wx8BfFXhj42eNND8SeFLv4XWPgm Tw3o/wASPD/hWfw149vvEei+EF1Kz1rWvWfBUESftdftDXKpiab4HfsuRSvuY7o7fxb+1C0K7Sdi 7GuJjlVDNvwxYKu38Ov+CxX7e37Wn7NP7UvhL4UfA/4uXPgLwH4j+BngnxJq2kWng/4favdy674h +InxK8N6tqVr4g8ReE9Y8SaZcT6NoelWsJ0vV7JLCW0W+09LW/kmupAD9g5f2gviT4p/4T6f9mfw r8PPix8P/gr4d8HtqHiXxV8S9WttS+Lmv+Ifhj4a+Lth4a+H+taT4d8SaXHBcfDDxt8PfENn8S9f v9W0vxHrfjAaT/ZFnaaXf+JX4T4Y/tIpqvxV8QeIPDx1HxN4I+Ovxg/Z80PwZ/a2o3lmvhjwr4+/ ZDi+Ldpq1hpUqXkVvNdtoURvdIiNlG93q91ezXLXELLcfmH/AMFDPHPi39j/AONf7NX7Pn7Nmu3v wn+EHx5+GXww+F/xS8I6CYrz+3/CHhbWPDnwS0KPT9e12PVvE/hHxHY/Cu4h8GHx14M1rw945utM 0fwxLe+I7m/8JeGLvSPpz9ti7m+B3wN/bZ+IvwnW28FeL/gV8S/2TfEPwm1PTLKzmt/BWqab4P8A hF8PLN9O0bUILzQ7iyi8EeI9b8MtpOpabfaTPpWpXEE9lLlGQA+vPjD+0T8Z4fiJp/w9+EWi+ArK 70b9qvwN8FNe1DxtqWrvba/4c8T/ALNrfG+SWGHS9CvptIuRql5Do8ssL3Eq2emrPBIsmpSLYXX+ PvjGx+JvxG+E/gPwzaa38TNd/aPPw+0ybxx478Qz+A/Dui6D+yV8EfjH4u8bRWkWj32o6P4e0t/F mmeG9L+HPhtIR4h8a66fEl3rGgQa/wCJtU0b8OfC3x++L9//AME2v2iP2xL3xre3f7Rtn+2N8FPH lj8RLjT9FlFh4ohsPg18CEvLDwg+mnwHY2X/AAqq5uvDEmh2nheHQZnvL3xBLpj+J7261qb69/ar +IXjD4a/sz/tNftMeCNZfQfjh8PP2qfgH4v8IeOoLLTrqbTNd+If7IH7JHw18ZyzaFqFnd+F9X07 XvBvi/XNOudB1rRNR0CG8k0zX7PTLfxF4f8AD+raWAffd1+1R8ZJta8LfCnR/hX4Bk+M1x+0d4j/ AGdPHtxf+Ptcj+GPhZ9I/Zwn/ac0r4k6JqEHg1vFPifT9b+H2peCYD4Il0jQ77TfGPiLUPC8/iuX SNAfxxqGT4k/bA+JPhvSYbHxJ4V+GPgDUvDfxL+I3wz+LPxe8XeIPGd38APAWpeDNK8I+JfCF7qW uaX4Wh1Hw9bfFTwt4103ULLUfiBe+DfBfgjWNK8R+FNQ8c+JNe/4Qm18e/Pf7Fer6j8RPhP+wL8b PGd0+u/FL41/HL43fEv4oeLp1jt7vxZ41j+Bnxt+HFtrFzZWKWulWCWHgTwT4S8J6ZpWkWGn6Npe h+HtLsdO061itUFfF3/BSv8AbA/aK/ZD1zUZv2ePiH/wr2T4i/tL/Ht/GR/4RLwN4tXWW8MfBf8A ZXbQyU8c+GfEyWH2E6xqX/ILWyFyLki7+0COERgH9JnhjUL7VvDXh7VNTOhnUtS0PSdQ1A+GNVm1 3w0b68sLe4uz4e1y4sdLn1nQzPJJ/ZOqz6Zp02o2H2e7ksbR5mt49yvAv2U9F0zw7+zD+zroei2i 2OlaZ8DvhVa2FmjzSR21ungfQ9kMbzySy+WmdqK0jbFARcKqge+0AFFFFABRRRQB/9k= --94eb2c0bda26132917054520b22d-- From nobody Mon Jan 2 12:27:53 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF808126B6D for ; Mon, 2 Jan 2017 12:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyh1CCmzFcB8 for ; Mon, 2 Jan 2017 12:27:49 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C76E1293FD for ; Mon, 2 Jan 2017 12:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v02KRk1A001116 for ; Mon, 2 Jan 2017 21:27:46 +0100 (CET) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tspXy02Z4z3Z6S for ; Mon, 2 Jan 2017 21:27:46 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id a197so371842853wmd.0 for ; Mon, 02 Jan 2017 12:27:45 -0800 (PST) X-Gm-Message-State: AIkVDXKkPfmpvHhZXZg4fNoPoXxo0vpiCIrBw2KJG1PR7AnDOSvZ4yF3wDVoX9eeHmp/yiHWXJi++yaFW5pQtg== X-Received: by 10.28.74.18 with SMTP id x18mr39348567wma.118.1483388865619; Mon, 02 Jan 2017 12:27:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.108.227 with HTTP; Mon, 2 Jan 2017 12:27:05 -0800 (PST) In-Reply-To: References: From: Klaus Hartke Date: Mon, 2 Jan 2017 21:27:05 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Tobias Kaupat Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] CoAP Observe over serial X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 20:27:53 -0000 Hi Tobias! Tobias Kaupat wrote: > CoAP by default restricts a Client to have 1 open interaction at the time. Would you also recommend this for Observes? > Due to simplicity I implemented it the way, that there can be only one Interaction, which means I can not do any request als long as the observe is running. > > Another implication is, that I can not observe 2 resources at a time. But since I need to be able to send requests while observing, what would be a good alternative? The limits are placed by congestion control and apply to communication over the Internet. If both client and server and the network in-between are under your control, you are free to choose whatever limits make sense for your application and hardware. > I guess implementing parallel transactions would be nice in any case. Yes :-) Ignoring message IDs and tokens and just assuming that all messages belong to the only interaction you started is not a good idea anyway. > Since we have no concept of connections or ports, mapping from CoAP messages to Interactions must fully rely on MessageID and Token? Or do all server responses carry the Token? All responses (including notifications) carry the token of the request. All acknowledgement and reset messages carry the message ID of the confirmable message, but do not always carry a token. I haven't followed the CoAP-over-serial topic; are you doing acknowledgements and retransmissions over serial? If not, then checking the token is all you need. > I'm also a bit afraid of loosing resource updates. For some resources I must be sure not to loose any update. Maybe that's a reason for pub/sub over observe? Observe follows a best-effort approach. If the resource state does not change more frequently than you can send notifications (and there are no proxies involved), then you should receive one notification for each resource state change. If the resource state however does change more frequently, then it is not possible that the client receives a notification for each state change without delay. Observe addresses this problem by sending only the latest resource state to the client. If a resource changes and then changes again, it is permissible that the server sends a notification only for the later change. This means that all important information needs to be in the representation of the resource state. The information is not lost when a notification is lost -- it just reaches the client a little bit later. Only if the server runs out of storage for new resource state, it must throw (for example) sensor readings away or start making fewer sensor readings. Pub/sub systems usually address the problem by not accepting new messages when the message queue is full. In this case, a publisher can buffer messages until the queue becomes less full. Again, the information is not lost, it just reaches the subscriber a little bit later. Only if the publisher runs out of storage for new messages, it must throw sensor readings away or start making fewer sensor readings. Long story short: You must write code that deals with the case that not all updates can be sent and code that deals with the case that not all updates are received. If you like it or not. Klaus From nobody Tue Jan 3 05:17:31 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12426128B38; Tue, 3 Jan 2017 05:17:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148344945005.28048.5285867090118455665.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 05:17:30 -0800 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm Subject: [core] core - New Meeting Session Request for IETF 98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 13:17:30 -0000 A new meeting session request has just been submitted by Jaime Jimenez, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Jaime Jimenez Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: artarea dispatch t2trg ace lpwan 6lo roll detnet Second Priority: quic dnssd saag irtfopen 6tisch netconf netmod sacm Third Priority: lwig httpbis v6ops opsarea cfrg icnrg homenet Special Requests: If CBOR WG is already set, it shouldn't conflict with CoRE. Please also avoid any IoT related BOFs that might come up. *Preferred* pairing: Tue/Thu or other space between; Friday is no problem. --------------------------------------------------------- From nobody Tue Jan 3 11:53:24 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57CA129B5A for ; Tue, 3 Jan 2017 11:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.1, 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 5KngZoK3uKtt for ; Tue, 3 Jan 2017 11:53:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45420129B5B for ; Tue, 3 Jan 2017 11:52:54 -0800 (PST) Received: from [192.168.91.167] ([80.92.115.195]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MfRnb-1cA1US1IGx-00P5v8; Tue, 03 Jan 2017 20:52:47 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 3 Jan 2017 20:52:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="109IdsKkh2uWfUk2HsswPKvh9uhXsd7HC" X-Provags-ID: V03:K0:KR5YGdf8+w73+KTgIBxe7af45eI/QUFYEMa8OOBQm2u10VahKjJ IthwUwmVTkYbG1vcRSZJcTamBTCyaFI7T0PH5UDm5Q15Cij6tLENysTdN3qRbqI2gxRermv YZLgXQeSu5zU+voJ+rTCjTBG6Gdp+wK9VzIabU1hCKENa07Psao/E5iaoMVoAvamkw69KoS cKXnby9KULyAE6jvsm5kw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q3nf8diES/k=:xu6nuP/u1N/HPmU0c+9G1o scU4KfYMnX4sdjhzgvEZKasn6zIrSbHGt1edacbyFcCARTGArS5VLVSoXHofD2J1qs1MyRe74 xMFehiYkHvjO+c5W+ou85CTRDbVpu8XdM1MP8GSmvNN9prHIm4GjhC+ghwTyK6pUDfy0O1QmY Rgb5AsUIxKxZKAEV2ahp/BjY+cOkTqyEYdntWMAkqOfGHAO3vCAlUIrVUhyMktb+eljEbgaHQ dXe6Ih1f5juzxclBuA5GXOGcfqKUbpqh/+9OF5+TQZuXlrAriC0lhpyS+WmVrWFh06Ev4lTX9 Sz97te3galeWm8veVhtXUkKa/z+JZrfSsrpwZcDciRwcTAq3dYY2av1sjqpJ8EU6lGqu+GFt+ qGH4FbwDuDPUUXnv8hBe6gmtarL2H2vnlXwBrjn5toYmFFyx/HkQl3h120o7MYLt4wkpflMAs QXOzg/LxVZBBc5s+Zxwxn9MlmG+GNe04rVEaLp+87NfkQFV1aWIqtQWnM7599FN4I3xeg5ODi +XUBR6CcB+VRWLfb48Zpm/AYR3oN0WawZGSonWa8koQb4gnR73+zDPxDHQh5mzoC4VsKXnBCQ xDOI1nvIoVZQlQNAtO6MHzrK88c6WPWnNrgVUVpALUcoC6axw26aKw1CMwLWl7KMnVvdZvyJ5 jnKR+VIQ86rBuYCIwK1lW8R/m6Et6YkWOvLiKTaOM4STjSptIP1xvkqZf09FvgYVukvoYJbzo H8KKnjzGCZ0tpHVkNMGW6UFmeblyHvPKDrQYKOIJS0y40/zXvdGBhz8s8o5+ZuQ4pgMqdXuK2 lZ1pQwbuALXAIAhzgwtaF+ycSjscIkdoftjw7PbR3MsJwsfi3V02xE7jKOGOxhOKdRXqUKwLU 25usslf3HZrbUYrmfT6RNI86LQdmcTl0mmI/MOkjUz53dpXuJC6kdf/kvphcXwEXNTYPuq2Wn Hb7WNR2bE1QFNi6wlUD/Qo55eIKDDFqtD3BSHp/QYhQnKPAmHKqom4Ft1k7oO89L8f7FkWRV4 ZprNuDRAh+RDPgtA4akU3ozK51dsmnSavbkC0QhsIAO6 Archived-At: Subject: [core] draft-ietf-core-dynlink -- New Use Case X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:53:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --109IdsKkh2uWfUk2HsswPKvh9uhXsd7HC Content-Type: multipart/mixed; boundary="DipoSShjqs274hddmwwODXNNxPm4xGEDN"; protected-headers="v1" From: Hannes Tschofenig To: "core@ietf.org WG" Cc: Friedhelm Rodermund Message-ID: Subject: draft-ietf-core-dynlink -- New Use Case --DipoSShjqs274hddmwwODXNNxPm4xGEDN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, Hi all, Friedhelm and I had recently been wondering about the following use case and whether others in the group also see it as worthwhile to include in the core-dynlink draft. Here is the story: core-dynlink describes attributes to reduce the amount of notifications that are sent to an observer. The approach is quite simple: The observer expresses interest in a resource and conveys the attributes, such as pmin, pmax, to rate limit notifications. When the resource changes then the subject, as RFC 7641 calls it, sends the current value of the resource. This is very useful functionality. However, imagine that you want to obtain data about many different resources and you utilize a data model (like in LWM2M) where resources are organized in a hierarchical fashion. For example, you may want to obtain a set of resources if the value of one of the resources changes. To be more specific, imagine a system that convey data during an alarms in an industrial facility: once a high temperature alarm is triggered the system will most likely want a snapshot of the system state (to quickly perform an analysis). What do you think? Ciao Hannes --DipoSShjqs274hddmwwODXNNxPm4xGEDN-- --109IdsKkh2uWfUk2HsswPKvh9uhXsd7HC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYbAEMAAoJEGhJURNOOiAthCMH/RdRLfua35+rLK0leGkugR/M J8Ho2o/x+U2qC3jVwtEIFCFtQiB2nkOM1LXXBYrnUMuQiKVQs3ddlIMMXcrHP+gE 6WiVOzouTJ77fFTEr6KLtWEyAl4WvO2UPi7TgYly/PfxpLrilPTsChc9mONDRUQN ThDef3O4/Lmw1tJ21tIYtvkMIpzwQWgHS8fJRvsjKlDN8+KP7WNEagVH4cKa48MF bT9k1NErTZQwOpJvI+jYsYG1dA89JQzM0ZSSnYs+T2RCOPmp6N79HSBNzJ5jRYwZ a7/DxbOLdnCgAYVR6rwPgZCXp8+APwzKXhUls16Ouz8n6M2mKnLsuEG0r5u/Xaw= =EEEz -----END PGP SIGNATURE----- --109IdsKkh2uWfUk2HsswPKvh9uhXsd7HC-- From nobody Wed Jan 4 01:12:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1612129C79; Wed, 4 Jan 2017 01:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmoiKLJd5ZgX; Wed, 4 Jan 2017 01:12:38 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA8B129C51; Wed, 4 Jan 2017 01:12:34 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 43BB145D95; Wed, 4 Jan 2017 10:12:32 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4F34D3F; Wed, 4 Jan 2017 10:12:31 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 948773B1; Wed, 4 Jan 2017 10:12:30 +0100 (CET) Received: (nullmailer pid 2232 invoked by uid 1000); Wed, 04 Jan 2017 09:12:29 -0000 Date: Wed, 4 Jan 2017 10:12:29 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-object-security@ietf.org, core@ietf.org Message-ID: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gvmj7cmcsptrcyj3" Content-Disposition: inline User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Subject: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 09:12:40 -0000 --gvmj7cmcsptrcyj3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello OSCOAP authors, getting familiar enough with OSCOAP to start an implementation, there are some areas which are not fully clear to me from reading the draft: * At least master secret and CID are preconfigured (that's assuming default algorithm, sender/receiver ID). It's out of scope for this spec, but are there any other drafts on how those should be rolled out / rolled over? * btw, why is algorithm a "SHALL" be pre-established (3.2) and the role IDs a "MAY" be predefined, if (as I understand) absence of pre-definition in both cases means fallback to defaults? * speaking of "role IDs" to subsume sender and recipient ID, it strikes me as odd that sender and recipient contexts are qualitatively different (the former has a sequence number, the latter a replay window in 3.1), but the roles of Sender and Recipient in terms of used IDs stay the same when roles flip mid-conversation. Does that mean that once my server starts "asking back", it grows a recipient sequence number, and the former client grows a sender replay window? * The option numbers are "to be done". Is there one that's already in use in first implementations? Could we pick one now and hope that all concurrent drafts become aware of its use so it stays stable, and if not just change it when going from draft to RFC? Or agree on one to use from the experimenal range until RFC release? * Replay protection: The sequence numbers follow DTLS' anti-replay mechanisms, where DTLS sessions are (to my limited knowledge) more or less ephemeral. When a device with a precommissioned context encounters a factory reset condition, or any kind of mis-match happens between =20 * the static context memory area of the keys, * the frequently modified window position possibly kept in log flash area, and * the bitfield inside the window (which I'd very much prefer not to commit to flash memory in embedded devices), =20 is there any way to recover from such a situation, eg roughly by the recipient saying "I've heard all that, start at N or I can't trust you at all"? =20 It might well be a bad idea to allow such a thing (at very least, that information needs to be authenticated), so right now this is primarily a question about whether there is a mechanism I missed, and whether there should be guidance considering the embedded use cases. Could you help clarify these issues? Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --gvmj7cmcsptrcyj3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhsvHoACgkQOY0REtOk veGAVQ//XkKSh0PxAWVQ3aylYWzCO52BjNZgSdOH6dnUkwBUKy4Dd1oLebdKy4qy 6zyMTR/TxGfUdMIAl1XWnu3MsqzRFrx+nBAOcluYznLa2GsrX7kCZazPucTEeauS zZJx+jbPETcpJwYKvEEWd5drAPCt8CNG2DGMN0PFRdW1wPwQqVRn06oiElYvzfFh Gtr7qC8Pm4IjsO4ApWMjD1lZONYL1NW4bmU8O+/7vMYnNvOtZ2Bf7vpB2+MLSxEL PGZSItCjjTWncUzq46HPMhU/4VNZRyWRJshpWN/bjv6IUsbSWeziVYzz9g16JQr8 9YGuMi0WIN9Hj43sP/FdrDvG02KAjMGtzZr0js9Z+nS+4dq/wlGVwpnBGgRf9o4v eJs627mRs3TwphQMAjhR/5yk7uosnGT2pYaA4RTvO1tjtmkiQ0lSnD1BGXmmCP9O H1MJhMp0azwrYl8sJ+ucHFWMysKnVNYcVEDm1L+jv9YAOLPQKPEQb7qCvDB1Lzlz zZHpQih8u4ZN3h3n9NOOGSaNjZCcdJK9wPrSpYGud9vHLfgDFy0BjJe6V8oc6GO2 ZBCCf2ODJckQuP33dR89yBZUiWQB46KLX2QP7spB9f7Zt6NbRpG66v8+RBP80fIe TZI65ORxKRJx9HDrlugEs9xTT/Ip+pl6j6i9TPNoq9o4oUncEE4= =NG3t -----END PGP SIGNATURE----- --gvmj7cmcsptrcyj3-- From nobody Wed Jan 4 02:22:22 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3303812943F for ; Wed, 4 Jan 2017 02:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lobaro.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ygI-v9nwAp for ; Wed, 4 Jan 2017 02:22:19 -0800 (PST) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [198.143.161.10]) (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 79F7C128DF6 for ; Wed, 4 Jan 2017 02:22:19 -0800 (PST) Received: from ns1.am20.siteground.biz ([107.6.152.202] helo=am20.siteground.biz) by se8.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1cOii0-0003Dv-9j for core@ietf.org; Wed, 04 Jan 2017 04:22:18 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lobaro.de; s=dkim; h=Content-Type:To:Subject:Message-ID:Date:From:References: In-Reply-To:MIME-Version; bh=GIUK/bkfL2zQx4t3lmrHGxGZH+CXrl9Sf54m8JfoADk=; b= dsCw2rfD1VYNtG4wGoKUz+UuajszgPPOSD4bZM1xZduMgKqUPUQRR2juHBsv/d92HbDlPcB/F4/JI xWp9t3jZx7/O6zCXCkIww6P03WAO0KgW7lr2IyCUHIVu9bb8ZKEKn6czRoAO2Dv4gzClphsdMFwhz gLTzyqsLe6mBS9eiA=; Received: from [209.85.161.174] (port=33976 helo=mail-yw0-f174.google.com) by am20.siteground.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1cOihy-0007k4-QZ for core@ietf.org; Wed, 04 Jan 2017 11:22:15 +0100 Received: by mail-yw0-f174.google.com with SMTP id t125so310647848ywc.1 for ; Wed, 04 Jan 2017 02:22:14 -0800 (PST) X-Gm-Message-State: AIkVDXIYycPLsiYcTSQKOb5xGwRPGjNdOGA4AJihFkKyIC2vEdOvR9Sf/2uEvWdc8LYEQipRwQWYs6u4QX7rDQ== X-Received: by 10.129.153.5 with SMTP id q5mr61289448ywg.256.1483525333843; Wed, 04 Jan 2017 02:22:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.173.40 with HTTP; Wed, 4 Jan 2017 02:22:13 -0800 (PST) In-Reply-To: References: From: Tobias Kaupat Date: Wed, 4 Jan 2017 11:22:13 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "core@ietf.org WG" Content-Type: multipart/related; boundary=94eb2c0bda268a23440545422840 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - am20.siteground.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lobaro.de X-Get-Message-Sender-Via: am20.siteground.biz: none X-Originating-IP: 107.6.152.202 X-SpamExperts-Domain: am20.siteground.biz X-SpamExperts-Username: 107.6.152.202 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=107.6.152.202@am20.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Filter-ID: s0sct1PQhAABKnZB5plbIdH40z9tliyPtpXyyHKT/m4RjSEj2nYPqqWQeUf53awN/bPom7IVowNb jNmNSGjlJJS31NqWy1r8mVG8NckVYvJ4fwnza0AjOF3X1ZlT7L/Ft4lP0GR8jfSinTz1pajzuyEb xxLK3QENjMlUnGz2Ts9rCcUrLhB+ReWoBzACTeUoZ4lTHaimKzOBSrygmkvqE0xA26j720POqpBf yrgRuwlm4zuNRcgRKiGg7nXFaZTx//tFQAs3zDmNrc3GnFYNqhjZPju8Yrl97OtSGugEjk4URvWx 0knMZb70Q77PCeyNejx+ZEH83D3uT7G9vVxSoDnlKnN5EY5Xdpjv88dVSAvrjuU3A3io6xJmD59i FVkbFIc8h94caA+NPqtxRqOTvif6OC2JfWwXCnj8ISEr5W3HklYpi9OIsJtKHR01fXKwPSDt2dCZ M7GpMC1nWutm/4713u8sUg7qYoWrd2yUM98XKu1VbgppFJRGoXLED7mHiE8E38RbdBtd0b9yL+aO NlaplafOirH+W3GOYf6wZShQJdtkddTPDvOO+kGbv+2L7T4KHkElZ0N/loOxgoJTC2eupYYdzPm7 YfRDaULOU2kSpt+d87cfMcGsNXCp7ARssXBCClSYNCe3q3XFvJn9q3McN6qoXPjenLhIOF1oeRbl FolXNjXru7lO2xnmeuKojzO38TXRVBLrvQ73AoV0obigX209HSiG8x/Tn0w5W7LcjS5E9AV2NsX6 VLjvFnXJB22niq1/gWQDVBnGJw2WMseOVuodnLVvldfhMjBky8VSLaTZh1EReo2BAQ7GpEsP4jX2 BkfNHJBioY9NgVkMhVNT/sjdakyzO5YcNFZ1BaY= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com X-Recommended-Action: accept Archived-At: Subject: Re: [core] CoAP Observe over serial X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 10:22:21 -0000 --94eb2c0bda268a23440545422840 Content-Type: multipart/alternative; boundary=94eb2c0bda268a2342054542283f --94eb2c0bda268a2342054542283f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks that helped a lot. I just implemented the interaction concept to handle parallel requests. One open question, more to CoAP than to observe, but related to my interactions: In the case of "A GET Request with a Separate Response". *How long should the client wait for the separate response after the ACK?* I need some timeout to close my interaction. I would take some reasonable default value like 10 seconds but can not find anything in the RFC - or did I missed it? There might be cases where it would be nice to have a hint from the server (e.g. in an option in the Ack) and there might be cases where the client can decide per Endpoint how long to wait. Are there already opinions on this issue? Regards, Tobias On Mon, Jan 2, 2017 at 9:27 PM, Klaus Hartke wrote: > Hi Tobias! > > Tobias Kaupat wrote: > > CoAP by default restricts a Client to have 1 open interaction at the > time. Would you also recommend this for Observes? > > Due to simplicity I implemented it the way, that there can be only one > Interaction, which means I can not do any request als long as the observe > is running. > > > > Another implication is, that I can not observe 2 resources at a time. > But since I need to be able to send requests while observing, what would = be > a good alternative? > > The limits are placed by congestion control and apply to communication > over the Internet. If both client and server and the network > in-between are under your control, you are free to choose whatever > limits make sense for your application and hardware. > > > I guess implementing parallel transactions would be nice in any case. > > Yes :-) Ignoring message IDs and tokens and just assuming that all > messages belong to the only interaction you started is not a good idea > anyway. > > > Since we have no concept of connections or ports, mapping from CoAP > messages to Interactions must fully rely on MessageID and Token? Or do al= l > server responses carry the Token? > > All responses (including notifications) carry the token of the > request. All acknowledgement and reset messages carry the message ID > of the confirmable message, but do not always carry a token. > > I haven't followed the CoAP-over-serial topic; are you doing > acknowledgements and retransmissions over serial? If not, then > checking the token is all you need. > > > I'm also a bit afraid of loosing resource updates. For some resources I > must be sure not to loose any update. Maybe that's a reason for pub/sub > over observe? > > Observe follows a best-effort approach. If the resource state does not > change more frequently than you can send notifications (and there are > no proxies involved), then you should receive one notification for > each resource state change. If the resource state however does change > more frequently, then it is not possible that the client receives a > notification for each state change without delay. > > Observe addresses this problem by sending only the latest resource > state to the client. If a resource changes and then changes again, it > is permissible that the server sends a notification only for the later > change. This means that all important information needs to be in the > representation of the resource state. The information is not lost when > a notification is lost -- it just reaches the client a little bit > later. Only if the server runs out of storage for new resource state, > it must throw (for example) sensor readings away or start making fewer > sensor readings. > > Pub/sub systems usually address the problem by not accepting new > messages when the message queue is full. In this case, a publisher can > buffer messages until the queue becomes less full. Again, the > information is not lost, it just reaches the subscriber a little bit > later. Only if the publisher runs out of storage for new messages, it > must throw sensor readings away or start making fewer sensor readings. > > Long story short: You must write code that deals with the case that > not all updates can be sent and code that deals with the case that not > all updates are received. If you like it or not. > > Klaus > --=20 Lobaro UG (haftungsbeschr=C3=A4nkt) Tempowerkring 21d 21079 Hamburg 040 / 22816531-0 www.lobaro.de info@lobaro.de USt.-Identifikationsnr.: DE297198645 WEEE-Reg.-Nr. DE18824018 Gesch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde Sitz der Gesellschaft: Hamburg Handelsregister: HRB 134264 Amtsgericht Hamburg --94eb2c0bda268a2342054542283f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks that helped a lot. I just implemented the interacti= on concept to handle parallel requests.

One open questio= n, more to CoAP than to observe, but related to my interactions: In the cas= e of "A GET Reque= st with a Separate Response". How long should the client wait for t= he separate response after the ACK? I need some timeout to close my int= eraction. I would take some reasonable default value like 10 seconds but ca= n not find anything in the RFC - or did I missed it?

There might be cases= where it would be nice to have a hint from the server (e.g. in an option i= n the Ack) and there might be cases where the client can decide per Endpoin= t how long to wait. Are there already opinions=C2=A0on this issue?

Regard= s,
To= bias
=

On Mon, Jan 2, 2017 at 9:27 PM, Klaus Hartke <hartke@tzi.org> wrote:
Hi Tobias!

Tobias Kaupat wrote:
> CoAP by default restricts a Client to have 1 open interaction at the t= ime. Would you also recommend this for Observes?
> Due to simplicity I implemented it the way, that there can be only one= Interaction, which means I can not do any request als long as the observe = is running.
>
> Another implication is, that I can not observe 2 resources at a time. = But since I need to be able to send requests while observing, what would be= a good alternative?

The limits are placed by congestion control and apply to communicati= on
over the Internet. If both client and server and the network
in-between are under your control, you are free to choose whatever
limits make sense for your application and hardware.

> I guess implementing parallel transactions would be nice in any case.<= br>
Yes :-) Ignoring message IDs and tokens and just assuming that all messages belong to the only interaction you started is not a good idea
anyway.

> Since we have no concept of connections or ports, mapping from CoAP me= ssages to Interactions must fully rely on MessageID and Token? Or do all se= rver responses carry the Token?

All responses (including notifications) carry the token of the
request. All acknowledgement and reset messages carry the message ID
of the confirmable message, but do not always carry a token.

I haven't followed the CoAP-over-serial topic; are you doing
acknowledgements and retransmissions over serial? If not, then
checking the token is all you need.

> I'm also a bit afraid of loosing resource updates. For some resour= ces I must be sure not to loose any update. Maybe that's a reason for p= ub/sub over observe?

Observe follows a best-effort approach. If the resource state does n= ot
change more frequently than you can send notifications (and there are
no proxies involved), then you should receive one notification for
each resource state change. If the resource state however does change
more frequently, then it is not possible that the client receives a
notification for each state change without delay.

Observe addresses this problem by sending only the latest resource
state to the client. If a resource changes and then changes again, it
is permissible that the server sends a notification only for the later
change. This means that all important information needs to be in the
representation of the resource state. The information is not lost when
a notification is lost -- it just reaches the client a little bit
later. Only if the server runs out of storage for new resource state,
it must throw (for example) sensor readings away or start making fewer
sensor readings.

Pub/sub systems usually address the problem by not accepting new
messages when the message queue is full. In this case, a publisher can
buffer messages until the queue becomes less full. Again, the
information is not lost, it just reaches the subscriber a little bit
later. Only if the publisher runs out of storage for new messages, it
must throw sensor readings away or start making fewer sensor readings.

Long story short: You must write code that deals with the case that
not all updates can be sent and code that deals with the case that not
all updates are received. If you like it or not.

Klaus



--
3D""

= Lobaro UG (haftungsbeschr=C3=A4nkt)
Tempowerkring 21d
21079 Hamburg
=C2=A0=
=C2=A0
USt.-Identifikationsnr.: DE29719= 8645
WEEE-Reg.-Nr. DE18824018
=C2=A0
<= font size=3D"1">Gesch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde
Sitz = der Gesellschaft: Hamburg
Handelsregister: HRB 134264
Amtsgericht Ham= burg
--94eb2c0bda268a2342054542283f-- --94eb2c0bda268a23440545422840 Content-Type: image/jpeg; name="lobaro_logo.jpg" Content-Disposition: inline; filename="lobaro_logo.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 8457dcfce885091a_0.1 /9j/4AAQSkZJRgABAQECWAJYAAD/4QCKRXhpZgAATU0AKgAAAAgABwEaAAUAAAABAAAAYgEbAAUA AAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAQAAAAclEQAAEAAAABAQAAAFERAAQAAAABAABcRlES AAQAAAABAABcRgAAAAAACSe+AAAD6AAJJ74AAAPocGFpbnQubmV0IDQuMC45AP/bAEMAAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB Af/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAf/AABEIADsAyAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0 4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery 8/T19vf4+fr/2gAMAwEAAhEDEQA/AP64v+CQUss3/BKf/gm7LNJJLK/7Dn7LjPJK7SSO3/CmPB3L OxLMfckmv0Wr85f+CP3/ACij/wCCbf8A2Y3+y5/6pjwdX6NUAFFFfEf7Tf7RHxS8PfEHwF+zB+y3 4Y8H+Lv2mvih4e1nx3NrXxIbWG+EfwA+Dvh/UbPQ9X+MvxXsvDd1p/iTxN/aPiPULXwn8L/hboGr +HNa+KPiiPXFj8VeFPCvgvxt4r0AA+3KK/N5P2Pf2zL+L+19c/4KxftLWXi0gSnTvAP7PP7CXh74 Rw3H3nt7TwV40/Zn+JnxG/shnyq22o/GzU9Zjt8Rr4h88fajpfCL46ftB/CL45+FP2Vv2zLrwJ4z 1L4rad4kvv2Z/wBp/wCGXhnUPAPhb4yan4J0mfxF4x+EHxK+GWo694sX4bfHfQfB1nqHj3SD4e8U 6z4F+K/grQfG3iDw3ZeCNQ8Fa14QiAKvx/lkX/gpJ/wTojWR1jl+FP7eXmxqzBJNmh/s5snmKDtf Y3K7gdp5GDX6M1+MP/BR39oTQ/2Zv2zf+Ce/xI1Lw5rvjzxBd+BP2z/Anwz+F/hM2Y8YfFn4s+P0 /Zn8L/Dv4beFzqE0Gn22oeJvEeoWkN9rWpzQaH4T8Pw6z4w8SXVj4c8P6vfW3uGk/s6f8FBvivaw +KvjX+374g/Zx1rVEF6Pg9+xT8Hv2eb3wb4HWUboPD2ofFX9q/4MftB+MfijqOmrtj1Lxjpvhj4Q 6Xrt2JZ7HwFoFm0VoAD9LqK/Kbxp47/a/wD2BbSL4pfHP4y2X7ZP7HmlXVpH8ZvH+v8Awx8HfC79 pf8AZy8MXNxHa3Pxq1k/CLT/AA18IfjJ8IfB/mx6l8VdM0T4WfDDxr4B8Hwax8QNMu/Hdjot/wCG Yf1IvdY0nTdIu9f1DU9PsdCsNOn1i+1m7vLe30qz0m1tnvbnU7nUJZEtINPt7ON7qa8llW3itkad 5BGpYAGjRX5UeBvEf7aP7eGkW/xf+Gvxqk/Yd/ZS8Up/aPwQuPCnwp8C/ET9qn40eA7rLaH8Y/Ee ofHLQ/Gnwn+C/hDx3p4g8Q/Dz4dy/B3x744uPCOp6P4k8Z+JvCetalc+ANC6XWfgJ/wUO+C9nP4w +Cf7b2rftZXujRtf3PwL/bN+FvwB8L2Pj+1gHmXXhvwr8b/2WfhB8B9R+FfiPUEV49E8VeLfh78Y PDtjfNDDq/haTT5ZLyyAP0yorwn9mz9oDwl+058HvDHxe8I6drvh1NWuNf8AD3ivwN4ttYLDxt8M /iP4H8Qan4M+JXwv8c6bbXF3b2HjH4eeONC13wn4ghtLu806e+0t77R7/UdHu9P1C6/Ib9j/APbG /bP/AG7Ph1F8OfgN4z8DeGNb+GXi74oeGf2pf2yPiF8PrLxjZeE/F1v8V/HK+CPgP8EPhF4cvfAv hTxd8WtF+EqeBPEHjvxl4s1KLwR8N9H8R+DhqHhn4neMfEet6T4dAP3vor83Zv2QP20tJhOr+FP+ Cr37RWq+LkUyrpnxd/Z1/Yd8X/CG6uh80cGoeDPhj+zp8D/iUNID4je20f43aNq0luSra4bnF0PT f2WP2kPiH498WfEv9nb9pLwf4Y+Hf7U/wRsvDOveKrDwNfapffC74ufC7xtNrNn4E+PXwYuPEAHi GLwX4k1Xw14m8M+JfB3iCS+8S/C/x54c1jwprGreItJm8J+NfF4B9q0V8cftU/tG+OPhhq3wy+CP wB8FaF8Tf2pfj3N4m/4Vn4X8W6pf6L8PPA/gnwPHo7/En47/ABi1fSLe71uy+F3w2bxL4V0ubS/D 9tJ4m8d+OvGPgj4f6BJpc3iS78S+HvJIP2RP21tdhGs+Nv8Agqx8f9B8XSqJ5NH+BX7On7E/gn4P 2N23zyW+meEvjF+z7+0N8TpdIV/3UUGufGzWdT+zqP8AibLcs1xQB9hfH5viGvwb+IDfCv8AtX/h ORoTf2SfDyaTJ4rW0+1Ww8QP4Jj8QBvD0nj5PDf9rv4Cj8RK3h2TxiuiJrytpDXgP56f8Et0/aqg 0Lxdb/tA3XxbvtPj8P8Ag6W4uPi/F8XC4+Id1DdXetwfD+/+PFjovxV1LSrfTLi2tvF5v/DmheAN K1C38M6F4BbxZremfEr4heMfSPA/xo/aU/Zu+M3w4+A37Y3iHwT8XvAHxy1i88HfAH9rPwP4Nk+F 93cfFGz0bUvEtr8E/wBoT4bR614h8M+HvGXi7w9o2vX3wy+JvgPVdL8E+PtU0HUPBV/4E8A+Lbrw haeOP0joA+d7r/hIvjJ4u8VaJZ+Jdc8IfDDwHq3/AAi+pz+E7+TRvE/jzxfDZ2l9rdmviO3xqnh7 wt4cW+tdLlbQZbDWdX15NTi/ta0sdNEN9ZvvgYmhQPqfwn8Z+NfBfim1Uz2a61428Y+OvCGs3EY3 LY+KvDfjHXNdhubG75gudQ0d9K8QWyym5s9TWWMI8Xwz1S18FeO/iF8LdflTT9V13xp4k+JPgWa6 YQw+LvDni+ePWtYj0maTat3qvhbxFcarp2saZGWu7TTTo2pGM2d+ki+w+LPFvh3wPoGoeJ/FWq2u jaLpkRluby6fG5jxDa2sKhpry/u5NtvY2FpHNeXty8dtawyzSIjfKYTB5bjcHicfmbhLG062LWNx latKliMpqUKtS9DC4nnhUyyjhKSg6U8NOgq1Llxs5VZ4mder+AcP8PcFcTcOZ1xZxzLDVeJsHmfE seJuI8wzOpl+b+H+KyrMMYqmV5FnccTh8XwTl3D+X08K8BicmxGVQzLL1h+KMVVx2IznE5pjsb4Z +NT8QPBumeI5tPbRtUM+qaN4i0OSUTvofinw5ql5oHiXRzMoXz47DW9NvYLa5KRm7tFt7sRos4Ud 5X5eWXx/+Kn7JWr6r40/aa8E6ZpX7J3xd8Vat47tfjN4YtdTXVf2Vte8aapLeHwx+1ToM95qS2Xw 5v8AzbW9i+P3hoWnhX4e6rfX3hr4u+HvCnh/Sbf4o679QeKf2vPhRo3iS+8GeDrLx/8AG7xdpEVn P4g0P4FeBta+JcXheLULWK+09fFPifSI4/BPhu+v7GeC+sdH1nxPZ63eWM0N9babLZyxzt9Nw7hc 1zbL8C44bEYrGPAYfEYtxoOEoJwpqeIxUVGNPCKU5xdVVPZ06NWoqTadkfoHCPEdWlwDwbm/GWOj g81zLIMmnjKmZUoZdjcdmWIy6nXm55YqdGdDM8XGM8Xicpw+GVTB1XXw8aMY4eXL9R0V4H8Lf2k/ hl8V9f1HwTpsnijwd8SdH09dX1T4XfFDwf4h+HPxBt9GaZbca7Y+H/FFjYt4j8Oid4oJPEnhS413 QIbmaG1m1OO6lSEld2KweKwNZ4fGYethqyjGfs69OVOThNc1OpFSS56dSLUqdSN4VItShJxaZ9lg MywGa4ZYvLcZhsdhnOdP22FrQrQjVpS5atGbg37OtRmnCtRny1aU04VIRkml8w/8Efv+UUf/AATb /wCzG/2XP/VMeDq/Rqvzl/4I/f8AKKP/AIJt/wDZjf7Ln/qmPB1fo1XMdoV+cf7LGNd/bt/4Ki+K tSH2nWvDfxC/ZT+CWkXknzS2fw88Kfsq+A/jJo2gwO2Wjs7fx9+0J8T9cECbY/tfiC6mKmSR2P6O V+cf7IXy/tm/8FYkbh2/aX/Z1nVTwzQP+wP+y5AkwB5MbzWtzErj5TJBMgO6NwAD9HK/OT/gqAq6 V8BPhB8Q7NRH4n+F37eX/BOnxD4S1AfLLYXXjP8Abe+BPwW8XxRyD544/EXwu+Kvj/wdqJjZWl0j xJqFuSUmdW/Ruvzn/wCCqALfsoeH4lBaWf8AbY/4JhQQRqCXmmk/4KYfsjrHFEgyzyOeERQWY8AE 0Acb+1P4I8O+Lv8Agp1/wSr1bXtPgv7v4deF/wBvnxv4XaeNZVsPET/DT4PeCl1CNXBUTw6J4z1u KCTG6GWdZoyskaMv6lV+cH7QciJ/wUp/4Jwq7qrS/Cz9vaOJWIBkceHv2dpSiA8swjjkkKjJ2I7d FJH6P0AYfifw3oXjPw14h8H+KNMtdb8M+K9D1bw14i0a/iE1jq+ha7YXGl6vpl5C3yy2t/p91cWt xG3Dwyup4Nfj78BPhr8T/wBrr/ghZ8D/AILaJ4xsrHx18Zf2IvhZ8H9Y8ZeKtQ1a0W/8MX/hLQPA fjy81bVdGsNT1ZNb8SfD238QQG/s7N5X17U0uGe1jZ7iD9nq/A/4YfE/xn8IP+DeH4b+Pfhvq8vh zx9/wxJ4K8PeAvFsGTJ4R8TfEyz0vwF4W8eW+GVZB4R1DxbY+L7diwglTS0Z28hy1AH2Tc/tnfEv 4g+I/Efw5/YE/ZZsf2gPDfwu1vUPhz4m+NvxD+K9j+zf+ypovi7wlcvoOu/D/wAB+NdM+H/xh+In xQ1TwJqFjd6B4rufhl8F9b+HnhrXdNvPB9x46TxVpWs6FpVPW/2sf23fgVZzeLf2pP2GPCmo/CXS ozeeLviJ+xL+0R4h/ae8QeA9EQFr3xN4i+CvxE/Z6/Zr+JfiDQdEiButZh+EVn8VfGS6ek95pvgv UhbzRL92fB/4T+BfgR8Kvh38F/hjokHhz4ffC3wb4e8CeD9GgCkWWg+GtMt9L09Z5QqNd300NsLn UtQmButR1Ca5v7uSW6uZpG9HoA/Lf9gLxx4M8X/tE/8ABR+++FHiXRfFfwd8b/Gr9nf49eAta8M3 9vqfhfVT8bP2NfgTf654i8NXto8ltLpHjGbwxZeMJWtn8m713Xdb1dh9r1W7d2/8EafA/h3wP+wP 4Gi8PafBZP4p+Mn7WfjjxBcRxotxq3iPxN+1d8Z7y+1C+lUB7meO3Wy0u2klLPDpem6fZKRDaRKv mf8AwTQ+B3hr9nn9sL/gr38PfBD/AGfwNd/tQ/Br4h+FfDqSs1n4Nh+K37OXgj4k+I/C+kWgbyNI 0Cy8c+KfFd54e0Oxjt9O0bRNQsNPsLaC0t4o196/4JM/8mG/Cb/sdv2kP/Wn/jLQB+jlfKHxB+An ibxB+2B+zb+0r4V1TQNJsPhh8L/2hvhD8UbO7m1GHXfF/gv4uT/CjxR4X0/TYbTTrjT9QHhrx98K dL1ffrF/YNpNpqGr/wBkGeTV9Rt5vq+igD84vhIB4i/4KmftrazqwF1d/Df9kv8AYd8A+DDJyuha J418c/td+OfGn2FekNx4s1nT/Cv9uSrze2/gvwvFJxpkVfo7X5x/An5f+CnH/BQ5G4dv2fv+Ce86 qeGaB7v9sSBJgDyY3mtbmJXHymSCZAd0bgfo5QB+c3/BWSNbb9gf43eLoB5Wv/Cu9+E/xp8Fainy 3Wi+Pvg38Z/h78S/BOs2U64lt7iw8SeGNOkZ4mRpbY3FrIWguJo3/Rmvzq/4K1c/8E5P2r0HLy/D q3giX+KSe48VeHYIIUHVpZppI4okGWkkdUUFmAP6K0Acv4t8E+EvHmljRvGPh7S/EOnJPHdwQalb JM9neRZ8m+0+5G2602/hyfJvrCe3u4dzeXMu45+Dv2F/C2h+L9J+MXjHxfaS+LvE3w+/bB/au+HH gjWPFV/qPiO68K+Dfhz8a/FnhLwXpOh/21d30WnyaH4d02y0yPVbeNNZvIoTLqOoXlzLNNJrSaLr v7ZXxT+Kuk+IPF3i/wALfsw/BPxpc/CiPwX4C8Ta14H1n45/E7QtP068+IOq+OPGPhi90vxXa/DX wVqGqp4H0nwV4f1fSYvFHiXSfFGp+LLrUNHtdG0h9bUv2BPhL4Q0+61n9mG61/8AZh+KVo9xqWh+ MPh54h8SS+G9S1lma58j4m/DbVdZvfBPxL8Pate7D4htfEOkSa7PE01xo3iDRdX8rUovGq4TB4uu sc8nwGLqUpJU8XXpUHjH9Xm+WWHlUw83aE1J0JTxFFN+9FxhKM39fmngf4Of2zlWI8RMbkuF8Rqm EybHQxtTwyyzijCcKvF0KOZZHh+I+Laua4biLLsbl1LE4fG5nhuG+GuJa/D/ALZ4enDE57hsflGD 9o/a18d6p8Mv2X/2gfH+h29nc614T+EHj/WNIj1G1ivdMXU7bw1qH2G41SzuI5re70u0umiutStp 4nhnsYbiKVfLdq6H9n74HfD/APZv+D3gL4MfDLRdO0Xwn4H8P6fpNsmnWVtZf2rfRW0S6n4gv0tU SKXVNdvhNqWoT4w09wUjCQRwxJ+d+n/FH9qb9v3wRr/wR8O+Abf9mjwHZr4q+DH7XPx18T2nh7xh qeoeMtFmv/BvxZ+E37Jvw+1k61putxy3MWpWF78b/jHpTeEPCVpfW+neHfhz8V/EKa5L4M+iPBvj j47fs26LYfDD4m/CX4lfHrwh4UtYdE8A/HD4QW/h7xT4h13wtp6La6FY/Fn4fahrugeKNL8eadps dvY6t4j8K2Xinwx4qntm16WXw3eX82i2/wBxl3/CpkX1LAVqMMT9fWPrYatXo4WeZYaphaVLBuk8 ROlCrWyyosX/ALJz/WZLNJzoUakaWJlS/M+MMqxvAviBmNDijBV1LKcPjOF6mIwdGpmtDIc3y7Ns T/bEZ1cuhirYLPIwwDp5tRU8snHIaPtsXT+tYD6zt/t4aXaaT8Bdf+OWmxJZ/Ej9msp8Z/hv4ht1 Eeq2moeF5re68ReFIrlcSzaJ8SvC8eqeBPEmiuz2erWGtJ5sDXlnp89sVia7YfFn9rbUfD3hvxN8 L/EvwP8A2b9G8SaB4t8ZWnxHu/D8fxU+NV14U1a01/w94KtvCHhfWvEdt4G+HD+ItM0/U/GN/wCJ 9Zh8WeKbCwi8L23hfStJ1TU9Ucr7/hvP+EOGcsjlvGPDlHizHfWK2IwsaGNoVo5PhKqpXwUsRTqT oupWrxr4uphaNScMNKs3V5MXWxNKn+Jca8JeInG+eSzvw34zxPAGV/VMPhMfPFZbi8NU4kx+HlVa zSGDrUKddUcNhJ4fLqOPxFKlUx9PDpUVVy/DYHEVvDP+CRvxg+Eulf8ABLH/AIJzaZqnxR+HWm6l p/7En7Mdnf6ff+NvDVnfWN5bfBzwhDcWl3aXGpxz21zbyo8U0E0aSxSKySKrKQP0P/4Xf8F/+ivf C/8A8L/wp/8ALavB2/4J0/8ABPl2Z3/YT/Y3Z2YszN+zD8E2ZmY5ZmY+CCSxJJJJyTyab/w7n/4J 7/8ARiP7Gv8A4jB8Ev8A5h6/IT+ij6a8O/EPwB4vu5rDwn458H+KL+3tzeXFl4d8TaLrd3BaLLFC 11Nbabe3M0Vus00MRndFiEssUZbdIoP53fHPV9S/Yn/ap179sK88O+JNf/Ze/aB+Hngj4d/tV6j4 P0HVvFer/An4g/CK68Rf8Ko/aL1XwtoFpqXiHVPhj4g8G+LtX+GPxs1vRNP1C68BWvg74ReML/TY /BWn+P8AxDoP2J8Kv2Uv2XPgTr994r+CH7NnwC+DfijU9Hm8Pal4k+FXwd+Hnw81/UNAub2w1K40 O+1jwj4d0jUbvR59R0vTL+bTJ7mSylvdOsLp4GntLeSP32gD5z8PfthfsleLfB8PxC8L/tQfs8+I fAc9mNRi8Z6N8aPhzqPhZrFoxL9qOvWviSXTEgWM7nd7lRGM79pBA+JNQ+KPh7/gpD8c/gp4d+A1 3/wnP7G37NvxW0X4+/Fz9oXSo5ZPhf8AGn4yfC+S6vPgZ8Ffgh4odP7L+KmkeCPiU+lfGv4n/Enw ZJq3gjw9rPw18CeAtM8Rar4g8ReKbPwp9p67+xj+x74o8Vy+PPE37KH7NfiLxxPdm/m8Z678Cvhf q/iua+aTzWvZfEWoeFrjV5LsykyG4a8MxkO8vu5r6NtbW2sba3srK2gs7OzgitbS0tYY7e2tba3j WKC3t4IlSKCCGJFjiiiRY441VEUKAAAfh1/wVF0746Qftu/8EwfiP+znpp8W/E/4IWP7aPxZh+FP 22x0s/G7wZpfhP4IeF/ib8IrHVtVuLbSNI8V+K/hz4t8USfDjU9amh0Kz+J+m+C5ddutP0cX2pWf 6E/Bf9vv9kH476VPdeDPjt4C0nxPpDfY/G3wq+Imu2Hwz+NXww16JFa/8LfFL4Q+OLjQ/H/gHxJp khMV3p3iLQrIShReafNfabPa3s/1Vd+HfD9/rWj+JL7QtGvfEXh221az8P6/d6XZXOtaFaa8tiuu 2uj6rNA99pltrS6Zpq6tBZTwRaiun2IvFmFpB5flnxS/Zp/Zy+ON1Z33xr/Z/wDgn8YL7T4lgsLz 4pfCrwJ8QLqxhRmdIbO48WaDq81tErszLHC6IrMzAAkmgD4n/aU/bZ8O/FHT/E37J/7CPxC8L/Gn 9rb4kaVceCxrnww1Wy8e+Bv2T9E8Twy6VrXx8+PvjDwzdXvhrwNB8PdIuLzxH4J+Hms6xZePPi14 ws9B8J+E9CnstQ1jX9B+l/Ev7Hnwn179im//AGELWHUdF+DMn7OMX7M2ivZTL/b3hzwVpvw+h+Hn hzVtLvUWAReJPDdhaafq2lajGsLwa3p9tfR+XJGpX33wN8PfAPww8PW3hL4a+B/B/wAPPClk7yWf hnwN4Z0Xwl4etJJAoke20XQLLT9NgeQIgdorZWYIoYnaMdhQB+aP7On7enhPSIdE/Zy/be8aeC/2 ff20vA+mw+HfGHhz4i6xp/w/8I/H59CSLTf+F6/s1+IfE02l6F8TPht8RUii8Uf2L4X1DUvFnwu1 DVLnwH8RNH0TX9GY3nsPxr/4KBfsk/Ayxt4dd+MnhLxt8QdcLWngD4G/CLV9M+Knx7+K2vvGxsfD Pw0+Efgy91Txh4n1W/mEcBu4tPt/D+ixy/2p4n1vQtDt7zVLb6W8f/DP4b/FjQJPCnxT+H3gj4l+ FppVnm8NeP8AwpoPjLQJZ0VkSaTRvEVhqWnPKiO6rI1sXVXZQQGIPI/Cz9nT9nz4GPev8E/gT8Gv g8+pR+TqL/Cz4YeCfh89/DvWTyr1vCWh6QbqPzEWTZOZF3qrY3AGgD8qv+CTmhfG/Tv2jP8AgqT4 m/aOSy034z/FL49fAT4qeLvBmmahb6xp/wALLHxl+zX4IuvA3weg12zLWXiK7+E3w6g8I+ANe8Ta ex0vxL4l8P6zr2kCPSdRso0+nv8Agkz/AMmG/Cb/ALHb9pD/ANaf+MtfoHYeHfD+lapruuaXoWja brXiiewuvE2sWGl2VnqniK50rT4NJ0y413ULeCO71efTtKtrfTLCbUJriSz0+3gsrdo7aKONTQPD vh/wppUGheFtC0bw1olrLez2ujaBpdlo2lW0+pX1zqmozQafp0FtaQy6hqd7eajeyRwq91fXdzdz mS4nlkcA2aKKKAPzU/aeh8Ufsw/tK+FP28PDfg/xZ48+FOt/Ci0/Z3/bI8NfD/QNU8XeO/Dvw58K +K9f8ffA/wDaB8PeCtAtrvxF43034I+KPHHxY0L4jeGPDOn6x4sk8AfF3UPGehaVqR+Hlzo+rfSv gb9s79kT4m+EYPH3w/8A2of2fvF/gye2+1f8JHofxf8AAN9pdtGF3Sx6jPHrx/su7tCGiv7HUhaX un3EcttfW9vcRSxJ9LV85eMv2PP2R/iL4pl8cfEH9ln9nLx341nuPtc/jDxl8EPhn4n8UzXW7f8A aZfEGt+GL7VpLjd83nPdmTdzuzQB8MfFD4xeDv8AgpH468A/s3fs06zZ/FP9mvwV8WvAXxR/a7/a N8JTLrHwXvNP+CXjLSPiP4P/AGZvhv4/si/h34ofEH4ifFDwt4Qj+LEHgfVNa0H4efCXRvGmheNt T03xZ4y8KaFf/rpVDS9L0zQ9OsdH0XTbDR9I0y1hstN0vS7O30/TtPsrdBHb2ljY2kcNtaWsEarH DbwRRxRIoREVQBV+gD4D+C/jDRv2efjf8Yf2e/ibfWvhVPi58X/Gnx0/Z78Ua1NHp2gfEzTvilcW 3iTx74D0nVblksH+I/gP4hXHiSS68JPdLrGpeDNZ8M6/pNldWi6sdP8AqX4x/G34a/AXwdd+Nvib 4ktdD02NhaaTpsYN94m8Xa5OVj03wp4I8NW2/WPFvizWbp4bLR/D+iWt3qN9dTxokQTfInSePvh1 4A+Kvhm+8F/EzwT4U+IPhHUthv8Aw14z0DS/Emh3TxbvJml0zV7W7tDcW5YvbXAiE9vIfMgkjkAY eR/DX9kD9mD4P+JI/GPw3+Bnw58MeL7eF7ax8VW/h61vfEml2kqsktno2u6oL7VNFspY3aOWz0m6 s7aWMhJImUADijTxVGLpUXRdO8vZ1Kjmp0Yybai6UYctZU7tQ/e0W4KMZNyTnL9ex3EHhvxVi8Px PxbS4ywvEKw2Ap8QZJw/hsmrZVxbjsvwlDCVM0o8SZhmNLG8HYnPIYeGIzeH+rHGNGlmtXHZjl8a ODxeGyTLMj9jzwF4x8E/ByTU/iLpJ8O/EL4sfET4ofHPxn4W8+K5Pg7Vfi9461vxrZeCpZ4C0E17 4N8P6novhnVriCWaC61jStQureeWCaNz9TUUV00qao0qdKLbVOEYJveXKkuaVrLmlu7Jatn59xPx Bi+KuI884kxtHD4bFZ5mmNzOrhcHGpDB4N4yvOtHBYKFWpWqwweDhKOFwlOpWq1IYelThOpOScmU UUVoeEFFFFABX53X3x9+LPhT4q/FvwV4S0PTfiNrnjT9uzw18BfAmm+NPF1/4Z8N/DzwxL/wTt+F /wC0Lreqx3NhoHiO8uNM03WPDvi/XZPDdnZW0utan4k1BYdT0+5uhcD9Ea/NBLG1/wCGpJp/K/e/ 8PLxfb98n/H1/wAOc4tN83bv2/8AHl+52Y8v/lps8395QB6Gn7TnxW+3zfCj/hA/AFz8dF/aPm/Z 4hvIvFHiGD4V+Vbfs46N+1HefE27d/D0/i230+y+Hut2nh0eCoba7u734iy2Wj/8JZZeF7y48Z6X x3wS+NvxQ0X4vfFLwb8UPDumnxB4+/b3X4JiPRvGGra54U8MaBpH/BNb4c/Hmw8QeCjq2kWN9Hpn iO98ByT3/hK5stLGg+IfGniZ/wC1PEMumjWvEny9+3T4q1/4RfCH9tT48fDvUG8OfFf4P/tt/Bjx d8OvFscFrqMnh7X/ABZ+yl+yt8G/EN22j6xBqHh/WINU+G/j7xZ4cm0zXtJ1TSkOpx6xBZRa/pmk 6pYfG0vxr+KOjf8ABNP4k/tlWHi68X9pO0/bK+H3xTtviVc2elahJB448T/B34P/ALO2s6rH4V1C wuvA62dx8GfEWseCLbw8PDP/AAjemWl0mqaXpFlr9pZarbgH7L/FT9rTxZ4P1j4g6PpPhPwpoeh+ AP2gLH4NeJ/i7491LxRJ8NvAOg3f7Nfwy+PUPjv4g/8ACLeHr248O6dqGtfESL4fW9/r+q+GfA2l SW9vrWv+PNP1C/0bwrrdrwh8afjtrnx78S6DOPgvqvwn0D9mH4I/GC4uPCPibXdffUda+IGrftAW d7qvgnxEPDVjaa54f1l/hz4dGmyX7xW0WhqNTs2uLzUJoh/PB4n/AG6P2q/g5+ydo/xu+HfxavNF +KHx7/a08T6l8WPFN74W8C+JZPFN1afspfs6x2QTSvFXhfW9C8PWtjDpenWthp/hfTNFsLGytIbG 0tobRfIP3B4W+IfjD4Y/FD/gl5ovgXVl0DSv2qv2PPElx8erGLTtKvIfHcmhaFcfFbR8DUrG8bwt Hp3j34y/ErW7WHwW3hyGOPxNJowj/sHTNF0vTQD9K/h98d/if4+8P/sU/EX4leDtH8Cx/tG+PtL1 Twz4O8F/EPxFdz+D9D8RfsifHv4tx6d8UL06RpeifEG6t4vC9rBc+G7Wyg8M6L4puNP1zT9X1+68 E6PrGs+BfGf9svUvGHws/ao+Hui+KfhJrl9efsO/tcfGbwP4/wD2ffiP4j8UReEJvhR4f8NeHJtO ufFUnh7Q9P1fVpLz4o+HdY0Hxb4R1CyexvtE1qxvND06a30zUb70tfDGh+I/gd/wTH8MazY/bND1 BtE0W7svtN5bebpup/8ABOn9prRb22+02lxBeR+dpl9dW3nRXCXEXm+dDLHcJHKn4i/sc/HH4q/t K/CX9pjVfjZ4wvPGt18LP+Cb37Y3wv8AASfYdI8OafoHgnWfD3wMn1PS10jwnp+haVqN5dv4V0BX 8QavZX/iNINOjtotWS3muYpgD+lj9pzxN4g8K+EPhze+HNXvtGutT/aO/Zo8M6hcafO0Et34f8Uf HHwNoPiLSJ2Xl7HWdGv73Tb+A/LPaXM0TfK5ryG2/ad+JF9pOhfFe7+H3hCP9njxh8b9I+Bel3Fl 4z19Pi7HbeMfjTB+z14J+KR02Pw5b+GzpXiX4japoN2/g+DX7HXPDvw71hfGcvia68U6fc/Dgep/ tUwRXHgz4ZrMm9U/aa/ZcnUbmXEtv8evAM0LZUqTskRW2nKtjDBlJB/GHwl8UvHt7/wVtvv2G7rx DLN+yt4Z+Lut/GLRPhI1lpg0+y+IOn+DU/aa0vVv+EkWyXxrc6do/wAdL5/iDovhW88S3HhHRtQt dJ0zS9CtNA0PRtJsAD9MPhh8GfD+k/tdfFvQIvHP7Q2oaB8N/hd+zf448I+H/Ef7Vf7TnizQbTxJ 4x8U/tD2Xia61XRfFHxd1jS/FFlq9r4G8LQXGieKbTWtCRNL/cabEb3UTd6f7Rdtr9h8XG8S/FGx /aJ1T9me3+F/h230a+/Zu8Z/FDw/qPw9+Jtp4m8dXHxE8RfE3wx8BfFXhj42eNND8SeFLv4XWPgm Tw3o/wASPD/hWfw149vvEei+EF1Kz1rWvWfBUESftdftDXKpiab4HfsuRSvuY7o7fxb+1C0K7Sdi 7GuJjlVDNvwxYKu38Ov+CxX7e37Wn7NP7UvhL4UfA/4uXPgLwH4j+BngnxJq2kWng/4favdy674h +InxK8N6tqVr4g8ReE9Y8SaZcT6NoelWsJ0vV7JLCW0W+09LW/kmupAD9g5f2gviT4p/4T6f9mfw r8PPix8P/gr4d8HtqHiXxV8S9WttS+Lmv+Ifhj4a+Lth4a+H+taT4d8SaXHBcfDDxt8PfENn8S9f v9W0vxHrfjAaT/ZFnaaXf+JX4T4Y/tIpqvxV8QeIPDx1HxN4I+Ovxg/Z80PwZ/a2o3lmvhjwr4+/ ZDi+Ldpq1hpUqXkVvNdtoURvdIiNlG93q91ezXLXELLcfmH/AMFDPHPi39j/AONf7NX7Pn7Nmu3v wn+EHx5+GXww+F/xS8I6CYrz+3/CHhbWPDnwS0KPT9e12PVvE/hHxHY/Cu4h8GHx14M1rw945utM 0fwxLe+I7m/8JeGLvSPpz9ti7m+B3wN/bZ+IvwnW28FeL/gV8S/2TfEPwm1PTLKzmt/BWqab4P8A hF8PLN9O0bUILzQ7iyi8EeI9b8MtpOpabfaTPpWpXEE9lLlGQA+vPjD+0T8Z4fiJp/w9+EWi+ArK 70b9qvwN8FNe1DxtqWrvba/4c8T/ALNrfG+SWGHS9CvptIuRql5Do8ssL3Eq2emrPBIsmpSLYXX+ PvjGx+JvxG+E/gPwzaa38TNd/aPPw+0ybxx478Qz+A/Dui6D+yV8EfjH4u8bRWkWj32o6P4e0t/F mmeG9L+HPhtIR4h8a66fEl3rGgQa/wCJtU0b8OfC3x++L9//AME2v2iP2xL3xre3f7Rtn+2N8FPH lj8RLjT9FlFh4ohsPg18CEvLDwg+mnwHY2X/AAqq5uvDEmh2nheHQZnvL3xBLpj+J7261qb69/ar +IXjD4a/sz/tNftMeCNZfQfjh8PP2qfgH4v8IeOoLLTrqbTNd+If7IH7JHw18ZyzaFqFnd+F9X07 XvBvi/XNOudB1rRNR0CG8k0zX7PTLfxF4f8AD+raWAffd1+1R8ZJta8LfCnR/hX4Bk+M1x+0d4j/ AGdPHtxf+Ptcj+GPhZ9I/Zwn/ac0r4k6JqEHg1vFPifT9b+H2peCYD4Il0jQ77TfGPiLUPC8/iuX SNAfxxqGT4k/bA+JPhvSYbHxJ4V+GPgDUvDfxL+I3wz+LPxe8XeIPGd38APAWpeDNK8I+JfCF7qW uaX4Wh1Hw9bfFTwt4103ULLUfiBe+DfBfgjWNK8R+FNQ8c+JNe/4Qm18e/Pf7Fer6j8RPhP+wL8b PGd0+u/FL41/HL43fEv4oeLp1jt7vxZ41j+Bnxt+HFtrFzZWKWulWCWHgTwT4S8J6ZpWkWGn6Npe h+HtLsdO061itUFfF3/BSv8AbA/aK/ZD1zUZv2ePiH/wr2T4i/tL/Ht/GR/4RLwN4tXWW8MfBf8A ZXbQyU8c+GfEyWH2E6xqX/ILWyFyLki7+0COERgH9JnhjUL7VvDXh7VNTOhnUtS0PSdQ1A+GNVm1 3w0b68sLe4uz4e1y4sdLn1nQzPJJ/ZOqz6Zp02o2H2e7ksbR5mt49yvAv2U9F0zw7+zD+zroei2i 2OlaZ8DvhVa2FmjzSR21ungfQ9kMbzySy+WmdqK0jbFARcKqge+0AFFFFABRRRQB/9k= --94eb2c0bda268a23440545422840-- From nobody Thu Jan 5 05:23:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C264B129450; Thu, 5 Jan 2017 05:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix1GTWPnBunl; Thu, 5 Jan 2017 05:23:33 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448C8129437; Thu, 5 Jan 2017 05:23:32 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 64F5A45DA0; Thu, 5 Jan 2017 14:23:30 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 949F63F; Thu, 5 Jan 2017 14:23:29 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2DCF63B1; Thu, 5 Jan 2017 14:23:29 +0100 (CET) Received: (nullmailer pid 26412 invoked by uid 1000); Thu, 05 Jan 2017 13:23:28 -0000 Date: Thu, 5 Jan 2017 14:23:28 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-object-security@ietf.org, core@ietf.org Message-ID: <20170105132327.26vmqpqam26uvaoy@hephaistos.amsuess.com> References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n3zcijqwcxks3tl5" Content-Disposition: inline In-Reply-To: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Subject: Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:23:34 -0000 --n3zcijqwcxks3tl5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello OSCOAP authors, On Wed, Jan 04, 2017 at 10:12:29AM +0100, Christian Ams=FCss wrote: > getting familiar enough with OSCOAP to start an implementation, there > are some areas which are not fully clear to me from reading the draft: some more questions came up: * 5.2 gives the context for the Enc_structure as "Encrypted", while cose-msg-24 would set a "Encrypt0". Why does that differ here? * 5. states that the '"unprotected" field [...] SHALL be empty', but above states that sid 'can be placed in the unprotected headers bucket'. How do those statements go together? * How are sequence numbers (which are sorted integers) mapped to partial IVs? Which endianness is used? (The padding direction follows from cose-msg-24 3.1). I'd assume (and implement) that big-endian is used because it aligns naturally with COSE's left-padding, but as I see it, that does not strictly follow from the draft. * I concluded that the tag is always the last bytes of the ciphertext from example A.4, but did not find text in the spec to support that; what made me especially unsure about this is that the COSE_Encrypt0 definition of cose-msg-24 5.2 only mentions the ciphertext there, which may be nil. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --n3zcijqwcxks3tl5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhuSM8ACgkQOY0REtOk veGoGw/7B1cd+gH3CtsQOf1bT3a9DvIZ5/fpkBBw3VfCP/mixxmNNEnWN5NG0dq+ YT+A/XbA/Y32hVOV0UNAEYDRL5UfbNTU7qRzbeMPktAL9Mo5DB/uxqiRTKIshnQ5 6O7xZhQCQzVCuPdZRz6F2/zpWoBdDrndHP0Ym3OhppY8SM8ZlpyjW0+s9jbkA+Nm A+YmMLjjEaSaCS5x112merR/Tp5lmI2bL45cgQwC5ThH4ZbI3g6M7wD3od7I7m/D +OS44j1ntBRo0ihAtDoOI2zrKgTo0GF8i64f4qA9VRxAOWOrmJh70AC9FKupPXRk RhyuGohueyrJfnQ0WunYvzxBncahjddQWNXXpAYZF/wSJ68W0dO8fxHirU7GRCe5 6PpGH3Cb64+r+vMHNcQ9HWG3zLZjTw+kjV1hcijW4attWKyEZL2M12r5E0V7O2B3 l19Nk3ZBYAYfzBFNQ/lg3+7jT7Pw40syhE1jqM+qBTLzFEn1Gw4EdSaIqPW6EpTe 3vBP6hX308tX+OhyXT6Xh2DIYXc73vnW1dHAO8wVmxZZTbqazl9t08vQc8nCkQtU PoXPkRBuhu0bIvYo0B0RQ9dMVWvNMTVELb+CJdbD73RKLnJ1MQtZHmzSjwZWqbYN 4Im+S2INJ5vDTgLb2LPLigDCTvXY2XFiC39n8mE5uXK3vafagQg= =wzbD -----END PGP SIGNATURE----- --n3zcijqwcxks3tl5-- From nobody Thu Jan 5 18:56:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2A0129BA2; Thu, 5 Jan 2017 18:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 C9NdFxrPkpRr; Thu, 5 Jan 2017 18:56:51 -0800 (PST) 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 1FAB01296B9; Thu, 5 Jan 2017 18:56:50 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 5 Jan 2017 19:16:21 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , , References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> In-Reply-To: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> Date: Thu, 5 Jan 2017 18:56:43 -0800 Message-ID: <004301d267c8$84443b70$8cccb250$@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: AQJG/i1ruZbl3sV3WEzkHYqMMmSQqKBBiMJA Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 02:56:53 -0000 Christian, While not an author on the drafts, I will take a stab at giving clarification to your points. See response below, Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Christian = Ams=FCss > Sent: Wednesday, January 04, 2017 1:12 AM > To: draft-ietf-core-object-security@ietf.org; core@ietf.org > Subject: [core] OSCOAP: roll-out, recipient seqno, option number, = sequence > numbers >=20 > Hello OSCOAP authors, >=20 > getting familiar enough with OSCOAP to start an implementation, there = are > some areas which are not fully clear to me from reading the draft: >=20 > * At least master secret and CID are preconfigured (that's assuming > default algorithm, sender/receiver ID). It's out of scope for this > spec, but are there any other drafts on how those should be rolled = out > / rolled over? There are indeed a couple of drafts that are looking a this: Draft-ietf-ace-oath-authz provides an overview of how authentication and authorization is going to work. It uses draft-ietf-ace-cbor-web-token = as a message format to carry the keys from the auth server back to the client = and resource server. It can run over either DTLS with draft-gerdes-ace-dtls-authorize or OACAOP with draft-selander-ace-coap-profile. Additionally, draft-selnder-ace-cose-ecdhe provides for a way to get = these secrets based on pre-configured asymmetric keys or symmetric secrets. >=20 > * btw, why is algorithm a "SHALL" be pre-established (3.2) and the > role IDs a "MAY" be predefined, if (as I understand) absence of > pre-definition in both cases means fallback to defaults? SHALL =3D=3D MUST so there is no fallback on the algorithm. I think = that the default on AEAD should be an MTI statement. Yes the role IDs would = default to the default values as would the KDF function. Given that there is = no negotiation on the replay window size, I don't think that there is = really a default here as an application can probably choose any size they want, = it will just effect the ability to cleanly pickup messages outside of the replay window. >=20 > * speaking of "role IDs" to subsume sender and recipient ID, it > strikes me as odd that sender and recipient contexts are = qualitatively > different (the former has a sequence number, the latter a replay > window in 3.1), but the roles of Sender and Recipient in terms of = used > IDs stay the same when roles flip mid-conversation. Does that mean > that once my server starts "asking back", it grows a recipient > sequence number, and the former client grows a sender replay window? In some sense, what you have stated above is correct. The sequence = number is used for a nonce and thus needs to be unique for every message that I send. In another sense, what you have stated above is wrong in that for most cases a device will be both a sender and a recipient and thus it = will have a sender context for all the messages it sends and a recipient = context for all of the messages that it can receive. The same thing is true for DTLS where there is a sending stream and a receiving stream and they are handled differently. Part of the confusion that you might be having at this point is the fact that there is another draft running around draft-tiloca-core-multicast-oscoap where you end up with a single sender context, but potentially one recipient context for each of the multicast receivers which can reply. Since they did not want to make a clean separation between these documents about how the context structures are setup, I find that the section is a bit sloppy. >=20 > * The option numbers are "to be done". Is there one that's already in > use in first implementations? Could we pick one now and hope that = all > concurrent drafts become aware of its use so it stays stable, and if > not just change it when going from draft to RFC? Or agree on one to > use from the experimenal range until RFC release? I am using a dummy with mine, however I would not want to make it = generally known. I would be willing to do one-on-one exchanges. My assumption is that a pre-assignment should be made something mid-month based on the = F2F conversation in Seoul. =20 >=20 > * Replay protection: The sequence numbers follow DTLS' anti-replay > mechanisms, where DTLS sessions are (to my limited knowledge) more = or > less ephemeral. >=20 > When a device with a precommissioned context encounters a factory > reset condition, or any kind of mis-match happens between >=20 > * the static context memory area of the keys, > * the frequently modified window position possibly kept in log flash > area, and > * the bitfield inside the window (which I'd very much prefer not to > commit to flash memory in embedded devices), >=20 > is there any way to recover from such a situation, eg roughly by the > recipient saying "I've heard all that, start at N or I can't trust = you > at all"? >=20 > It might well be a bad idea to allow such a thing (at very least, = that > information needs to be authenticated), so right now this is = primarily > a question about whether there is a mechanism I missed, and whether > there should be guidance considering the embedded use cases. The reset of the nonce is going to be a problem under all circumstances = if you go back to a clean factory state and you cannot store the = appropriate nonce in non-volatile memory. Under these circumstances, the = expectation that I have is that the key you are using is also going to be lost so = you no longer have a key that can be used to encrypt messages and you will need = to go through a key establishment protocol (see the above drafts) to create = a new session encryption key. This is going to be the same as with DTLS either with a shared secret or an asymmetric key pair where a new = session is established. >=20 > Could you help clarify these issues? >=20 > Thanks > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Jan 5 19:09:59 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6A0129BC7; Thu, 5 Jan 2017 19:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 LyFUZOHeKxtA; Thu, 5 Jan 2017 19:09:57 -0800 (PST) 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 69FE6129BC4; Thu, 5 Jan 2017 19:09:57 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 5 Jan 2017 19:29:27 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , , References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <20170105132327.26vmqpqam26uvaoy@hephaistos.amsuess.com> In-Reply-To: <20170105132327.26vmqpqam26uvaoy@hephaistos.amsuess.com> Date: Thu, 5 Jan 2017 19:09:49 -0800 Message-ID: <004401d267ca$58e6ef70$0ab4ce50$@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: AQJG/i1ruZbl3sV3WEzkHYqMMmSQqAHC6UwWoDN9aoA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 03:09:59 -0000 And some more possible answers Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Christian = Ams=FCss > Sent: Thursday, January 05, 2017 5:23 AM > To: draft-ietf-core-object-security@ietf.org; core@ietf.org > Subject: Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence > numbers >=20 > Hello OSCOAP authors, >=20 > On Wed, Jan 04, 2017 at 10:12:29AM +0100, Christian Ams=FCss wrote: > > getting familiar enough with OSCOAP to start an implementation, = there > > are some areas which are not fully clear to me from reading the = draft: >=20 > some more questions came up: >=20 > * 5.2 gives the context for the Enc_structure as "Encrypted", while > cose-msg-24 would set a "Encrypt0". Why does that differ here? I think that they (and I) missed a change in the COSE document. This = was what it used to be. >=20 > * 5. states that the '"unprotected" field [...] SHALL be empty', but > above states that sid 'can be placed in the unprotected headers > bucket'. How do those statements go together? Looks to me like when they address my comment on this they only got it partly correctly. If you look below, it says that 'sid' is going to be = a protected header field. >=20 > * How are sequence numbers (which are sorted integers) mapped to = partial > IVs? Which endianness is used? (The padding direction follows from > cose-msg-24 3.1). >=20 > I'd assume (and implement) that big-endian is used because it aligns > naturally with COSE's left-padding, but as I see it, that does not > strictly follow from the draft. I treated the sequence number as a network byte order integer packed = into the smallest possible byte string. For the same reasons that you gave. >=20 > * I concluded that the tag is always the last bytes of the ciphertext > from example A.4, but did not find text in the spec to support that; > what made me especially unsure about this is that the COSE_Encrypt0 > definition of cose-msg-24 5.2 only mentions the ciphertext there, > which may be nil. Feel free to assume that the tag is appended to the end of the cipher = text. This is going to be dependent on the algorithm that is being used and is done in other ways for some different algorithms. For example, there is = one algorithm (SIV mode) where the tag is the IV and is thus frequently prepended to the cipher text. It is true that there is a way not to = include the cipher text as part of a COSE message, however this is for a case of detached cipher text. Even in that case the tag is carried as part of = the cipher text it is just carried someplace else. OSCOAP does not use = detached cipher text. >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Fri Jan 6 05:27:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D31294D5 for ; Fri, 6 Jan 2017 05:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl81P8shW8U8 for ; Fri, 6 Jan 2017 05:27:42 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CC71293FC for ; Fri, 6 Jan 2017 05:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vJYJM6MqZZk7dUzvHZjqfFAm3rm3C0fU15JyvUwsEKI=; b=LO+w9ESog4mn44IvJdkj3caVqb CJSjU1sXv7n6OGe9Krj7+BRbR5vJWzAHB4EEaYozauZsZCWxEn7eJq9VCuZkkRDpf8HS2KH0ImP1h OAoHNt041ZDi6WkF0ZCVJrSTASfyRPF+kJq7UCjgLbVq2NRsTgx0zxYf5/st8W/RAT+7gVyjyNE8/ n4GzXZLPUfj4uFf9iAsOpBktezoADhPvAfCu1zDw/bgxh9LVOURaJbU7Yreoe9urzzaaoX3aCIXnj QtJq+X1qmcBpOijILtRhu8Az0Eb1E8GeYImz39tR+F6q5scRiMGocW7/lzAxCwsQ5XhHEQp+/bGkk isfEnzGA==; Received: from [116.6.65.160] (port=57156 helo=[172.31.1.51]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cPUYV-003w80-Aa for core@ietf.org; Sat, 07 Jan 2017 00:27:40 +1100 To: core@ietf.org References: From: Christian Groves Message-ID: <59ad5eb8-b377-159b-8cca-bae2fcf56bf2@nteczone.com> Date: Sat, 7 Jan 2017 00:27:23 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] draft-ietf-core-dynlink -- New Use Case X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:27:43 -0000 Hello Hannes, I've been thinking about a similar use case whilst updating dynlink, so I'd agree with you that such functionality would be a worthwhile addition to dynlink. The question is which method would be the appropriate way to implement such functionality? A possible way to do this would be to use a linked batch (or batch) interface (cl.4.3/draft-ietf-core-interfaces). The client would construct a resource using the linked batch interface for the information/resources that it requires. A GET on the collection would return all the information. However the current text of draft-ietf-core-interfaces indicates that observe may be supported on an item in a collection not on the collection itself. To get around this we could introduce an "item" query attribute that is only used on collection (e.g. batch, linked-batch) resources which enables the use of the parameters from dynlink on a collection. The "item" attribute points to one item in the collection. e.g. given the links: Req: GET /.well-known/core Res: 2.05 Content (application/link-format) ;rt="simple.sen";if="core.b", ;rt="simple.sen.lt";if="core.s", ;rt="simple.sen.tmp";if="core.s";obs, ;rt="simple.sen.hum";if="core.s", A Req: GET /s?item=tmp>=37 Token: 0x4a Observe: 0 would produce the following when temp exceeds 37: Res: 2.05 Content (application/senml+json) {"e":[ { "n": "/s/light", "v": 123, "u": "lx" }, { "n": "/s/temp", "v": 38, "u": "degC" }, { "n": "/s/humidity", "v": 80, "u": "%RH" }], } For me this seems like the easiest approach as the observation attributes are kept together and doing a GET on the collection seems logically right because you want all the information of the collection resource. However there might be other methods? Regards, Christian On 4/01/2017 6:52 AM, Hannes Tschofenig wrote: > Hi Christian, Hi all, > > Friedhelm and I had recently been wondering about the following use case > and whether others in the group also see it as worthwhile to include in > the core-dynlink draft. > > Here is the story: > > core-dynlink describes attributes to reduce the amount of notifications > that are sent to an observer. The approach is quite simple: The observer > expresses interest in a resource and conveys the attributes, such as > pmin, pmax, to rate limit notifications. > > When the resource changes then the subject, as RFC 7641 calls it, sends > the current value of the resource. > > This is very useful functionality. > > However, imagine that you want to obtain data about many different > resources and you utilize a data model (like in LWM2M) where resources > are organized in a hierarchical fashion. For example, you may want to > obtain a set of resources if the value of one of the resources changes. > > To be more specific, imagine a system that convey data during an alarms > in an industrial facility: once a high temperature alarm is triggered > the system will most likely want a snapshot of the system state (to > quickly perform an analysis). > > What do you think? > > Ciao > Hannes > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jan 9 14:01:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3A1293E8; Mon, 9 Jan 2017 14:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pheqeh7fijPt; Mon, 9 Jan 2017 14:01:31 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6731127ABE; Mon, 9 Jan 2017 14:01:30 -0800 (PST) X-AuditID: c1b4fb2d-26a859800000561e-6f-58740838ce4b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 3F.46.22046.83804785; Mon, 9 Jan 2017 23:01:28 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.95]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Mon, 9 Jan 2017 23:01:20 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "core@ietf.org" Thread-Topic: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers Thread-Index: AQHSZmq0sIasQcnGlU2tRoaM5elaSqEqs2yAgAYHjoA= Date: Mon, 9 Jan 2017 22:02:04 +0000 Message-ID: References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> In-Reply-To: <004301d267c8$84443b70$8cccb250$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2J7lK4FR0mEwaPJRhbLLzxnsdj3dj2z xbR/Z1gsVk//zubA4rFxznQ2j6377zJ5LFnykymAOYrLJiU1J7MstUjfLoErY8HqVYwFC2Iq lhwUaGD8ENnFyMkhIWAisfbUPsYuRi4OIYF1jBI3z/SyQjiLGCVWL3jLAlLFJuAi8aDhEROI LSKQL/HrZwcLSBGzQBOjxPxlc8ESwgIREv09t1khiiIldhy9wA5hW0ncPvgZLM4ioCJxasZJ sHpeAQuJ6V9mgS0QEqiSWLf7A1g9p4CDxMz795lBbEYBMYnvp9aA1TMLiEvcejKfCeJsAYkl e84zQ9iiEi8f/wObLyqgJ7H8+RqouJLEotufgeo5gHo1Jdbv0ocYYy2x6f9CFghbUWJK90N2 iHMEJU7OfMIygVF8FpJtsxC6ZyHpnoWkexaS7gWMrKsYRYtTi4tz042M9VKLMpOLi/Pz9PJS SzYxAmPx4JbfujsYV792PMQowMGoxMNbsLQ4Qog1say4MvcQowQHs5IILyNbSYQQb0piZVVq UX58UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjC4Hi50i5nC6MleJB1f9 6vxj8Hf92i+HHaROO0h+zpyy7nJ0xaZgPo+FF65UnVSfxX/R47S3qlz86z4p79kHvnMn6v1g /c9/4tmPfNNbn1MWLxN6OUdKOIFViD1IJllMbtoD7eqltuUFxdKrP3XzGG/YLZa/JH2R3uwW CYuvGbK2IcrRR8vLlViKMxINtZiLihMBdC+a/sECAAA= Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" Subject: Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:01:33 -0000 SGkgQ2hyaXN0aWFuLA0KDQpUaGFua3MgZm9yIHZlcnkgZ29vZCBjb21tZW50cywgYXBvbG9naWVz IGZvciBzbG93IHJlc3BvbnNlLiBKaW0gaGFzDQphbHJlYWR5IHByb3ZpZGVkIHNvbWUgYW5zd2Vy cywgaGVyZSBhcmUgc29tZSBtb3JlLg0KDQpPbiAyMDE3LTAxLTA2IDAzOjU2LCAiSmltIFNjaGFh ZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KDQo+Q2hyaXN0aWFuLA0KPg0KPldo aWxlIG5vdCBhbiBhdXRob3Igb24gdGhlIGRyYWZ0cywgSSB3aWxsIHRha2UgYSBzdGFiIGF0IGdp dmluZw0KPmNsYXJpZmljYXRpb24gdG8geW91ciBwb2ludHMuDQo+DQo+U2VlIHJlc3BvbnNlIGJl bG93LA0KPg0KPkppbQ0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJp c3RpYW4gQW1zw7xzcw0KPj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA0LCAyMDE3IDE6MTIg QU0NCj4+IFRvOiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnOyBjb3Jl QGlldGYub3JnDQo+PiBTdWJqZWN0OiBbY29yZV0gT1NDT0FQOiByb2xsLW91dCwgcmVjaXBpZW50 IHNlcW5vLCBvcHRpb24gbnVtYmVyLA0KPj5zZXF1ZW5jZQ0KPj4gbnVtYmVycw0KPj4gDQo+PiBI ZWxsbyBPU0NPQVAgYXV0aG9ycywNCj4+IA0KPj4gZ2V0dGluZyBmYW1pbGlhciBlbm91Z2ggd2l0 aCBPU0NPQVAgdG8gc3RhcnQgYW4gaW1wbGVtZW50YXRpb24sIHRoZXJlDQo+PmFyZQ0KPj4gc29t ZSBhcmVhcyB3aGljaCBhcmUgbm90IGZ1bGx5IGNsZWFyIHRvIG1lIGZyb20gcmVhZGluZyB0aGUg ZHJhZnQ6DQo+PiANCj4+ICogQXQgbGVhc3QgbWFzdGVyIHNlY3JldCBhbmQgQ0lEIGFyZSBwcmVj b25maWd1cmVkICh0aGF0J3MgYXNzdW1pbmcNCj4+ICAgZGVmYXVsdCBhbGdvcml0aG0sIHNlbmRl ci9yZWNlaXZlciBJRCkuIEl0J3Mgb3V0IG9mIHNjb3BlIGZvciB0aGlzDQo+PiAgIHNwZWMsIGJ1 dCBhcmUgdGhlcmUgYW55IG90aGVyIGRyYWZ0cyBvbiBob3cgdGhvc2Ugc2hvdWxkIGJlIHJvbGxl ZCBvdXQNCj4+ICAgLyByb2xsZWQgb3Zlcj8NCj4NCj5UaGVyZSBhcmUgaW5kZWVkIGEgY291cGxl IG9mIGRyYWZ0cyB0aGF0IGFyZSBsb29raW5nIGEgdGhpczoNCj4NCj5EcmFmdC1pZXRmLWFjZS1v YXRoLWF1dGh6IHByb3ZpZGVzIGFuIG92ZXJ2aWV3IG9mIGhvdyBhdXRoZW50aWNhdGlvbiBhbmQN Cj5hdXRob3JpemF0aW9uIGlzIGdvaW5nIHRvIHdvcmsuICBJdCB1c2VzIGRyYWZ0LWlldGYtYWNl LWNib3Itd2ViLXRva2VuIGFzDQo+YQ0KPm1lc3NhZ2UgZm9ybWF0IHRvIGNhcnJ5IHRoZSBrZXlz IGZyb20gdGhlIGF1dGggc2VydmVyIGJhY2sgdG8gdGhlIGNsaWVudA0KPmFuZA0KPnJlc291cmNl IHNlcnZlci4gIEl0IGNhbiBydW4gb3ZlciBlaXRoZXIgRFRMUyB3aXRoDQo+ZHJhZnQtZ2VyZGVz LWFjZS1kdGxzLWF1dGhvcml6ZSBvciBPQUNBT1Agd2l0aA0KPmRyYWZ0LXNlbGFuZGVyLWFjZS1j b2FwLXByb2ZpbGUuDQoNCkkgdGhpbmsgSmltIG1lYW50IHRoaXMgZHJhZnQ6DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VpdHotYWNlLW9zY29hcC1wcm9maWxlDQoNCj4NCj5B ZGRpdGlvbmFsbHksIGRyYWZ0LXNlbG5kZXItYWNlLWNvc2UtZWNkaGUgcHJvdmlkZXMgZm9yIGEg d2F5IHRvIGdldCB0aGVzZQ0KPnNlY3JldHMgYmFzZWQgb24gcHJlLWNvbmZpZ3VyZWQgYXN5bW1l dHJpYyBrZXlzIG9yIHN5bW1ldHJpYyBzZWNyZXRzLg0KDQpDZXJ0aWZpY2F0ZSBiYXNlZCBhdXRo ZW50aWNhdGlvbiBpcyBhbHNvIHN1cHBvcnRlZCBpbg0KICAgICAgICAgICAgICAgICAgIA0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlDQog ICAgICAgICAgICAgICAgICAgDQoNCj4NCj4+IA0KPj4gICAqIGJ0dywgd2h5IGlzIGFsZ29yaXRo bSBhICJTSEFMTCIgYmUgcHJlLWVzdGFibGlzaGVkICgzLjIpIGFuZCB0aGUNCj4+ICAgICByb2xl IElEcyBhICJNQVkiIGJlIHByZWRlZmluZWQsIGlmIChhcyBJIHVuZGVyc3RhbmQpIGFic2VuY2Ug b2YNCj4+ICAgICBwcmUtZGVmaW5pdGlvbiBpbiBib3RoIGNhc2VzIG1lYW5zIGZhbGxiYWNrIHRv IGRlZmF1bHRzPw0KPg0KPlNIQUxMID09IE1VU1Qgc28gdGhlcmUgaXMgbm8gZmFsbGJhY2sgb24g dGhlIGFsZ29yaXRobS4gIEkgdGhpbmsgdGhhdCB0aGUNCj5kZWZhdWx0IG9uIEFFQUQgc2hvdWxk IGJlIGFuIE1USSBzdGF0ZW1lbnQuICBZZXMgdGhlIHJvbGUgSURzIHdvdWxkDQo+ZGVmYXVsdA0K PnRvIHRoZSBkZWZhdWx0IHZhbHVlcyBhcyB3b3VsZCB0aGUgS0RGIGZ1bmN0aW9uLiAgIEdpdmVu IHRoYXQgdGhlcmUgaXMgbm8NCj5uZWdvdGlhdGlvbiBvbiB0aGUgcmVwbGF5IHdpbmRvdyBzaXpl LCBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgcmVhbGx5DQo+YQ0KPmRlZmF1bHQgaGVyZSBh cyBhbiBhcHBsaWNhdGlvbiBjYW4gcHJvYmFibHkgY2hvb3NlIGFueSBzaXplIHRoZXkgd2FudCwg aXQNCj53aWxsIGp1c3QgZWZmZWN0IHRoZSBhYmlsaXR5IHRvIGNsZWFubHkgcGlja3VwIG1lc3Nh Z2VzIG91dHNpZGUgb2YgdGhlDQo+cmVwbGF5IHdpbmRvdy4NCg0KVGhlIGRlZmF1bHRzIHNob3Vs ZCBiZSBNVEkgYXMgSmltIHBvaW50ZWQgb3V0LiBTZWUNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL29zY29hcC9pc3N1ZXMvNDINCg0KDQo+DQo+PiANCj4+ICogc3BlYWtpbmcgb2YgInJvbGUg SURzIiB0byBzdWJzdW1lIHNlbmRlciBhbmQgcmVjaXBpZW50IElELCBpdA0KPj4gICBzdHJpa2Vz IG1lIGFzIG9kZCB0aGF0IHNlbmRlciBhbmQgcmVjaXBpZW50IGNvbnRleHRzIGFyZSBxdWFsaXRh dGl2ZWx5DQo+PiAgIGRpZmZlcmVudCAodGhlIGZvcm1lciBoYXMgYSBzZXF1ZW5jZSBudW1iZXIs IHRoZSBsYXR0ZXIgYSByZXBsYXkNCj4+ICAgd2luZG93IGluIDMuMSksIGJ1dCB0aGUgcm9sZXMg b2YgU2VuZGVyIGFuZCBSZWNpcGllbnQgaW4gdGVybXMgb2YgdXNlZA0KPj4gICBJRHMgc3RheSB0 aGUgc2FtZSB3aGVuIHJvbGVzIGZsaXAgbWlkLWNvbnZlcnNhdGlvbi4gRG9lcyB0aGF0IG1lYW4N Cj4+ICAgdGhhdCBvbmNlIG15IHNlcnZlciBzdGFydHMgImFza2luZyBiYWNrIiwgaXQgZ3Jvd3Mg YSByZWNpcGllbnQNCj4+ICAgc2VxdWVuY2UgbnVtYmVyLCBhbmQgdGhlIGZvcm1lciBjbGllbnQg Z3Jvd3MgYSBzZW5kZXIgcmVwbGF5IHdpbmRvdz8NCj4NCj5JbiBzb21lIHNlbnNlLCB3aGF0IHlv dSBoYXZlIHN0YXRlZCBhYm92ZSBpcyBjb3JyZWN0LiAgVGhlIHNlcXVlbmNlIG51bWJlcg0KPmlz IHVzZWQgZm9yIGEgbm9uY2UgYW5kIHRodXMgbmVlZHMgdG8gYmUgdW5pcXVlIGZvciBldmVyeSBt ZXNzYWdlIHRoYXQgSQ0KPnNlbmQuICBJbiBhbm90aGVyIHNlbnNlLCB3aGF0IHlvdSBoYXZlIHN0 YXRlZCBhYm92ZSBpcyB3cm9uZyBpbiB0aGF0IGZvcg0KPm1vc3QgY2FzZXMgYSBkZXZpY2Ugd2ls bCBiZSBib3RoIGEgc2VuZGVyIGFuZCBhIHJlY2lwaWVudCBhbmQgdGh1cyBpdCB3aWxsDQo+aGF2 ZSBhIHNlbmRlciBjb250ZXh0IGZvciBhbGwgdGhlIG1lc3NhZ2VzIGl0IHNlbmRzIGFuZCBhIHJl Y2lwaWVudA0KPmNvbnRleHQNCj5mb3IgYWxsIG9mIHRoZSBtZXNzYWdlcyB0aGF0IGl0IGNhbiBy ZWNlaXZlLiAgVGhlIHNhbWUgdGhpbmcgaXMgdHJ1ZSBmb3INCj5EVExTIHdoZXJlIHRoZXJlIGlz IGEgc2VuZGluZyBzdHJlYW0gYW5kIGEgcmVjZWl2aW5nIHN0cmVhbSBhbmQgdGhleSBhcmUNCj5o YW5kbGVkIGRpZmZlcmVudGx5Lg0KDQoNClRoZXJlIG1heSBiZSBzb21lIGNvbmZ1c2lvbiBoZXJl IGluZGljYXRpbmcgdGhhdCBmdXJ0aGVyIGNsYXJpZmljYXRpb24gaXMNCm5lZWRlZCBpbiB0aGUg ZHJhZnQ6IEJvdGggbm9kZXMgaGF2ZSBhbGwgcGFydHMgb2YgdGhlIGNvbnRleHQ7ICBjb21tb24s DQpzZW5kZXIgYW5kIHJlY2lwaWVudC4gVGh1cyB3aGVuIGEgbm9kZSBzZW5kcyBpdCBhbHdheXMg dXNlcyB0aGUgc2VuZGVyDQpwYXJ0IGFuZCB3aGVuIGl0IHJlY2VpdmVzIHRoZSByZWNpcGllbnQg cGFydCwgcmVnYXJkbGVzcyBvZiBpdHMgaW5pdGlhbA0Kcm9sZS4gU2VuZGVyIGFuZCByZWNpcGll bnQgcGFydHMgYXJlIG1pcnJvcmVkIGJldHdlZW4gdGhlIHR3byBub2RlcywNCm92ZXJzaW1wbGlm eWluZzogTm9kZSAxOiBTZW5kZXJDdHg9QSBSZWNpcGllbnRDdHg9QjsgTm9kZSAyOiBTZW5kZXJD dHg9Qg0KUmVjaXBpZW50Q3R4PUENCg0KU2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29z Y29hcC9pc3N1ZXMvNDMNCg0KPg0KPlBhcnQgb2YgdGhlIGNvbmZ1c2lvbiB0aGF0IHlvdSBtaWdo dCBiZSBoYXZpbmcgYXQgdGhpcyBwb2ludCBpcyB0aGUgZmFjdA0KPnRoYXQgdGhlcmUgaXMgYW5v dGhlciBkcmFmdCBydW5uaW5nIGFyb3VuZA0KPmRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1v c2NvYXAgd2hlcmUgeW91IGVuZCB1cCB3aXRoIGEgc2luZ2xlIHNlbmRlcg0KPmNvbnRleHQsIGJ1 dCBwb3RlbnRpYWxseSBvbmUgcmVjaXBpZW50IGNvbnRleHQgZm9yIGVhY2ggb2YgdGhlIG11bHRp Y2FzdA0KPnJlY2VpdmVycyB3aGljaCBjYW4gcmVwbHkuICBTaW5jZSB0aGV5IGRpZCBub3Qgd2Fu dCB0byBtYWtlIGEgY2xlYW4NCj5zZXBhcmF0aW9uIGJldHdlZW4gdGhlc2UgZG9jdW1lbnRzIGFi b3V0IGhvdyB0aGUgY29udGV4dCBzdHJ1Y3R1cmVzIGFyZQ0KPnNldHVwLCBJIGZpbmQgdGhhdCB0 aGUgc2VjdGlvbiBpcyBhIGJpdCBzbG9wcHkuDQoNCkFzIEppbSBwb2ludHMgb3V0LCB0aGUgbXVs dGljYXN0IGNhc2UgaXMgY292ZXJlZCBpbiBhIHNlcGFyYXRlIGRyYWZ0LiBXZQ0Kd2FudGVkIHRv IHNlcGFyYXRlIHRoZSBzZWN1cml0eSBzb2x1dGlvbnMgZm9yIHRoZSBkaWZmZXJlbnQgdXNlIGNh c2VzDQoodW5pY2FzdCByZXF1ZXN0LXJlc3BvbnNlLCBncm91cCBjb21tdW5pY2F0aW9uL211bHRp Y2FzdCB3aXRoIHVuaWNhc3QNCnJlc3BvbnNlLCBjYWNoaW5nLCBwdWItc3ViIGV0Yy4pIHNpbmNl IG90aGVyd2lzZSB0aGUgZHJhZnQgd291bGQgYmUNCnVud2llbGR5LiBUaGUgZm9jdXMgb2YgT1ND T0FQIGlzIHVuaWNhc3QgcmVxdWVzdC1yZXNwb25zZSwgYnV0IHNpbmNlIGdyb3VwDQpjb21tdW5p Y2F0aW9uL211bHRpY2FzdCBjYW4gYmUgc3VwcG9ydGVkIHdpdGggZXNzZW50aWFsbHkgdGhlIHNh bWUNCmNvbnN0cnVjdCwgd2UgYWxzbyB3YW50ZWQgdG8gcHJlcGFyZSBmb3IgdGhhdCB1c2UgY2Fz ZS4gVGhlcmVmb3JlIHRoaXMNCmRyYWZ0IGRlZmluZXMgcmVjaXBpZW50IElEIHdoaWNoIGlzIHJl ZHVuZGFudCBpbiB1bmljYXN0IGJ1dCBuZWNlc3NhcnkNCndoZW4gdGhlcmUgbWF5IGJlIGRpZmZl cmVudCB1bmljYXN0IHJlc3BvbnNlcyB0byBvbmUgcmVxdWVzdC4gSSB0aGluayB0aGlzDQpvbmUg dGhpbmcgSmltIGZpbmRzIHNsb3BweS4gVGhlIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIG1ha2Ug ZGlmZmVyZW50DQptZXNzYWdlIHByb3RlY3Rpb24gcHJvY2Vzc2luZyBmb3IgdW5pY2FzdCBPU0NP QVAgYW5kIG11bHRpY2FzdCBPU0NPQVAuDQoNCj4NCj4+IA0KPj4gKiBUaGUgb3B0aW9uIG51bWJl cnMgYXJlICJ0byBiZSBkb25lIi4gSXMgdGhlcmUgb25lIHRoYXQncyBhbHJlYWR5IGluDQo+PiAg IHVzZSBpbiBmaXJzdCBpbXBsZW1lbnRhdGlvbnM/IENvdWxkIHdlIHBpY2sgb25lIG5vdyBhbmQg aG9wZSB0aGF0IGFsbA0KPj4gICBjb25jdXJyZW50IGRyYWZ0cyBiZWNvbWUgYXdhcmUgb2YgaXRz IHVzZSBzbyBpdCBzdGF5cyBzdGFibGUsIGFuZCBpZg0KPj4gICBub3QganVzdCBjaGFuZ2UgaXQg d2hlbiBnb2luZyBmcm9tIGRyYWZ0IHRvIFJGQz8gT3IgYWdyZWUgb24gb25lIHRvDQo+PiAgIHVz ZSBmcm9tIHRoZSBleHBlcmltZW5hbCByYW5nZSB1bnRpbCBSRkMgcmVsZWFzZT8NCj4NCj5JIGFt IHVzaW5nIGEgZHVtbXkgd2l0aCBtaW5lLCBob3dldmVyIEkgd291bGQgbm90IHdhbnQgdG8gbWFr ZSBpdA0KPmdlbmVyYWxseQ0KPmtub3duLiAgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIGRvIG9uZS1v bi1vbmUgZXhjaGFuZ2VzLiAgTXkgYXNzdW1wdGlvbiBpcw0KPnRoYXQgYSBwcmUtYXNzaWdubWVu dCBzaG91bGQgYmUgbWFkZSBzb21ldGhpbmcgbWlkLW1vbnRoIGJhc2VkIG9uIHRoZSBGMkYNCj5j b252ZXJzYXRpb24gaW4gU2VvdWwuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIGlmIHNv bWUgYXV0aG9yaXRhdGl2ZSBwZXJzb24gd291bGQgcHJvcG9zZSBhDQp0ZW50YXRpdmUgb3B0aW9u IG51bWJlciBpbiB0aGUgMC4uMjU1IHJhbmdlIHRvIHVzZSBmb3IgdGhpcyBwdXJwb3NlLCB3aGlj aA0KY291bGQgbGF0ZXIgYmUgY29uZmlybWVkIG9yIHJlcGxhY2VkLg0KDQo+DQo+PiANCj4+ICog UmVwbGF5IHByb3RlY3Rpb246IFRoZSBzZXF1ZW5jZSBudW1iZXJzIGZvbGxvdyBEVExTJyBhbnRp LXJlcGxheQ0KPj4gICBtZWNoYW5pc21zLCB3aGVyZSBEVExTIHNlc3Npb25zIGFyZSAodG8gbXkg bGltaXRlZCBrbm93bGVkZ2UpIG1vcmUgb3INCj4+ICAgbGVzcyBlcGhlbWVyYWwuDQo+PiANCj4+ ICAgV2hlbiBhIGRldmljZSB3aXRoIGEgcHJlY29tbWlzc2lvbmVkIGNvbnRleHQgZW5jb3VudGVy cyBhIGZhY3RvcnkNCj4+ICAgcmVzZXQgY29uZGl0aW9uLCBvciBhbnkga2luZCBvZiBtaXMtbWF0 Y2ggaGFwcGVucyBiZXR3ZWVuDQo+PiANCj4+ICAgKiB0aGUgc3RhdGljIGNvbnRleHQgbWVtb3J5 IGFyZWEgb2YgdGhlIGtleXMsDQo+PiAgICogdGhlIGZyZXF1ZW50bHkgbW9kaWZpZWQgd2luZG93 IHBvc2l0aW9uIHBvc3NpYmx5IGtlcHQgaW4gbG9nIGZsYXNoDQo+PiAgICAgYXJlYSwgYW5kDQo+ PiAgICogdGhlIGJpdGZpZWxkIGluc2lkZSB0aGUgd2luZG93ICh3aGljaCBJJ2QgdmVyeSBtdWNo IHByZWZlciBub3QgdG8NCj4+ICAgICBjb21taXQgdG8gZmxhc2ggbWVtb3J5IGluIGVtYmVkZGVk IGRldmljZXMpLA0KPj4gDQo+PiAgIGlzIHRoZXJlIGFueSB3YXkgdG8gcmVjb3ZlciBmcm9tIHN1 Y2ggYSBzaXR1YXRpb24sIGVnIHJvdWdobHkgYnkgdGhlDQo+PiAgIHJlY2lwaWVudCBzYXlpbmcg IkkndmUgaGVhcmQgYWxsIHRoYXQsIHN0YXJ0IGF0IE4gb3IgSSBjYW4ndCB0cnVzdCB5b3UNCj4+ ICAgYXQgYWxsIj8NCj4+IA0KPj4gICBJdCBtaWdodCB3ZWxsIGJlIGEgYmFkIGlkZWEgdG8gYWxs b3cgc3VjaCBhIHRoaW5nIChhdCB2ZXJ5IGxlYXN0LCB0aGF0DQo+PiAgIGluZm9ybWF0aW9uIG5l ZWRzIHRvIGJlIGF1dGhlbnRpY2F0ZWQpLCBzbyByaWdodCBub3cgdGhpcyBpcyBwcmltYXJpbHkN Cj4+ICAgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRoZXJlIGlzIGEgbWVjaGFuaXNtIEkgbWlz c2VkLCBhbmQgd2hldGhlcg0KPj4gICB0aGVyZSBzaG91bGQgYmUgZ3VpZGFuY2UgY29uc2lkZXJp bmcgdGhlIGVtYmVkZGVkIHVzZSBjYXNlcy4NCj4NCj5UaGUgcmVzZXQgb2YgdGhlIG5vbmNlIGlz IGdvaW5nIHRvIGJlIGEgcHJvYmxlbSB1bmRlciBhbGwgY2lyY3Vtc3RhbmNlcyBpZg0KPnlvdSBn byBiYWNrIHRvIGEgY2xlYW4gZmFjdG9yeSBzdGF0ZSBhbmQgeW91IGNhbm5vdCBzdG9yZSB0aGUg YXBwcm9wcmlhdGUNCj5ub25jZSBpbiBub24tdm9sYXRpbGUgbWVtb3J5LiAgVW5kZXIgdGhlc2Ug Y2lyY3Vtc3RhbmNlcywgdGhlIGV4cGVjdGF0aW9uDQo+dGhhdCBJIGhhdmUgaXMgdGhhdCB0aGUg a2V5IHlvdSBhcmUgdXNpbmcgaXMgYWxzbyBnb2luZyB0byBiZSBsb3N0IHNvIHlvdQ0KPm5vDQo+ bG9uZ2VyIGhhdmUgYSBrZXkgdGhhdCBjYW4gYmUgdXNlZCB0byBlbmNyeXB0IG1lc3NhZ2VzIGFu ZCB5b3Ugd2lsbCBuZWVkDQo+dG8NCj5nbyB0aHJvdWdoIGEga2V5IGVzdGFibGlzaG1lbnQgcHJv dG9jb2wgKHNlZSB0aGUgYWJvdmUgZHJhZnRzKSB0byBjcmVhdGUgYQ0KPm5ldyBzZXNzaW9uIGVu Y3J5cHRpb24ga2V5LiAgVGhpcyBpcyBnb2luZyB0byBiZSB0aGUgc2FtZSBhcyB3aXRoIERUTFMN Cj5laXRoZXIgd2l0aCBhIHNoYXJlZCBzZWNyZXQgb3IgYW4gYXN5bW1ldHJpYyBrZXkgcGFpciB3 aGVyZSBhIG5ldyBzZXNzaW9uDQo+aXMNCj5lc3RhYmxpc2hlZC4NCg0KQXMgSmltIHNhaWQsIHRo ZSBzZWN1cml0eSBjb250ZXh0IHNob3VsZCBub3QgYmUgcmV1c2VkIHdoZW4gYSBkZXZpY2UgaXMN CnJlc2V0LiBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGF0IGxlYXN0IGhhdmUgc29tZSBjb25zaWRl cmF0aW9ucyBpbiB0aGUNCmNhc2Ugb2YgUFNLIGluIGVtYmVkZGVkIGRldmljZXMgYW5kIHBlcmhh cHMgbWFrZSBzb21lIHJlY29tbWVuZGF0aW9ucy4NCg0KU2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9j b3JlLXdnL29zY29hcC9pc3N1ZXMvNDgNCg0KR8O2cmFuDQoNCg0KPg0KPj4gDQo+PiBDb3VsZCB5 b3UgaGVscCBjbGFyaWZ5IHRoZXNlIGlzc3Vlcz8NCj4+IA0KPj4gVGhhbmtzDQo+PiBDaHJpc3Rp YW4NCj4+IA0KPj4gLS0NCj4+IFRvIHVzZSByYXcgcG93ZXIgaXMgdG8gbWFrZSB5b3Vyc2VsZiBp bmZpbml0ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlcg0KPnBvd2Vycy4NCj4+ICAgLS0gQmVuZSBH ZXNzZXJpdCBheGlvbQ0KPg0KDQo= From nobody Mon Jan 9 14:34:40 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69674129894; Mon, 9 Jan 2017 14:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b442QOpuHbI3; Mon, 9 Jan 2017 14:34:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3580A126D74; Mon, 9 Jan 2017 14:34:36 -0800 (PST) X-AuditID: c1b4fb30-d248a98000007ae2-cf-58740ffac44c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id CE.7E.31458.AFF04785; Mon, 9 Jan 2017 23:34:34 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.95]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Mon, 9 Jan 2017 23:33:57 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "core@ietf.org" Thread-Topic: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers Thread-Index: AQHSZmq0sIasQcnGlU2tRoaM5elaSqEp0DQAgADm4YCABg0BgA== Date: Mon, 9 Jan 2017 22:34:40 +0000 Message-ID: References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <20170105132327.26vmqpqam26uvaoy@hephaistos.amsuess.com> <004401d267ca$58e6ef70$0ab4ce50$@augustcellars.com> In-Reply-To: <004401d267ca$58e6ef70$0ab4ce50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <8B104BA972EB6B4F820F56C08E0220BE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7n+4v/pIIgy2TlC2WX3jOYrHv7Xpm i2n/zrBYrJ7+nc2BxWPjnOlsHlv332XyWLLkJ1MAcxSXTUpqTmZZapG+XQJXxtw/RxgLpqlV LFnfz9TAOEO1i5GTQ0LARGJPxweWLkYuDiGBdYwSG47eY4NwFjFKXFvwgg2kik3AReJBwyMm EFtEIF/i188OsA5mgSZGifnL5oIlhAUiJPp7brNCFEVK7Dh6gR3CdpJY9n09WA2LgIrEjik3 wIbyClhIXJq/hhVi21ZGicm7bjKDJDgFHCRmn50CNohRQEzi+6k1YM3MAuISt57MZ4K4W0Bi yZ7zzBC2qMTLx//A6kUF9CSWP18DFVeSaFzyBCjOAdSrKbF+lz7EGGuJ9n0vWCFsRYkp3Q/Z Ie4RlDg58wnLBEbxWUi2zULonoWkexaS7llIuhcwsq5iFC1OLU7KTTcy0kstykwuLs7P08tL LdnECIzHg1t+G+xgfPnc8RCjAAejEg9vwdLiCCHWxLLiytxDjBIczEoivNu5SiKEeFMSK6tS i/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYIxwcLcXEJlqyXlALaf+ inGz4crgZYVOqZ9fnw9b8I6zoXFJgfiuTHd99bu+AdevNhu3FQW35CoKaV3dknrjUQLDql27 5KY/PMEe9O+lxfzTPyzrmw9vfuc30TA7wdpcpdOxzUNY1Hsn45kQyWv/vQOOaR2bLW8s47xk iVjV6e7V228udljeq8RSnJFoqMVcVJwIAFRtq47DAgAA Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" Subject: Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:34:38 -0000 QWRkaXRpb25hbCBhbnN3ZXJzLg0KDQpPbiAyMDE3LTAxLTA2IDA0OjA5LCAiSmltIFNjaGFhZCIg PGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+IEZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gQW1zw7xzcw0KPj4gU2VudDogVGh1cnNkYXksIEphbnVh cnkgMDUsIDIwMTcgNToyMyBBTQ0KPj4gVG86IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJp dHlAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbY29yZV0gT1NDT0FQ OiByb2xsLW91dCwgcmVjaXBpZW50IHNlcW5vLCBvcHRpb24gbnVtYmVyLA0KPnNlcXVlbmNlDQo+ PiBudW1iZXJzDQo+PiANCj4+IEhlbGxvIE9TQ09BUCBhdXRob3JzLA0KPj4gDQo+PiBPbiBXZWQs IEphbiAwNCwgMjAxNyBhdCAxMDoxMjoyOUFNICswMTAwLCBDaHJpc3RpYW4gQW1zw7xzcyB3cm90 ZToNCj4+ID4gZ2V0dGluZyBmYW1pbGlhciBlbm91Z2ggd2l0aCBPU0NPQVAgdG8gc3RhcnQgYW4g aW1wbGVtZW50YXRpb24sIHRoZXJlDQo+PiA+IGFyZSBzb21lIGFyZWFzIHdoaWNoIGFyZSBub3Qg ZnVsbHkgY2xlYXIgdG8gbWUgZnJvbSByZWFkaW5nIHRoZSBkcmFmdDoNCj4+IA0KPj4gc29tZSBt b3JlIHF1ZXN0aW9ucyBjYW1lIHVwOg0KPj4gDQo+PiAqIDUuMiBnaXZlcyB0aGUgY29udGV4dCBm b3IgdGhlIEVuY19zdHJ1Y3R1cmUgYXMgIkVuY3J5cHRlZCIsIHdoaWxlDQo+PiAgIGNvc2UtbXNn LTI0IHdvdWxkIHNldCBhICJFbmNyeXB0MCIuIFdoeSBkb2VzIHRoYXQgZGlmZmVyIGhlcmU/DQo+ DQo+SSB0aGluayB0aGF0IHRoZXkgKGFuZCBJKSBtaXNzZWQgYSBjaGFuZ2UgaW4gdGhlIENPU0Ug ZG9jdW1lbnQuICBUaGlzIHdhcw0KPndoYXQgaXQgdXNlZCB0byBiZS4NCg0KQ29ycmVjdCwgYSBy ZW1uYW50IGZyb20gYW4gb2xkZXIgdmVyc2lvbiBvZiBDT1NFLg0KDQo+DQo+PiANCj4+ICogNS4g c3RhdGVzIHRoYXQgdGhlICcidW5wcm90ZWN0ZWQiIGZpZWxkIFsuLi5dIFNIQUxMIGJlIGVtcHR5 JywgYnV0DQo+PiAgIGFib3ZlIHN0YXRlcyB0aGF0IHNpZCAnY2FuIGJlIHBsYWNlZCBpbiB0aGUg dW5wcm90ZWN0ZWQgaGVhZGVycw0KPj4gICBidWNrZXQnLiBIb3cgZG8gdGhvc2Ugc3RhdGVtZW50 cyBnbyB0b2dldGhlcj8NCj4NCj5Mb29rcyB0byBtZSBsaWtlIHdoZW4gdGhleSBhZGRyZXNzIG15 IGNvbW1lbnQgb24gdGhpcyB0aGV5IG9ubHkgZ290IGl0DQo+cGFydGx5IGNvcnJlY3RseS4gIElm IHlvdSBsb29rIGJlbG93LCBpdCBzYXlzIHRoYXQgJ3NpZCcgaXMgZ29pbmcgdG8gYmUgYQ0KPnBy b3RlY3RlZCBoZWFkZXIgZmllbGQuDQoNCg0KT25lIHN0YXRlbWVudCBpcyBhYm91dCB0aGUgc2Vj dXJpdHkgcmVxdWlyZW1lbnRzLCB0aGUgb3RoZXIgaXMgYWJvdXQgdGhlDQpmb3JtYXQgdXNlZC4g V2UgYWxyZWFkeSB0cmllZCB0byBjbGFyaWZ5IHRoaXMgKGlzc3VlICMxNSkgYnV0IGFwcGFyZW50 bHkNCm5vdCBzdWZmaWNpZW50bHkgd2VsbCBzbyBpdCBpcyByZW9wZW5lZDoNCg0KaHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvb3Njb2FwL2lzc3Vlcy8xNQ0KDQoNCj4NCj4+IA0KPj4gKiBIb3cg YXJlIHNlcXVlbmNlIG51bWJlcnMgKHdoaWNoIGFyZSBzb3J0ZWQgaW50ZWdlcnMpIG1hcHBlZCB0 byBwYXJ0aWFsDQo+PiAgIElWcz8gV2hpY2ggZW5kaWFubmVzcyBpcyB1c2VkPyAoVGhlIHBhZGRp bmcgZGlyZWN0aW9uIGZvbGxvd3MgZnJvbQ0KPj4gICBjb3NlLW1zZy0yNCAzLjEpLg0KPj4gDQo+ PiAgIEknZCBhc3N1bWUgKGFuZCBpbXBsZW1lbnQpIHRoYXQgYmlnLWVuZGlhbiBpcyB1c2VkIGJl Y2F1c2UgaXQgYWxpZ25zDQo+PiAgIG5hdHVyYWxseSB3aXRoIENPU0UncyBsZWZ0LXBhZGRpbmcs IGJ1dCBhcyBJIHNlZSBpdCwgdGhhdCBkb2VzIG5vdA0KPj4gICBzdHJpY3RseSBmb2xsb3cgZnJv bSB0aGUgZHJhZnQuDQo+DQo+DQo+SSB0cmVhdGVkIHRoZSBzZXF1ZW5jZSBudW1iZXIgYXMgYSBu ZXR3b3JrIGJ5dGUgb3JkZXIgaW50ZWdlciBwYWNrZWQgaW50bw0KPnRoZSBzbWFsbGVzdCBwb3Nz aWJsZSBieXRlIHN0cmluZy4gIEZvciB0aGUgc2FtZSByZWFzb25zIHRoYXQgeW91IGdhdmUuDQoN Cg0KSW5kZWVkLCB0aGlzIHdhcyBub3QgZGVmaW5lZCwgd2Ugd2lsbCB1cGRhdGUgdGhlIGRvY3Vt ZW50IHRvIHJlcXVpcmUNCm5ldHdvcmsgYnl0ZSBvcmRlci4gU2VlICBodHRwczovL2dpdGh1Yi5j b20vY29yZS13Zy9vc2NvYXAvaXNzdWVzLzQ0DQoNCg0KPg0KPj4gDQo+PiAqIEkgY29uY2x1ZGVk IHRoYXQgdGhlIHRhZyBpcyBhbHdheXMgdGhlIGxhc3QgYnl0ZXMgb2YgdGhlIGNpcGhlcnRleHQN Cj4+ICAgZnJvbSBleGFtcGxlIEEuNCwgYnV0IGRpZCBub3QgZmluZCB0ZXh0IGluIHRoZSBzcGVj IHRvIHN1cHBvcnQgdGhhdDsNCj4+ICAgd2hhdCBtYWRlIG1lIGVzcGVjaWFsbHkgdW5zdXJlIGFi b3V0IHRoaXMgaXMgdGhhdCB0aGUgQ09TRV9FbmNyeXB0MA0KPj4gICBkZWZpbml0aW9uIG9mIGNv c2UtbXNnLTI0IDUuMiBvbmx5IG1lbnRpb25zIHRoZSBjaXBoZXJ0ZXh0IHRoZXJlLA0KPj4gICB3 aGljaCBtYXkgYmUgbmlsLg0KPg0KPkZlZWwgZnJlZSB0byBhc3N1bWUgdGhhdCB0aGUgdGFnIGlz IGFwcGVuZGVkIHRvIHRoZSBlbmQgb2YgdGhlIGNpcGhlcg0KPnRleHQuDQo+VGhpcyBpcyBnb2lu ZyB0byBiZSBkZXBlbmRlbnQgb24gdGhlIGFsZ29yaXRobSB0aGF0IGlzIGJlaW5nIHVzZWQgYW5k IGlzDQo+ZG9uZSBpbiBvdGhlciB3YXlzIGZvciBzb21lIGRpZmZlcmVudCBhbGdvcml0aG1zLiAg Rm9yIGV4YW1wbGUsIHRoZXJlIGlzDQo+b25lDQo+YWxnb3JpdGhtIChTSVYgbW9kZSkgd2hlcmUg dGhlIHRhZyBpcyB0aGUgSVYgYW5kIGlzIHRodXMgZnJlcXVlbnRseQ0KPnByZXBlbmRlZCB0byB0 aGUgY2lwaGVyIHRleHQuDQoNCkFzIEppbSBzYXlzLCB0aGlzIGlzIGFsZ29yaXRobSBkZXBlbmRl bnQuIFdlIHdpbGwgY2xhcmlmeSB0aGlzLg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvb3Nj b2FwL2lzc3Vlcy80OQ0KDQpHw7ZyYW4NCg0KPkl0IGlzIHRydWUgdGhhdCB0aGVyZSBpcyBhIHdh eSBub3QgdG8gaW5jbHVkZQ0KPnRoZSBjaXBoZXIgdGV4dCBhcyBwYXJ0IG9mIGEgQ09TRSBtZXNz YWdlLCBob3dldmVyIHRoaXMgaXMgZm9yIGEgY2FzZSBvZg0KPmRldGFjaGVkIGNpcGhlciB0ZXh0 LiAgRXZlbiBpbiB0aGF0IGNhc2UgdGhlIHRhZyBpcyBjYXJyaWVkIGFzIHBhcnQgb2YgdGhlDQo+ Y2lwaGVyIHRleHQgaXQgaXMganVzdCBjYXJyaWVkIHNvbWVwbGFjZSBlbHNlLiAgT1NDT0FQIGRv ZXMgbm90IHVzZQ0KPmRldGFjaGVkDQo+Y2lwaGVyIHRleHQuDQo+DQo+PiANCj4+IEJlc3QgcmVn YXJkcw0KPj4gQ2hyaXN0aWFuDQo+PiANCj4+IC0tDQo+PiBUbyB1c2UgcmF3IHBvd2VyIGlzIHRv IG1ha2UgeW91cnNlbGYgaW5maW5pdGVseSB2dWxuZXJhYmxlIHRvIGdyZWF0ZXINCj5wb3dlcnMu DQo+PiAgIC0tIEJlbmUgR2Vzc2VyaXQgYXhpb20NCj4NCg0K From nobody Mon Jan 9 23:09:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941E9129AF2; Mon, 9 Jan 2017 23:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k2YW2lBAvYM; Mon, 9 Jan 2017 23:09:03 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B807B129AF1; Mon, 9 Jan 2017 23:09:03 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id F263D45E64; Tue, 10 Jan 2017 08:09:00 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E6B1927; Tue, 10 Jan 2017 08:08:59 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 95622373; Tue, 10 Jan 2017 08:08:59 +0100 (CET) Received: (nullmailer pid 1659 invoked by uid 1000); Tue, 10 Jan 2017 07:08:58 -0000 Date: Tue, 10 Jan 2017 08:08:58 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="olgo3u3bcwz4fz6n" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP: [...], sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 07:09:05 -0000 --olgo3u3bcwz4fz6n Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 09, 2017 at 10:02:04PM +0000, G=F6ran Selander wrote: > >> is there any way to recover from such a situation, eg roughly by the > >> recipient saying "I've heard all that, start at N or I can't trust y= ou > >> at all"? > >>=20 > >> It might well be a bad idea to allow such a thing (at very least, th= at > >> information needs to be authenticated), so right now this is primari= ly > >> a question about whether there is a mechanism I missed, and whether > >> there should be guidance considering the embedded use cases. > > > >The reset of the nonce is going to be a problem under all > >circumstances if you go back to a clean factory state and you cannot > >store the appropriate nonce in non-volatile memory. >=20 > As Jim said, the security context should not be reused when a device is > reset. I agree that we should at least have some considerations in the > case of PSK in embedded devices and perhaps make some recommendations. My concern is not only for resets, but for persistence in general; flash based devices (as in embedded flash with a few thousand erase cycles). Writing to persistent memory on every transaction (shutdowns are not clean on those devices in my experience) is not practical there. In its sender context, a device could just lease out sequence numbers =66rom flash and leap ahead on reboot; eg. it would read the last used sequence number as 1024 on reboot, write 2048, and count from 1025 to 2048 in RAM while sending until flash gets written to again. A power outage then does no more harm than wasting some sequence numbers. In its recipient context, if the device only stores something like the end of its receive window on flash, it'll take the communication partner up to window-size failed attempts (which it might not even be allowed to repeat) to get in the clear. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --olgo3u3bcwz4fz6n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlh0iIcACgkQOY0REtOk veEVdw//WIPa/9sF+iAO5KZgihayIxucGji2ayLVtDhjV+OToy0Xf3YlvKlGzQ44 kqvsvdDH+tcGLHyEwwb8Pv/7kx2NJMLX+dgKASwHFfuoiba63nqQjPhMQS+keKV/ ylQ7y+OP41g0jtRdAWU5CRMJljAEC9+5VKqBWpUhzr0ce1u39YeHdhi+93xkVJTt 4twEORMHzd4EZJdJ3i7Aniy9A221j8PxF/sGxk+aqX6tkYkrsW5zuz0ErkavVnoU bQofcaMPPDTjY35+Mnu4i9vOlWm+zsgkylVboh+GKY26PPNo3K8J8NRNCFMaZK2P MIWQTnTeAGBgIhfbxzEUtzDg16FGY6T39TSae3j3of2rGRuiOquoLaXf/qnnbPak q6v3ImYR5D4/efVsQSf/f3FLsgE3AcbJIdx3yxI5ET9snUSSDqY/NnAJJU3bwsmx x3gzVStuI2vOhktQjYIUrvU97JprrxOz5QIWV4Y8Yv0A+97sxE27P/+vhIqVCVwS EmPTZE3U24TkRUx66modqm7s/0eXTW/3qXhFzYlYZZ9XniSjFdiXHMsyPf3E5gcA jAWlq+26mJcdeBXSBE7o+BnoBb5dS+AV6imDUF2PRmgQSaEjSmI7v9iHV4IbH0GF LyGVgkKxUcTUV5oQlI4lHniSmsq1yPEJhDL9vUM2DjuQtD1U2Rw= =S0aC -----END PGP SIGNATURE----- --olgo3u3bcwz4fz6n-- From nobody Wed Jan 11 06:03:58 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85204129C5D for ; Wed, 11 Jan 2017 06:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, 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 jJYNxMByheaU for ; Wed, 11 Jan 2017 06:03:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42D8129B0C for ; Wed, 11 Jan 2017 06:03:55 -0800 (PST) Received: from [192.168.91.167] ([84.14.163.130]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lj1jy-1d1C1G3afe-00dEdW for ; Wed, 11 Jan 2017 15:03:53 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 11 Jan 2017 15:03:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="099NSQSBiN6vjSDjbBD9KtnWgPdHxGw3o" X-Provags-ID: V03:K0:SgxmzgGWWeT880pcw3Ky6gUyAUxxNaPYKy3meYICdYNQUK7U+ms XF3jrJwAbnxxN9y8Hqk09VxfNTTL/B+Mf19ooeA6rMS1xUGC/k95UqnEZ6rPGWPkiPFZAiT cX5qkRme5faYR9p5fjbikPINtmZQUnYHWl2UKSzVvIWQRyJokLD04ZE+RrnhoCRFliARf69 Ngt2h6g07hImXG6FhNtHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:PpMJylo/hVs=:S9ljPS9RsIWemlIU0bLplk wiJpAahNQkJqkZ9Wa6os2wuxUOo6tdkMW65SQ9TGbCZg+OIwdqr16gz5y49eA+HuWEgldQucj jmqhzH606an4w1z4a7fNaHupK5uCCebFMvBwxoHsSS3Q4rXj0zlphQ8lpi9e4lYTcjHWmUH8z VpvrYBiFCm6Q9IXyhj96E8vcuN+NYC625GSMbr9kl7GXHHaC1BX53L4/StQp+KultzUPb2gmA aT8TH4PsppiYW3jwS+2Heyhb7dLiJsniguagGHh74z7YrTj91HdcJ04SWGGgQ0YW1Oo0ABjfo wyOjGe2wMpVNDrnoGKzFgLJ3JfKRqtSuNQjx4Pr0caV9e5p+wg8zB/4JrFDCz290e3xmiSXIU dZP/wcDciiUU/cv7YRNYPI8CYSGmeMPWzB05jVnuJVx8pvj3C/IN3MYKeYzbkE/BoaiqXfgEO JZz0BYLYM8e49t0VYhzoJ5gu6pHknmMVz9+C/mdOlvT9wbUB2dI6jq14Pu7D7Wde3u+8qoHSo siZ+BzwCwqQ709vOeM3t1jukcP1cMW7LE0/ijI6nDh4ZHZTp/SfsxQJvKFEv0g0KeFfLmHOKz SUDpaOdcUeSEJLxp7vzkbD3JHclR36EICBP4cpzUqTphEdsZhe2QQqnc4hH9Mmd1JpEYyZYRE e1IqURnCjv0ynKPUJWp59Rq5wv8SEc+gJSQz+WyFXs7ctvTdy1sw9zNFpBIOJIJuviWJutUkj fAnKh2hGEiIyrRGD0gLiWK14Pz5+b1xJzg+DG1WbMjDyPzer1v3H8WkkLPM= Archived-At: Subject: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:03:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --099NSQSBiN6vjSDjbBD9KtnWgPdHxGw3o Content-Type: multipart/mixed; boundary="oT4u1n6sxr3KJQUOpjJMd2wqDosJWgQPi"; protected-headers="v1" From: Hannes Tschofenig To: "core@ietf.org WG" Message-ID: Subject: Lifetime (lt) and Less Than (lt) --oT4u1n6sxr3KJQUOpjJMd2wqDosJWgQPi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I noticed that https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 uses the parameter lt for lifetime and https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for Less Than. Both use the same parameter acronym (lt). Can this cause problems? Should we change lifetime to lft? Ciao Hannes --oT4u1n6sxr3KJQUOpjJMd2wqDosJWgQPi-- --099NSQSBiN6vjSDjbBD9KtnWgPdHxGw3o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYdjtGAAoJEGhJURNOOiAtc3sIAJJK/Q7NibbAQAK6XxOBMFOk ZAFXBM9rvpqDfIe2RoXrudJmo4kLi4qrWwxz96wh1AVYUAa9Qf5fgbLWXml1sPdp MpoTBQL4iqLsucsQvB51UmmLQI7IxHHgb+iOujWHaHMa+5+44Bam75OVHw3UGWe8 AeDhSG/F7aqFZ5/wUQyb9nWWFkaUgtrQrF3McPNuSL5m4ZE1UuPOI7LmLqjfCTCY 8lPFxqlMK4+zopqCojTMY2l7kvjDZeqEhGnYYDOnyo4ykpzo5vu9QT/8VjU0N3Rk iyApqxdWAuslko6hhhsrm9AlVBHCqIWYzNJrb0HFk/YX8zsPYBgly5t7BuYbQEc= =ISyQ -----END PGP SIGNATURE----- --099NSQSBiN6vjSDjbBD9KtnWgPdHxGw3o-- From nobody Wed Jan 11 06:46:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1589C129B3A for ; Wed, 11 Jan 2017 06:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaWi5hCgiQvo for ; Wed, 11 Jan 2017 06:46:24 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D41B129518 for ; Wed, 11 Jan 2017 06:46:24 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 14so37492701pgg.1 for ; Wed, 11 Jan 2017 06:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fESwA14++2l0JTzyVr4k2+262sQqyfgnoK9B6Y0vHsE=; b=LGdDa7QTXZajnyWzZSjvf/wUNx5i71/0EifLeTRI40Bd6Bjb1/2z6HQ7YC8+p/6kbu gqGD0EruUffki/JoPRAay8mgjVWDWdUhCQx85jCRKpkqXWU2xkb2lOxh+nVYTsZRH8OW nvg/DZSp8THIc0N+VebIKINgqEagOcaLk3MKNkDjFFmCN8ScH6nnaiSs4QhehJw1hZqi CBkeNdGyzTAMPWW42t6/lTgoCB9WOBbOEM8ePxhBtrHrWyN7Rm5p8MNwzy3Nm7fB8aLt MCPVF4kPoQGStw4EOzrFip0R6ISg8N/C3WQg5LejNxsk4llrbUSQooeMaLF/7atidWy4 7HrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fESwA14++2l0JTzyVr4k2+262sQqyfgnoK9B6Y0vHsE=; b=idegSwA1B4W/S/Uf6yp4br/dhkjCywFTmFy8kCNOxykXvOBhMW6kSjdvU4Dr/j86op Ly48q6ZGAi7GwOoWQ/KLn0nDQbBGgveqz04guCc+k9qRtjJvke71abGR6uA55MlGUK4g voxvRc/BfWt/w+Sfl96I3kSYfMATaRhyNKOIho0YOWfaoIf3zbh8jfU0MspdE4wRJLRR zZJuUZHHwPq4fIq5fu+xikLawh0UwrkU3t3ZSE5NagviBCI9u4WZDFWH4/IA4vGImtO2 f1SxewiOySkhVFCor7EiRZkx+HYzc4GCMl4Q0phvuwceYi6oshgn8NB8t38LgSkxO0Ah qH4Q== X-Gm-Message-State: AIkVDXJGITPjLNB1nT3cgNEqrz1VSYKmQZWRQaOjaAiKZ2V+Nj6/2s9t6rsYm+P68FnF0A== X-Received: by 10.98.67.89 with SMTP id q86mr10800009pfa.178.1484145984034; Wed, 11 Jan 2017 06:46:24 -0800 (PST) Received: from wsip-98-173-88-26.lv.lv.cox.net (wsip-98-173-88-26.lv.lv.cox.net. [98.173.88.26]) by smtp.gmail.com with ESMTPSA id r21sm14460419pfd.95.2017.01.11.06.46.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 06:46:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Wed, 11 Jan 2017 06:46:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:46:26 -0000 Hi Hannes, I never noticed that before! I don't think there would ever be a situation where you would use them = in the same request, so I don't think we need to change either one. I think it's a similar idea as 2 URIs with a different path component: /example/sensor/a /example/sensor/b /rd?lt=3D100 /some/sensor/not-an-rd?lt=3D25.3 Does this make sense? Best regards, Michael > On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I noticed that > https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 uses > the parameter lt for lifetime and > https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for = Less > Than. >=20 > Both use the same parameter acronym (lt). >=20 > Can this cause problems? Should we change lifetime to lft? >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 11 07:51:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F69B1294BD for ; Wed, 11 Jan 2017 07:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGHDeq4MYMjp for ; Wed, 11 Jan 2017 07:51:29 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7BD12949D for ; Wed, 11 Jan 2017 07:51:28 -0800 (PST) Received: from devpc ([84.14.163.130]) by mrelayeu.kundenserver.de (mreue004 [212.227.15.168]) with ESMTPSA (Nemesis) id 0MC5LA-1cIZjx3wsy-008raE; Wed, 11 Jan 2017 16:51:26 +0100 From: "David Navarro" To: "'Michael Koster'" , "'Hannes Tschofenig'" References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> In-Reply-To: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> Date: Wed, 11 Jan 2017 16:51:21 +0100 Message-ID: <003501d26c22$8e7fe540$ab7fafc0$@ioterop.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: AQHDA97OwTF3NL3tcb9OZvxPX0MWQAKybv1coTymt0A= Content-Language: fr X-Provags-ID: V03:K0:z5/hy4ZFNlZjRhTAFRju4q7i/z0RDYwTSYZCJo8n7luofQFmbgv wDLfP9G9yeMYgyJquuOQS9PbttVE5438ZihPRt+Gxc+y+7vj7C5Iqbt+0ehnZDBGlODGXlg j6l94NCh8n/7YiLGnrLSul/jo8QDMGCPw3T4QDZubJEFSTvfrhBlQDbrrXYh2wa9xvQt/hq JuxCNtaG6tMcOg/GurOoA== X-UI-Out-Filterresults: notjunk:1;V01:K0:TUvCU8cYJmI=:Y7mG+ffA9q4sLpxtBNIuoi kJdtuPyOLYFz+oV1A/ZGeyMkF9Dli9jQ2QiyEGDp9Zs+q8bRaVSU2ujiKLBRcbZDFbPhLGqXR AJzPw788HiqaTqXRJRQEGziBMrJlvW8/5GE6fTImL3RddMCbT/KgK6JZSVDPaFf5XIXAULbD0 AMbLUr0wwzgw0N65So4YqTcIb8fw2VPMN3upMcROrQ6Iixq6jb6Lmr4dT0isohKe80P3LDY6Y cpy+CI1+fO2+ILv//zngxa9c2FGVUTAUZfL5wht7jB6Pp+AIfxVdQclAV+Yx1ivoCsL5c67JE ezdNLyrpyihCFOlCsMH3q94ADFKixlzrAv5LXCymPyh9WNXXjIKi28rmxBRZoI9WNWYDsyTR9 bP/Eo8PLKI1mTTzbmu6VzOBi+545Vll/VKZ3e73+0Mh2yC+kfI7nTUm9ggvpdd2Te6zsaCkHl jPwrB5F9h1OJ09UqEjgPIXLi6sMh4O96cX/6UQrdjUc3sC9+tpaq7r1fZGHm3ERxPrLcHopYv 3FJ1zmcI9c2QrobI0O6raCI0MxDDBCgQPbkPlnAjZM+pKeAaeB5T6yk/BtPxCK+LUit7IPiC0 OHuVIW+OWFQ80eHbXoCkbXaPA6+NQVR3E+M2bhykdIp/T1JldwyH0c6GnDN/lKkDgJxbFnny6 GvanYvFoE4raaGTogVvsdxC9za9xRcXK2F8CfPNvT01fOFPVc3G8Qks7Yy/RQY03ynMoHWyH6 IxNPICGmZQ7+SAsf Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:51:31 -0000 Hi Michael, I agree there is currently no risk of collision. However I think it = would be better to avoid future problem while we can. For instance one may imagine a lifetime attribute in an observation = request so that this observation is automatically cancelled by the server. /sensor/temperature/value?lt=3D10>=3D30<=3D86400 Regards, David Navarro -----Message d'origine----- De=A0: core [mailto:core-bounces@ietf.org] De la part de Michael Koster Envoy=E9=A0: mercredi 11 janvier 2017 15:46 =C0=A0: Hannes Tschofenig Cc=A0: core@ietf.org WG Objet=A0: Re: [core] Lifetime (lt) and Less Than (lt) Hi Hannes, I never noticed that before! I don't think there would ever be a situation where you would use them = in the same request, so I don't think we need to change either one. I think it's a similar idea as 2 URIs with a different path component: /example/sensor/a /example/sensor/b /rd?lt=3D100 /some/sensor/not-an-rd?lt=3D25.3 Does this make sense? Best regards, Michael > On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I noticed that > https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 uses = > the parameter lt for lifetime and > https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for=20 > Less Than. >=20 > Both use the same parameter acronym (lt). >=20 > Can this cause problems? Should we change lifetime to lft? >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 11 08:08:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAC129D00 for ; Wed, 11 Jan 2017 08:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulop98CzsRUG for ; Wed, 11 Jan 2017 08:08:31 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FF7129CF2 for ; Wed, 11 Jan 2017 08:08:31 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.207]) by smtp-cloud2.xs4all.net with ESMTP id X48V1u00M4U4Moq0148VZe; Wed, 11 Jan 2017 17:08:29 +0100 Received: from AMontpellier-654-1-131-243.w90-0.abo.wanadoo.fr ([90.0.90.243]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 11 Jan 2017 17:08:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 11 Jan 2017 17:08:29 +0100 From: peter van der Stok To: David Navarro Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:08:33 -0000 I am afraid that I agree with David. could we distinguish with capitals, lifetime is LT? Peter David Navarro schreef op 2017-01-11 16:51: > Hi Michael, > > I agree there is currently no risk of collision. However I think it > would be > better to avoid future problem while we can. > For instance one may imagine a lifetime attribute in an observation > request > so that this observation is automatically cancelled by the server. > > /sensor/temperature/value?lt=10>=30<=86400 > > > Regards, > David Navarro > > -----Message d'origine----- > De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster > Envoyé : mercredi 11 janvier 2017 15:46 > À : Hannes Tschofenig > Cc : core@ietf.org WG > Objet : Re: [core] Lifetime (lt) and Less Than (lt) > > Hi Hannes, > > I never noticed that before! > > I don't think there would ever be a situation where you would use them > in > the same request, so I don't think we need to change either one. > > I think it's a similar idea as 2 URIs with a different path component: > > /example/sensor/a > /example/sensor/b > > /rd?lt=100 > /some/sensor/not-an-rd?lt=25.3 > > Does this make sense? > > Best regards, > > Michael >> On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig >> > wrote: >> >> Hi all, >> >> I noticed that >> https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 uses >> the parameter lt for lifetime and >> https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for >> Less Than. >> >> Both use the same parameter acronym (lt). >> >> Can this cause problems? Should we change lifetime to lft? >> >> Ciao >> Hannes >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 11 08:19:57 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503C3129F01 for ; Wed, 11 Jan 2017 08:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUvBKT1zavco for ; Wed, 11 Jan 2017 08:19:54 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 E49DC129D11 for ; Wed, 11 Jan 2017 08:19:53 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 75so15907947pgf.3 for ; Wed, 11 Jan 2017 08:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Og2osTmt5u1G1xh/ib7+OtdLsVHrk+oYQANjRzBatyo=; b=bVgRq2e7B+bFoNIsnoVUYD5pl54AVhQhsU8PLOoWOat28Nt7xvXMif7eCKBK5hphDs 7md7Ob//bEdv9So2MEV6WRUUjitd4gvvXz90RKuZmmKziZO4qSzCmeojT7SRxorXbNcX Bd3G4ozxv79FYs2gBObQ70bRGc3MEbBam9ptE3SY0Rv7c/E9cMF6CVuKiP4QX3kHeFLs mifF0R6tY7d7/ATD6+qR2TTFDkOslCKKP6SEt//4vQLYsIVOroIGkE40D97MTA0VhzTc ULPiCTxoQcP5ypxEA2cA64OOsGrov0xgvCVrkIB4kHMkeHC4NuJZ3KjsqLjwLxjd6gzM 4HCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Og2osTmt5u1G1xh/ib7+OtdLsVHrk+oYQANjRzBatyo=; b=imR2TGizRsvy6S0YqWESZ1+ndzEkC6B1D/k20XAWUXdZY9FDA3QtuygDn5ObmDjWht dEIxKzNAyxUOLjT5fwwDtwtB/iLx6VU78YPsCvTgl6rCLL1eZAWzgEA7Ln4Niv+0JjUy 9SS47mQLabeUCU58R8wB+64UP1jL8vV8WthtrfMYR+xeXdcemX6rMhPtEN6qu8JkzsQA jYvJp+Kkyyz96FWnOfvPC/viua5rxFnawsm19RoZaXJ/7xG9uCPqSLD+QzjV/vcXAyY6 +DcItivg691qtX4ZfSjPkzlvc6zAiQTeGeELHBtluE81KIVt4mHymhWB/k6GwJErozRB LXIw== X-Gm-Message-State: AIkVDXK4RELhe6MVdkhgdDYmodgEBhb6opM2dWFbhWcGWVHML8pTpgFZacLGEbeTOBPJKQ== X-Received: by 10.84.143.162 with SMTP id 31mr14524083plz.2.1484151593526; Wed, 11 Jan 2017 08:19:53 -0800 (PST) Received: from wsip-98-173-88-26.lv.lv.cox.net (wsip-98-173-88-26.lv.lv.cox.net. [98.173.88.26]) by smtp.gmail.com with ESMTPSA id d69sm15003079pfd.11.2017.01.11.08.19.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 08:19:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Wed, 11 Jan 2017 08:19:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:19:55 -0000 Hi Peter I believe URI parameters are not allowed to be case sensitive. Use of = case is not recommended in general as it's still LT. Best regards, Michael > On Jan 11, 2017, at 8:08 AM, peter van der Stok = wrote: >=20 > I am afraid that I agree with David. > could we distinguish with capitals, lifetime is LT? >=20 > Peter >=20 > David Navarro schreef op 2017-01-11 16:51: >> Hi Michael, >> I agree there is currently no risk of collision. However I think it = would be >> better to avoid future problem while we can. >> For instance one may imagine a lifetime attribute in an observation = request >> so that this observation is automatically cancelled by the server. >> /sensor/temperature/value?lt=3D10>=3D30<=3D86400 >> Regards, >> David Navarro >> -----Message d'origine----- >> De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster >> Envoy=C3=A9 : mercredi 11 janvier 2017 15:46 >> =C3=80 : Hannes Tschofenig >> Cc : core@ietf.org WG >> Objet : Re: [core] Lifetime (lt) and Less Than (lt) >> Hi Hannes, >> I never noticed that before! >> I don't think there would ever be a situation where you would use = them in >> the same request, so I don't think we need to change either one. >> I think it's a similar idea as 2 URIs with a different path = component: >> /example/sensor/a >> /example/sensor/b >> /rd?lt=3D100 >> /some/sensor/not-an-rd?lt=3D25.3 >> Does this make sense? >> Best regards, >> Michael >>> On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig = >> wrote: >>> Hi all, >>> I noticed that >>> https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 = uses >>> the parameter lt for lifetime and >>> https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for >>> Less Than. >>> Both use the same parameter acronym (lt). >>> Can this cause problems? Should we change lifetime to lft? >>> Ciao >>> Hannes >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 11 08:25:24 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D07F129F10 for ; Wed, 11 Jan 2017 08:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAE7J1hw0MxL for ; Wed, 11 Jan 2017 08:25:21 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4A41294CF for ; Wed, 11 Jan 2017 08:25:21 -0800 (PST) Received: from devpc ([84.14.163.130]) by mrelayeu.kundenserver.de (mreue001 [212.227.15.168]) with ESMTPSA (Nemesis) id 0MIDR0-1cRt8k1jI6-003rqe; Wed, 11 Jan 2017 17:25:16 +0100 From: "David Navarro" To: "'Michael Koster'" , References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> In-Reply-To: Date: Wed, 11 Jan 2017 17:25:11 +0100 Message-ID: <003701d26c27$48c09270$da41b750$@ioterop.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: AQHDA97OwTF3NL3tcb9OZvxPX0MWQAKybv1cAdFf7hMBoT7q2wHTy83soRJ/2xA= Content-Language: fr X-Provags-ID: V03:K0:YTOB2N2jW7QTTVVpggYxq4XZKHaC/MKW+fmoiagwtRjvXwUZSBQ HgsEUZCoLQ1KxaYsLZcat3uKxKGJEFnhZUm3NouCGbSxzp3SmOAgaAdK6JKIUmjV0q4M8p9 pGHXyi35cldWo8250+++hd3gnOGsVM4nTSKAIZWsim4Qug/BuvwRn5WAfznZJd1789oVJ5E yf2eezMQYhjtEwuM0Fnmw== X-UI-Out-Filterresults: notjunk:1;V01:K0:eZwcU6ity+8=:zbq0QBdTvzqK1fAxe3X0pE gFFboqr6Xa95F8nOBv5Wz1toNLsEQRtrk9iNrjIYXuPphMLeN6wF4udl4EEJ1Mry4gI7OYDML yJkb1ZiuCYlGQFjLMqwqYwGrZ4pkayLyPrYi7klVUkSlUfqpw3bXlDJrBSEFt/gUi972x6pWC Vn51PbXnavK3+CuocciADbjlJVnAgFR12FqYObGiCAh32og3+5u4iLFZ5XuhxTQpTMSRrROna 73gWqVOTmL4ZXXkhLvyCZ02P0EKIhX16UDdysNzK2Lwvx+EgK+18P0sNUdwyr884MGqvqbNUH +kYpqWnscq7nzx7CGV059/LTUNwprZ5zZ8R0uiNWuZcz1t3uTJ2jccB1SkU3ZUWjDL+u/wggA TUGS4ZhqyqaYQmROGL8r4fZGfUBJ4w1MkdiWZEjURMAxJEMb+pvWLIoYqShwZL1LyyIVWsHf8 LwzQxC9hf5QXYQX2GvXFbw0sTJawB9xZGby2D3EotPCtRopNaK/zdXKgk+KfsWnJMDi3eqVNx 21E0t49bUv4Jxnn2XHxiPGNug3FEV/kVd7fUyJaHo7gChRJ8aLEIhowQZnoROrBvkXITVBmrI zXvNczVIxgooPAm7IpqskWSuf4jvkE88Yf8qT52NMzi9vd20j4osI7BBtzQAyv9R/nK1Q4ewG iTx0hbfAgwkFKwCFtNEBCrCJa3DLMlJSbHNSRxfkpUJFr5PJELaS7q8zMsPJZi/yS+ahKHK/W +31s5UgOvApAEvjE Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:25:23 -0000 Hi, What about 'lft' for lifetime ? Regards, David Navarro -----Message d'origine----- De : Michael Koster [mailto:michaeljohnkoster@gmail.com]=20 Envoy=C3=A9 : mercredi 11 janvier 2017 17:20 =C3=80 : consultancy@vanderstok.org Cc : David Navarro ; Hannes Tschofenig = ; core@ietf.org Objet : Re: [core] Lifetime (lt) and Less Than (lt) Hi Peter I believe URI parameters are not allowed to be case sensitive. Use of = case is not recommended in general as it's still LT. Best regards, Michael > On Jan 11, 2017, at 8:08 AM, peter van der Stok = wrote: >=20 > I am afraid that I agree with David. > could we distinguish with capitals, lifetime is LT? >=20 > Peter >=20 > David Navarro schreef op 2017-01-11 16:51: >> Hi Michael, >> I agree there is currently no risk of collision. However I think it=20 >> would be better to avoid future problem while we can. >> For instance one may imagine a lifetime attribute in an observation=20 >> request so that this observation is automatically cancelled by the = server. >> /sensor/temperature/value?lt=3D10>=3D30<=3D86400 >> Regards, >> David Navarro >> -----Message d'origine----- >> De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster = >> Envoy=C3=A9 : mercredi 11 janvier 2017 15:46 =C3=80 : Hannes = Tschofenig=20 >> Cc : core@ietf.org WG =20 >> Objet : Re: [core] Lifetime (lt) and Less Than (lt) Hi Hannes, I=20 >> never noticed that before! >> I don't think there would ever be a situation where you would use=20 >> them in the same request, so I don't think we need to change either = one. >> I think it's a similar idea as 2 URIs with a different path = component: >> /example/sensor/a >> /example/sensor/b >> /rd?lt=3D100 >> /some/sensor/not-an-rd?lt=3D25.3 >> Does this make sense? >> Best regards, >> Michael >>> On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig=20 >>> >> wrote: >>> Hi all, >>> I noticed that >>> https://tools.ietf.org/html/draft-ietf-core-resource-directory-09=20 >>> uses the parameter lt for lifetime and >>> https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for=20 >>> Less Than. >>> Both use the same parameter acronym (lt). >>> Can this cause problems? Should we change lifetime to lft? >>> Ciao >>> Hannes >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 11 08:47:22 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91175129F2F for ; Wed, 11 Jan 2017 08:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLaxsmcISWPm for ; Wed, 11 Jan 2017 08:47:18 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9656129F03 for ; Wed, 11 Jan 2017 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0BGlDZL006700; Wed, 11 Jan 2017 17:47:13 +0100 (CET) Received: from [192.168.217.124] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tzFDK3WhMz3Zlp; Wed, 11 Jan 2017 17:47:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Wed, 11 Jan 2017 17:47:12 +0100 X-Mao-Original-Outgoing-Id: 505846032.711539-d195b8419cf23ea6256c35d92dae316d Content-Transfer-Encoding: quoted-printable Message-Id: <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> To: Michael Koster X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:47:20 -0000 On 11 Jan 2017, at 17:19, Michael Koster = wrote: >=20 > I believe URI parameters are not allowed to be case sensitive. They sure are (how would you do base64 otherwise?) > Use of case is not recommended in general as it's still LT. I think the attempt to do case-insensitive got out of fashion with = FORTRAN 66. (Yes, we still have it for domain names, but these aren=E2=80=99t that = much younger :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 11 08:56:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C206B1295D9 for ; Wed, 11 Jan 2017 08:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkrVmdMDb9aW for ; Wed, 11 Jan 2017 08:56:00 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 CE91C128AB0 for ; Wed, 11 Jan 2017 08:56:00 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id b22so16844777pfd.3 for ; Wed, 11 Jan 2017 08:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ADpDgvxJ5fbhzGtujyhe5gWyxSZOs5HeIC8veOhkzS8=; b=r6fRGgvucz5QSSPHxIkrc7Br31szn1OGyTRLayb4IxiGO7b/ZiBrEHZdWpKa1KpoDQ RPxaAFhbZYbg636b09mEIqzHdvbB6E/bchkjVksWtggkzv2ZoMBIpPOeg/iXDNLq9B0W dxgotfo1QGEKyhLC1TI2rzxMdy++dUQIR9fYElGKzZi9+LXnvW19okmVhgzYWuKOTjBg gUgam2ISmlPC0TqmxYy+GdufkoxD5B9Exz8+iH9fyTwINdpKEBXMdCCLE0JpUWXH8Ugy Ly134I8zDSkgYsuntK49ldeNJVR44LcYbOkD0YUWOGzZlog+HkPbvZhFgCUGABbvQmgv 3ziw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ADpDgvxJ5fbhzGtujyhe5gWyxSZOs5HeIC8veOhkzS8=; b=SyBTIIoZekXmN6v8T+mwcbrBj5+E0Ny+J5N7xYAQ5wEGl2D2fYnuQmdEniSp49jH0q n+W5W2WgrUyL92oEHnWX+pP25RhFmOnpY+0j7YGoqNrG5mwV8uBI/WmPL56W6Dn15E0y M6k3HxFcAbUe8WRO3Dm3EA/mXTLmQBgT6v2kMWm/2z1eq/8d7ezjZVyCpR7diKvxd92h KTPJzrnO/lCiKPuNagJd8H8QVrIMw5ASF1rG/UvOvRNpXi0YDbg0CTAoESH1YSxLy1AE 8J+BQKHTxhrtNTzfYVr/jX1GmPYx70Q+Hz9grS7vECaD0JBMWNy1XV+CPQKzvjT7Wq4N ALlg== X-Gm-Message-State: AIkVDXIQwKPcaKX9Uvw9Asrgt/c1P58Ht8P7AUt9AkIY1jSEztiAt8753FTq2/3Z76lS3g== X-Received: by 10.84.142.1 with SMTP id 1mr2892741plw.90.1484153760452; Wed, 11 Jan 2017 08:56:00 -0800 (PST) Received: from wsip-98-173-88-26.lv.lv.cox.net (wsip-98-173-88-26.lv.lv.cox.net. [98.173.88.26]) by smtp.gmail.com with ESMTPSA id h17sm15142160pfh.62.2017.01.11.08.55.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 08:55:59 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8776EDA9-B588-42E4-B2A0-0E27BB9A720D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> Date: Wed, 11 Jan 2017 08:55:57 -0800 Message-Id: <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:56:02 -0000 --Apple-Mail=_8776EDA9-B588-42E4-B2A0-0E27BB9A720D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK sorry, I was thinking about this in RFC6690 which refers to something = a little different: reg-rel-type =3D LOALPHA *( LOALPHA / DIGIT / "." / "-" ) I still would not recommend only changing the case to differentiate. Carsten, do you think this is a potential conflict and should be = changed? Best regards, Michael PS FORTRAN66? I'm not that much younger either ;-) CamelCase is going out = of style anyway > On Jan 11, 2017, at 8:47 AM, Carsten Bormann wrote: >=20 > On 11 Jan 2017, at 17:19, Michael Koster = wrote: >>=20 >> I believe URI parameters are not allowed to be case sensitive. >=20 > They sure are (how would you do base64 otherwise?) >=20 >> Use of case is not recommended in general as it's still LT. >=20 > I think the attempt to do case-insensitive got out of fashion with = FORTRAN 66. > (Yes, we still have it for domain names, but these aren=E2=80=99t that = much younger :-) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --Apple-Mail=_8776EDA9-B588-42E4-B2A0-0E27BB9A720D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK sorry, I was thinking about this in RFC6690 which refers = to something a little different:

reg-rel-type   =3D LOALPHA *( LOALPHA / DIGIT / "." / "-" =
)

I still = would not recommend only changing the case to differentiate.

Carsten, do you think = this is a potential conflict and should be changed?

Best regards,

Michael

PS
FORTRAN66? I'm not that much younger either ;-) CamelCase is = going out of style anyway


On Jan 11, 2017, at 8:47 AM, Carsten Bormann <cabo@tzi.org> = wrote:

On = 11 Jan 2017, at 17:19, Michael Koster <michaeljohnkoster@gmail.com> wrote:

I believe = URI parameters are not allowed to be case sensitive.

They sure are (how would you do = base64 otherwise?)

Use of case is not recommended in general as it's still = LT.

I think the attempt to do = case-insensitive got out of fashion with FORTRAN 66.
(Yes, = we still have it for domain names, but these aren=E2=80=99t that much = younger :-)

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


= --Apple-Mail=_8776EDA9-B588-42E4-B2A0-0E27BB9A720D-- From nobody Wed Jan 11 09:02:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB94129D38 for ; Wed, 11 Jan 2017 09:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df93n_RQ8g6D for ; Wed, 11 Jan 2017 09:02:17 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BDE129D19 for ; Wed, 11 Jan 2017 09:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0BH2DUI021894; Wed, 11 Jan 2017 18:02:13 +0100 (CET) Received: from [192.168.217.124] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tzFYd1jgcz3ZmJ; Wed, 11 Jan 2017 18:02:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> Date: Wed, 11 Jan 2017 18:02:12 +0100 X-Mao-Original-Outgoing-Id: 505846932.603998-91bff3f23eab3fd1864deccf412a7f42 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> To: Michael Koster X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:02:18 -0000 > On 11 Jan 2017, at 17:55, Michael Koster = wrote: >=20 > OK sorry, I was thinking about this in RFC6690 which refers to = something a little different: >=20 > reg-rel-type =3D LOALPHA *( LOALPHA / DIGIT / "." / "-=E2=80=9C ) Right, this (only allowing lower case) was probably done to evade the = question of case-sensitivity. It is still compatible with the = case-sensitive millennium were are living in :-) (And it is for relation-types, while we were talking about URI-query = prefixes, IIRC.) > I still would not recommend only changing the case to differentiate. I=E2=80=99m actually with you on that point. Just wanted to curb as = early as possible any potential myth-building about CoAP being = case-insensitive in some way. > Carsten, do you think this is a potential conflict and should be = changed? (If this =3D =E2=80=9Clt" for both lifetime and less-than:) Well, it is certainly unfortunate. It seems it will not confuse the = machines, so we don=E2=80=99t HAVE to fix it, but it might confuse = humans, which are even more important. If none of these specifications = were in actual use, I=E2=80=99d try to change it. Do we still have the = liberty? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 11 09:24:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E3212960B for ; Wed, 11 Jan 2017 09:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFL81On9HjJx for ; Wed, 11 Jan 2017 09:24:32 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 2B6C6129532 for ; Wed, 11 Jan 2017 09:24:32 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id b1so54239677pgc.1 for ; Wed, 11 Jan 2017 09:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qAXm6EJpTelUnk0yHLpQTfjKQW+S5HwH7eQHgpMqe8M=; b=n7YTNSfXRk6EsWtD5OBp4E8N/BY4WuiFz/zmcP+nWm4FbSefiDeRO4sETBUAZlvlA6 rfSYcGQD8RdkmOshxvefXKyrs5j/+hMl/f0cHolJEzUb/NHy5VZa1zrogE7d5CfL/1d2 GVtLD8eDRU6Yx0wzJ3Yy3k3JVslFGj+se1k26tsjdtAn1lqAAxq8YIiWxy0DAZ3tARio 4Qb1PBrqNGlC2kWmd3A/k/9MfUAutK6Xpie0pGok61XcC9X+m7eNt0gj+7Q8liiVi1n6 tjDLVRpk/oPANuVVpCJVJrMnfcF8W0SNCwblixC+meCB01vx+uJqHUhTA5m5qEXVjorP H4jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qAXm6EJpTelUnk0yHLpQTfjKQW+S5HwH7eQHgpMqe8M=; b=Ll9oh/f1EylsNNUzOzuT+kc3BsEb5J0HlxyCHWo76eGtQujrHxGXRwTBEVL6Dg6s5M heqXHiytaKQTwiCVTaiCs72W+nK5t3e1HP6eHpjWTmgnWKlycjQG5abkgunh9m/hJ5bn 1vzSKg67USba0ozkIuLJdIFIjh8DKdjjSvdXoE99LBeJ/vMyuk+IZMI4CNtFtzYEXsqn aVJS4wZSuDD1LGckoxzH1Pt0Kn8yvkKngMxNF8NQNprxz9UHrhkVbSRMep0G/NA9zIwi c/LLHn064r4i2HJjSbHgx9j17TYsNDeHHA/FndTZRKyH0jNSyIdU2IZgCkfJc8jW98Xn +M7Q== X-Gm-Message-State: AIkVDXIpl+yW24qExvAgTwlibugmOKsNzBOCIDPhhFLgSbV6Rjc4a8OP2I7V6VWLPYFEXQ== X-Received: by 10.98.133.202 with SMTP id m71mr11815754pfk.102.1484155471726; Wed, 11 Jan 2017 09:24:31 -0800 (PST) Received: from wsip-98-173-88-26.lv.lv.cox.net (wsip-98-173-88-26.lv.lv.cox.net. [98.173.88.26]) by smtp.gmail.com with ESMTPSA id 18sm15339904pgf.28.2017.01.11.09.24.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 09:24:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Wed, 11 Jan 2017 09:24:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:24:33 -0000 I believe LWM2M uses both registration lifetime and conditional = notification less than parameters. David or Hannes could confirm. There is no issue with OCF Best regards,=20 Michael > On Jan 11, 2017, at 9:02 AM, Carsten Bormann wrote: >=20 >=20 >> On 11 Jan 2017, at 17:55, Michael Koster = wrote: >>=20 >> OK sorry, I was thinking about this in RFC6690 which refers to = something a little different: >>=20 >> reg-rel-type =3D LOALPHA *( LOALPHA / DIGIT / "." / "-=E2=80=9C ) >=20 > Right, this (only allowing lower case) was probably done to evade the = question of case-sensitivity. It is still compatible with the = case-sensitive millennium were are living in :-) > (And it is for relation-types, while we were talking about URI-query = prefixes, IIRC.) >=20 >> I still would not recommend only changing the case to differentiate. >=20 > I=E2=80=99m actually with you on that point. Just wanted to curb as = early as possible any potential myth-building about CoAP being = case-insensitive in some way. >=20 >> Carsten, do you think this is a potential conflict and should be = changed? >=20 > (If this =3D =E2=80=9Clt" for both lifetime and less-than:) >=20 > Well, it is certainly unfortunate. It seems it will not confuse the = machines, so we don=E2=80=99t HAVE to fix it, but it might confuse = humans, which are even more important. If none of these specifications = were in actual use, I=E2=80=99d try to change it. Do we still have the = liberty? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Wed Jan 11 09:36:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C6A12953C for ; Wed, 11 Jan 2017 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0vY-ZqAKziI for ; Wed, 11 Jan 2017 09:36:42 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B551294D5 for ; Wed, 11 Jan 2017 09:36:42 -0800 (PST) Received: from devpc ([84.14.163.130]) by mrelayeu.kundenserver.de (mreue104 [212.227.15.184]) with ESMTPSA (Nemesis) id 0MBjmR-1cH9gm3Bfb-00Amj7; Wed, 11 Jan 2017 18:36:31 +0100 From: "David Navarro" To: "'Michael Koster'" , "'Carsten Bormann'" References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> In-Reply-To: <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> Date: Wed, 11 Jan 2017 18:36:27 +0100 Message-ID: <005f01d26c31$3d1131a0$b73394e0$@ioterop.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: AQHDA97OwTF3NL3tcb9OZvxPX0MWQAKybv1cAdFf7hMBoT7q2wHTy83sAaUegBEB41mQhQHk0a0AAba7L+Wg2XIW8A== Content-Language: fr X-Provags-ID: V03:K0:kuH7PHo2OwQ2IbCGMufun/i1HyVBTVzX4ZzOApelO22KM+9d62+ lPbHvJtnnH5P6hZw9KecGpO8SNPECXaxn6EZ5GQ8MwISxqbL42P7mun+HT9XWTZbW3cZpRk KukRyZqgq8B/PqfpAkZT2KY06UkNaSRnS49fzeZ8FOozNkUG43XMrGFL6vbmn6ZUd6WgsAo /pFeMnZMZETcQ7nQbuBeQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:jsD3yD3DXNU=:reySwqEoIrcxGZGjwAW6vG HPbK1KsdvPM7jOSAmgr9pLWaaQqsVfg3TAvljhwPzcgYHgD3FxzrH996NRwHg2yrjvxI/b4KP E3+QmE3mS63JQrrhZGoAjUdL+sPIU1sPR8fW28+3Hw2/xdEVmufJ20CImtwIQ4Xv8ehajRcp0 3WMAslgEq5Ya6+rVfFSCr71qBtf6kGZ9QkYuvsYtx63xzlJD4bv/RFbLMT8cANhe5TCKeORVg 5AoKKFguZefSBGvn48As2Scgn9lMGHB0xyDxyNtpkK0wPycv+BrT/hbN8R67XJPQsTbDOxArZ +q/LGDX7oRoT57P2XiMGr8bAA64VIQZRhMudjrnxe7RG9NLTJ7UbX/W1NyOUbCGzlqoxi8QFB 1BiHnG3QE9u629cXVSiiUbUmWzYXTVVYShp+UCrY9v9vKxP8zyseEBnOXjanGBK8ZEi8ESiSe TipiYlQYccykV/O0ypjwV2dE/0j8Hes7jq1bHrtkIvri0e2pa2N56fRdDMFpcdKQXb05NF75e koBYz+gHNkvZtDFHFTzJQl74EpFXK/c6e8MOPCzAMyRwE9/s78if0qahjJ7fWwEsq+3jTSNza IliqGyomCES4ELoUYg2BPr9rqIjXiKrM1/jNxm0fHfjJvvSe1aEJpqCQlKAj9Ap7GcDCSItJT snOyiJVhhROF3MmxWYMSN5WAweby7u1EL3zpT02kUDAkXuNcOOLkBBD4Ndpqr5HmYKZUySw92 +o20gpfkXZTmu7Le Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:36:44 -0000 Yes both are used in LwM2M but the OMA DM WG is willing to remove the = possible confusion. As I wrote earlier, an hypothetical future confusion could be a lifetime = attribute in an observation request so that this observation is = automatically cancelled by the server: /sensor/temperature/value?lt=3D10>=3D30&lft=3D86400 Meaning "I want notifications when the temperature crosses the 10C or = the 30C threshold during the next 24 hours. =20 Regards, David Navarro -----Message d'origine----- De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster Envoy=C3=A9 : mercredi 11 janvier 2017 18:24 =C3=80 : Carsten Bormann Cc : core@ietf.org Objet : Re: [core] Lifetime (lt) and Less Than (lt) I believe LWM2M uses both registration lifetime and conditional = notification less than parameters. David or Hannes could confirm. There is no issue with OCF Best regards,=20 Michael > On Jan 11, 2017, at 9:02 AM, Carsten Bormann wrote: >=20 >=20 >> On 11 Jan 2017, at 17:55, Michael Koster = wrote: >>=20 >> OK sorry, I was thinking about this in RFC6690 which refers to = something a little different: >>=20 >> reg-rel-type =3D LOALPHA *( LOALPHA / DIGIT / "." / "-=E2=80=9C ) >=20 > Right, this (only allowing lower case) was probably done to evade the=20 > question of case-sensitivity. It is still compatible with the=20 > case-sensitive millennium were are living in :-) (And it is for=20 > relation-types, while we were talking about URI-query prefixes, IIRC.) >=20 >> I still would not recommend only changing the case to differentiate. >=20 > I=E2=80=99m actually with you on that point. Just wanted to curb as = early as possible any potential myth-building about CoAP being = case-insensitive in some way. >=20 >> Carsten, do you think this is a potential conflict and should be = changed? >=20 > (If this =3D =E2=80=9Clt" for both lifetime and less-than:) >=20 > Well, it is certainly unfortunate. It seems it will not confuse the = machines, so we don=E2=80=99t HAVE to fix it, but it might confuse = humans, which are even more important. If none of these specifications = were in actual use, I=E2=80=99d try to change it. Do we still have the = liberty? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 11 11:44:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD2129572 for ; Wed, 11 Jan 2017 11:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMn3zswTHSQs for ; Wed, 11 Jan 2017 11:44:03 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 52C48129599 for ; Wed, 11 Jan 2017 11:44:03 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 204so7723290pge.2 for ; Wed, 11 Jan 2017 11:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XkSVHzqTf9hpl+vnYHKNCdhENiL+z30Jk/jddUSy2UA=; b=Zud3VjDxOpebThICwZt1WB54AGdAQETH7Nnx+zTZxc8w+LLFMJX7ypL4T5s0YkVX4z nCvWocXWpjTipwbEQpcKkpGiv/5qSTqknXNluwJXU5Tw9oprkSieapp7ok5rYr+gG86R L5H46hw7fTxXEcRTEfu/knK1InlBru6usSpdGc9/W3e0hSEGbRYgjzQW59dxOxuOvf+J VB30o1HPyuhk871wF4EmwucQGL1Kv7hfGVHY4F6OjdrYQ2/nali3nq2JeIPq1DRG9wG3 ZbqwuVbD1RNLMkz8JS9jSoX1keg2fYQETGjgTHRHZpLp17ANLuju+pJ8DekYk4aHM8b1 nU/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XkSVHzqTf9hpl+vnYHKNCdhENiL+z30Jk/jddUSy2UA=; b=KL/F4pYn+ddMfjonMVwWeJeRJmakY+7spUAs61SX1HiTdK4MEFuSZEYAHNHNweM8or iiEW3FGMZ2do1EI0nFnI6Ls7A+8ozSaYVOSeOvvEY/AUHDqHcTUojXckDNFYuxaqTxWp C1CeLTQzttHA7AuV/9/Af175iwGuQOJzJhvPlk/7y/hU3ANfraVBC588L8X+q8m3chln dqBpp+LiyPfUHGUKpPswL0/aVL1FjpKFJ9i21LzP2WZvckuQ0Z27yW8HC/AJkFoUhQEm 0ZlPxA/xbQlPboxl/EoYmzDaoQbmLMc8Sowp+slrOJmwQM5NbjtUG/cFIKSgTMcOxRC/ KT7w== X-Gm-Message-State: AIkVDXJQAKqHV8rbHWa38WQ4n/2vn1g1WB15co+Zezb8sSZbXGK9ii1dhs3uZFTze68Bhw== X-Received: by 10.98.57.16 with SMTP id g16mr11954250pfa.109.1484163842816; Wed, 11 Jan 2017 11:44:02 -0800 (PST) Received: from wsip-98-173-86-122.lv.lv.cox.net (wsip-98-173-86-122.lv.lv.cox.net. [98.173.86.122]) by smtp.gmail.com with ESMTPSA id e127sm15689093pfh.89.2017.01.11.11.44.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 11:44:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> Date: Wed, 11 Jan 2017 11:44:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> To: David Navarro X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:44:05 -0000 If we must change something, I would recommend changing the conditional = notification parameter instead.=20 I think there is likely to be less impact changing dynlink vs. changing = RD. I think there are more implementations of RD that would be affected. Also if we intend to have a policy of not reusing identifiers, should we = have a registry of CoAP query parameters? Best regards, MIchael > On Jan 11, 2017, at 9:36 AM, David Navarro = wrote: >=20 > Yes both are used in LwM2M but the OMA DM WG is willing to remove the = possible confusion. >=20 > As I wrote earlier, an hypothetical future confusion could be a = lifetime attribute in an observation request so that this observation is = automatically cancelled by the server: > /sensor/temperature/value?lt=3D10>=3D30&lft=3D86400 > Meaning "I want notifications when the temperature crosses the 10C or = the 30C threshold during the next 24 hours. >=20 > Regards, > David Navarro >=20 > -----Message d'origine----- > De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster > Envoy=C3=A9 : mercredi 11 janvier 2017 18:24 > =C3=80 : Carsten Bormann > Cc : core@ietf.org > Objet : Re: [core] Lifetime (lt) and Less Than (lt) >=20 > I believe LWM2M uses both registration lifetime and conditional = notification less than parameters. David or Hannes could confirm. >=20 > There is no issue with OCF >=20 > Best regards,=20 >=20 > Michael >=20 >> On Jan 11, 2017, at 9:02 AM, Carsten Bormann wrote: >>=20 >>=20 >>> On 11 Jan 2017, at 17:55, Michael Koster = wrote: >>>=20 >>> OK sorry, I was thinking about this in RFC6690 which refers to = something a little different: >>>=20 >>> reg-rel-type =3D LOALPHA *( LOALPHA / DIGIT / "." / "-=E2=80=9C ) >>=20 >> Right, this (only allowing lower case) was probably done to evade the=20= >> question of case-sensitivity. It is still compatible with the=20 >> case-sensitive millennium were are living in :-) (And it is for=20 >> relation-types, while we were talking about URI-query prefixes, = IIRC.) >>=20 >>> I still would not recommend only changing the case to differentiate. >>=20 >> I=E2=80=99m actually with you on that point. Just wanted to curb as = early as possible any potential myth-building about CoAP being = case-insensitive in some way. >>=20 >>> Carsten, do you think this is a potential conflict and should be = changed? >>=20 >> (If this =3D =E2=80=9Clt" for both lifetime and less-than:) >>=20 >> Well, it is certainly unfortunate. It seems it will not confuse the = machines, so we don=E2=80=99t HAVE to fix it, but it might confuse = humans, which are even more important. If none of these specifications = were in actual use, I=E2=80=99d try to change it. Do we still have the = liberty? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Wed Jan 11 12:46:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82B0129872 for ; Wed, 11 Jan 2017 12:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, 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 3Kd7ixwA4Ype for ; Wed, 11 Jan 2017 12:46:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDD11297F3 for ; Wed, 11 Jan 2017 12:46:46 -0800 (PST) Received: from [192.168.91.167] ([62.212.97.25]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MHokD-1cSmhp0REz-003b2y; Wed, 11 Jan 2017 21:46:40 +0100 To: Michael Koster , David Navarro References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 11 Jan 2017 21:46:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E1N6raqbdxpc0xehDcmAQxFkrEr8K1oj5" X-Provags-ID: V03:K0:8xDZbQywGfj6VEX4g9nxIDQFLIeC6Ws5cM2bXMLhat59Y1PlYVH M6u3UX8r83BNZWET84YHNS6JP0apXsZQmYMq81AgyNz3pXBvz9H8cjWwZxL3sjGVU6LnuwH tmNWLyygW9jJ/zK/XkN+oXt9vNdeEHOQNHsHE3im5T4xFRnmYT4F+TScaAVALpoElUnEyzS GC0tVX2Cl6drrocH5CABw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ELekgFFBmaI=:mCYMIo9LhPtP7EG+dK+Xms TXGvXIyM/u12yj2bQwh7eyDYdvw5KLkeS68yybcPR3/C2SWs/P2MQEl5YtRogueu4nI1mxQrq JKBWT0WBOMHDNavrSTzH1YF+r+5g6IqpT606OCrTVIuXOzFWgT8OlsnSEbNiYq0QNEHYVz8lE d+/lQkGZJcIPDaeiT39hENkG1KDqKPoiCefVoHLuCKHeam2SfHQehUv8SoUNzySre702GP3zj xt8biS6H3MWfHKfbjXMe38D/GOJAqE75jnrlZ6Flpb2cCUXekx6lZ6uaXv3+ER1M7HHTKiCyM xXpVS6UgxkaUNpAtMqcNS6U8FeuqvdQfoOojqhM6rykTgIOJW8HP8EDXeWQbiT64HTT1U0j8l DRrUa8NEBRkopdvYZuXCj3Am2oWWMP5Es2XZfor0TPEmK+GAYmj1jP38h/6tnB8anS66CyJ3y vGJKp3H2no8Pr1bcP5n5BEJs4W+1U0W7NUVDFIvxIlEFjenlj3QWe4mRTQS8Wl5FBEd0FN86F J7uw43AatJokEr/673M4WYdErJmCgiPh2aKn15dfSS0iV5o9Zs+d2k3bVQDdm/xwJdnnAlg4j 9g0fi+tfPZFt+7mC442LvPb+n2WkEBiVnH3e8u7tE/cCO9TSBtdILLe1YZb71fn7pFBTxKjjC 0AsPYH8WBU/NmmAUOvQQVtmt/VEaiOTEYr1qSt/AEc4bJT6uZDuqdxcGjk6FiJj3/KdE9XYpR ZCU4Cl0OelV2CiOXGb4ygBXF9z1Ca7u9R6JXtn+D+SmiYV5Ahca3mfXyeBn7Jxi/5VUP6AHoZ cTY3Z6+jQ6vEc/aHSGJQZNiC5YmczEZLI0k9Bb/cbsIapfdNeqB4i767YaE54ERXpoL/KM20h p3/5aeszyN3wJWFegyAGcxEBlBvtk8IzHbu40I0ENZgkCR+0xZH30eR7F4PzVT3nyf+UGCoOZ vhs6ElDfSjTrexb7foHj5++qb0rOQMvNb2vrP74bdjY6y90Tdb17e+DUuHYtxcdSxxqwWMf0T HjfLU+HB9gM7AW+CRcP+5NLLWbFeWGwItgFgtBKl/oR6 Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:46:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E1N6raqbdxpc0xehDcmAQxFkrEr8K1oj5 Content-Type: multipart/mixed; boundary="O0Jrkgqcr0BTwmwtQtBHnruGoiuVnt1l0"; protected-headers="v1" From: Hannes Tschofenig To: Michael Koster , David Navarro Cc: core@ietf.org Message-ID: Subject: Re: [core] Lifetime (lt) and Less Than (lt) References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> In-Reply-To: --O0Jrkgqcr0BTwmwtQtBHnruGoiuVnt1l0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 01/11/2017 08:44 PM, Michael Koster wrote: > If we must change something, I would recommend changing the conditional= notification parameter instead.=20 >=20 > I think there is likely to be less impact changing dynlink vs. changing= RD. I think there are more implementations of RD that would be affected.= I don't have an opinion about this aspect. > Also if we intend to have a policy of not reusing identifiers, should w= e have a registry of CoAP query parameters? I believe a registry for the parameters would be useful. Ciao Hannes >=20 > Best regards, >=20 > MIchael >=20 >> On Jan 11, 2017, at 9:36 AM, David Navarro = wrote: >> >> Yes both are used in LwM2M but the OMA DM WG is willing to remove the = possible confusion. >> >> As I wrote earlier, an hypothetical future confusion could be a lifeti= me attribute in an observation request so that this observation is automa= tically cancelled by the server: >> /sensor/temperature/value?lt=3D10>=3D30&lft=3D86400 >> Meaning "I want notifications when the temperature crosses the 10C or = the 30C threshold during the next 24 hours. >> >> Regards, >> David Navarro >> >> -----Message d'origine----- >> De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster >> Envoy=C3=A9 : mercredi 11 janvier 2017 18:24 >> =C3=80 : Carsten Bormann >> Cc : core@ietf.org >> Objet : Re: [core] Lifetime (lt) and Less Than (lt) >> >> I believe LWM2M uses both registration lifetime and conditional notifi= cation less than parameters. David or Hannes could confirm. >> >> There is no issue with OCF >> >> Best regards,=20 >> >> Michael >> >>> On Jan 11, 2017, at 9:02 AM, Carsten Bormann wrote: >>> >>> >>>> On 11 Jan 2017, at 17:55, Michael Koster wrote: >>>> >>>> OK sorry, I was thinking about this in RFC6690 which refers to somet= hing a little different: >>>> >>>> reg-rel-type =3D LOALPHA *( LOALPHA / DIGIT / "." / "-=E2=80=9C ) >>> >>> Right, this (only allowing lower case) was probably done to evade the= =20 >>> question of case-sensitivity. It is still compatible with the=20 >>> case-sensitive millennium were are living in :-) (And it is for=20 >>> relation-types, while we were talking about URI-query prefixes, IIRC.= ) >>> >>>> I still would not recommend only changing the case to differentiate.= >>> >>> I=E2=80=99m actually with you on that point. Just wanted to curb as = early as possible any potential myth-building about CoAP being case-insen= sitive in some way. >>> >>>> Carsten, do you think this is a potential conflict and should be cha= nged? >>> >>> (If this =3D =E2=80=9Clt" for both lifetime and less-than:) >>> >>> Well, it is certainly unfortunate. It seems it will not confuse the = machines, so we don=E2=80=99t HAVE to fix it, but it might confuse humans= , which are even more important. If none of these specifications were in= actual use, I=E2=80=99d try to change it. Do we still have the liberty?= >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --O0Jrkgqcr0BTwmwtQtBHnruGoiuVnt1l0-- --E1N6raqbdxpc0xehDcmAQxFkrEr8K1oj5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYdpmuAAoJEGhJURNOOiAtB7QIAJT4dZgXNWRVFGVvhxnYsgpq Djxw4BMlacw5bY9duhjtkQH6h78kEUeqbz3G+ZmyVw7AbPxnWcpLJrtIPj2vLppV YSURZmWmiF4Bnfs7iQDlv4F+ph2pdbLJkMhI29itXtcYYygeLgBbOAs15ZskcPxW I6/VhyIhQed6ceujxklvXFDef8TMVC7qFYPUgXQp9nx2svTx1fWbsilJFWXPF9oz xZxMMWBNPYQyKIgOUKXh0XFqwz7FyZLoTFjf+meXxKUjQ8q8hYzDGsPLX7M0MJm6 /9ZD0NzEFD3xJ7B3UAp2QZT/TRmemz3FbNN8GoX3KVe+rEZop+WdKspj15R7ZZo= =P6gP -----END PGP SIGNATURE----- --E1N6raqbdxpc0xehDcmAQxFkrEr8K1oj5-- From nobody Wed Jan 11 15:07:23 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEBE1295C8 for ; Wed, 11 Jan 2017 15:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPg6Jjwonfm9 for ; Wed, 11 Jan 2017 15:07:20 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3291295C4 for ; Wed, 11 Jan 2017 15:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0BN7EkV006774; Thu, 12 Jan 2017 00:07:14 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tzPfp1rv3z3Zrr; Thu, 12 Jan 2017 00:07:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Thu, 12 Jan 2017 00:07:13 +0100 X-Mao-Original-Outgoing-Id: 505868833.294952-e549d3ddac0d485bcdf21f8bab4def0a Content-Transfer-Encoding: quoted-printable Message-Id: <254B781C-B4F5-47D4-B239-4247664F13C5@tzi.org> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:07:22 -0000 On 11 Jan 2017, at 21:46, Hannes Tschofenig = wrote: >=20 > I believe a registry for the parameters would be useful. If we think that is useful, we could do this informally, as in https://svn.tools.ietf.org/svn/wg/core/registry.txt This would mean we don=E2=80=99t have to wait for an IANA process, which = might be too heavyweight for this. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 11 16:23:42 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4D21295C6 for ; Wed, 11 Jan 2017 15:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-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 lFJ__sNpw8Do for ; Wed, 11 Jan 2017 15:26:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC581295F0 for ; Wed, 11 Jan 2017 15:26:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 32F3AB8019F; Wed, 11 Jan 2017 15:26:18 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170111232618.32F3AB8019F@rfc-editor.org> Date: Wed, 11 Jan 2017 15:26:18 -0800 (PST) Archived-At: X-Mailman-Approved-At: Wed, 11 Jan 2017 16:23:41 -0800 Cc: kolban1@kolban.com, core@ietf.org, rfc-editor@rfc-editor.org Subject: [core] [Technical Errata Reported] RFC7252 (4902) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:26:29 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4902 -------------------------------------- Type: Technical Reported by: Neil Kolban Section: 3.0 Original Text ------------- This is followed by a variable-length Token value, which can be between 0 and 8 bytes long. Corrected Text -------------- This is followed by a variable-length Token value, which can be between 0 and 7 bytes long. Notes ----- This is a nit-pick but we enter into the ambiguity of the semantics of "between" and whether it means inclusive or exclusive. In this context, since we can obviously have no token which would mean a token of length 0, then we are using between in its "inclusive" semantics ... which would then imply that "7" is the maximum (inclusive) length of a token which is constrained to 3 bits with a maximum value of 0b111 = decimal 7. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Jan 11 23:29:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC7129489 for ; Wed, 11 Jan 2017 23:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC-4BK9dsZSQ for ; Wed, 11 Jan 2017 23:29:26 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866031270B4 for ; Wed, 11 Jan 2017 23:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0C7TMFO029691; Thu, 12 Jan 2017 08:29:22 +0100 (CET) Received: from [10.0.1.13] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tzcpB0cVLz3ZwV; Thu, 12 Jan 2017 08:29:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Thu, 12 Jan 2017 08:29:21 +0100 X-Mao-Original-Outgoing-Id: 505898961.515051-b59239d2899a258b7fd4b9209c0a0611 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170111232618.32F3AB8019F@rfc-editor.org> To: Neil Kolban X-Mailer: Apple Mail (2.3259) Archived-At: Cc: RFC Interest , "core \(core@ietf.org\)" Subject: Re: [core] [Technical Errata Reported] RFC7252 (4902) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:29:28 -0000 Hi Neil, no problem, thanks for reading attentively. Your report reminded me that sometimes we write things in specifications = that probably should be marked with a =E2=80=9C(really!)=E2=80=9D or = =E2=80=9C(!)=E2=80=9D. I=E2=80=99m not sure we have a good convention = for that (=E2=80=9C(!)=E2=80=9D has all these other connotations), but = something like Knuth=E2=80=99s =E2=80=9Cdangerous bend" might prevent = the occasional double take when a spec violates the POLS (principle of = least surprise). (CCing rfc-i not because this is something that must be handled = immediately, but to start the creative processes in the back of their = collective minds.) Gr=C3=BC=C3=9Fe, Carsten > On 12 Jan 2017, at 00:30, Neil Kolban wrote: >=20 > Please ignore this report ... just realized that the TKL is 4 bits and = not 3 bits and hence 8 is a valid length for a token. >=20 >=20 > Apologies. >=20 >=20 > Neil >=20 >=20 > On 1/11/2017 5:26 PM, RFC Errata System wrote: >> The following errata report has been submitted for RFC7252, >> "The Constrained Application Protocol (CoAP)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D7252&eid=3D4902 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Neil Kolban >>=20 >> Section: 3.0 >>=20 >> Original Text >> ------------- >> This is followed by a variable-length Token value, which can be >> between 0 and 8 bytes long. >>=20 >> Corrected Text >> -------------- >> This is followed by a variable-length Token value, which can be >> between 0 and 7 bytes long. >>=20 >> Notes >> ----- >> This is a nit-pick but we enter into the ambiguity of the semantics = of "between" and whether it means inclusive or exclusive. In this = context, since we can obviously have no token which would mean a token = of length 0, then we are using between in its "inclusive" semantics ... = which would then imply that "7" is the maximum (inclusive) length of a = token which is constrained to 3 bits with a maximum value of 0b111 =3D = decimal 7. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC7252 (draft-ietf-core-coap-18) >> -------------------------------------- >> Title : The Constrained Application Protocol (CoAP) >> Publication Date : June 2014 >> Author(s) : Z. Shelby, K. Hartke, C. Bormann >> Category : PROPOSED STANDARD >> Source : Constrained RESTful Environments APP >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >>=20 >>=20 >=20 >=20 From nobody Thu Jan 12 03:16:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E8C1295A3 for ; Thu, 12 Jan 2017 03:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRXTIqqUj6E7 for ; Thu, 12 Jan 2017 03:16:03 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3351129594 for ; Thu, 12 Jan 2017 03:16:02 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 12 Jan 2017 12:15:53 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0319.002; Thu, 12 Jan 2017 12:15:59 +0100 From: "Kovatsch Matthias" To: core WG Thread-Topic: Copper CoAP user-agent for Chrome Thread-Index: AdJsxRzLNqB2H/4iQnaB1f+xUC6Leg== Date: Thu, 12 Jan 2017 11:15:58 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5577F0262@MBX110.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] Copper CoAP user-agent for Chrome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 11:16:04 -0000 Dear all If you liked using Copper (Cu), but are usually using Google Chrome, this m= ight interest you: https://github.com/mkovatsc/Copper4Cr Best wishes and a late happy new year Matthias From nobody Fri Jan 13 09:46:42 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59AF129CDB; Fri, 13 Jan 2017 09:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yULCIYNGwsbW; Fri, 13 Jan 2017 09:46:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A34129CEC; Fri, 13 Jan 2017 09:46:25 -0800 (PST) X-AuditID: c1b4fb30-d3d9198000004e29-c7-5879126f5d94 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id F5.F0.20009.F6219785; Fri, 13 Jan 2017 18:46:23 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.95]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 18:45:34 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] OSCOAP: [...], sequence numbers Thread-Index: AQHSaxCGFcqj/qEuz0qLdPYr3fiZf6E2s4KA Date: Fri, 13 Jan 2017 17:46:22 +0000 Message-ID: References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> In-Reply-To: <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <185D85A80FDF7049A9F23BDFA232BE34@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7h26+UGWEwcJZVhbLLzxnsdj3dj2z xbR/Z1gsVk//zubA4rFxznQ2j6377zJ5LFnykymAOYrLJiU1J7MstUjfLoErY0tnSsE2pYof k94xNjAeUexi5OSQEDCRWPZtOmsXIxeHkMA6RokT67cwQjiLGSVm/ZrLBFLFJuAi8aDhEZgt IuAhMXHpF3aQImaQojUnjrGBJIQFjCVu/33ODFFkIrFu6yp2CNtI4v+XVSxdjBwcLAKqEh++ 2IOEeQUsJC5Mb4Ha/IRR4nnXBFaQBKeAq0TTkY1gNqOAmMT3U2vAFjMLiEvcejKfCeJsAYkl e84zQ9iiEi8f/wOrFxXQk1j+fA1UXEli7eHtYHuZBTQl1u/ShxhjLXF+xyd2CFtRYkr3Q3aI ewQlTs58wjKBUXwWkm2zELpnIemehaR7FpLuBYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJL NjECY/Hglt8GOxhfPnc8xCjAwajEw1vAVREhxJpYVlyZe4hRgoNZSYS3lK0yQog3JbGyKrUo P76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGCe+OhPKfidJ96ZHDdTSu TST52bKJetfLQoKvO3j9lAx3OyuybOqCQF6322kM97/GJlYu1vst2OmknStz8spFj7/5u0qY jH1qC3S237beVRrGFFftbpvcKLnbvPvDT8clxonmsoaCl5MuFXG8TXqyYEPCHd5nHYxvGMuF a1138ifa3Cj5rqTEUpyRaKjFXFScCAA3j4rywQIAAA== Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP: [...], sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 17:46:33 -0000 SGkgQ2hyaXN0aWFuLA0KDQpJbmxpbmU6DQoNCk9uIDIwMTctMDEtMTAgMDg6MDgsICJDaHJpc3Rp YW4gQW1zw7xzcyIgPGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0Pg0Kd3JvdGU6DQoNCj5P biBNb24sIEphbiAwOSwgMjAxNyBhdCAxMDowMjowNFBNICswMDAwLCBHw7ZyYW4gU2VsYW5kZXIg d3JvdGU6DQo+PiA+PiAgIGlzIHRoZXJlIGFueSB3YXkgdG8gcmVjb3ZlciBmcm9tIHN1Y2ggYSBz aXR1YXRpb24sIGVnIHJvdWdobHkgYnkNCj4+dGhlDQo+PiA+PiAgIHJlY2lwaWVudCBzYXlpbmcg IkkndmUgaGVhcmQgYWxsIHRoYXQsIHN0YXJ0IGF0IE4gb3IgSSBjYW4ndCB0cnVzdA0KPj55b3UN Cj4+ID4+ICAgYXQgYWxsIj8NCj4+ID4+IA0KPj4gPj4gICBJdCBtaWdodCB3ZWxsIGJlIGEgYmFk IGlkZWEgdG8gYWxsb3cgc3VjaCBhIHRoaW5nIChhdCB2ZXJ5IGxlYXN0LA0KPj50aGF0DQo+PiA+ PiAgIGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIGF1dGhlbnRpY2F0ZWQpLCBzbyByaWdodCBub3cg dGhpcyBpcw0KPj5wcmltYXJpbHkNCj4+ID4+ICAgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRo ZXJlIGlzIGEgbWVjaGFuaXNtIEkgbWlzc2VkLCBhbmQgd2hldGhlcg0KPj4gPj4gICB0aGVyZSBz aG91bGQgYmUgZ3VpZGFuY2UgY29uc2lkZXJpbmcgdGhlIGVtYmVkZGVkIHVzZSBjYXNlcy4NCj4+ ID4NCj4+ID5UaGUgcmVzZXQgb2YgdGhlIG5vbmNlIGlzIGdvaW5nIHRvIGJlIGEgcHJvYmxlbSB1 bmRlciBhbGwNCj4+ID5jaXJjdW1zdGFuY2VzIGlmIHlvdSBnbyBiYWNrIHRvIGEgY2xlYW4gZmFj dG9yeSBzdGF0ZSBhbmQgeW91IGNhbm5vdA0KPj4gPnN0b3JlIHRoZSBhcHByb3ByaWF0ZSBub25j ZSBpbiBub24tdm9sYXRpbGUgbWVtb3J5Lg0KPj4gDQo+PiBBcyBKaW0gc2FpZCwgdGhlIHNlY3Vy aXR5IGNvbnRleHQgc2hvdWxkIG5vdCBiZSByZXVzZWQgd2hlbiBhIGRldmljZSBpcw0KPj4gcmVz ZXQuIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgYXQgbGVhc3QgaGF2ZSBzb21lIGNvbnNpZGVyYXRp b25zIGluIHRoZQ0KPj4gY2FzZSBvZiBQU0sgaW4gZW1iZWRkZWQgZGV2aWNlcyBhbmQgcGVyaGFw cyBtYWtlIHNvbWUgcmVjb21tZW5kYXRpb25zLg0KPg0KPk15IGNvbmNlcm4gaXMgbm90IG9ubHkg Zm9yIHJlc2V0cywgYnV0IGZvciBwZXJzaXN0ZW5jZSBpbiBnZW5lcmFsOyBmbGFzaA0KPmJhc2Vk IGRldmljZXMgKGFzIGluIGVtYmVkZGVkIGZsYXNoIHdpdGggYSBmZXcgdGhvdXNhbmQgZXJhc2Ug Y3ljbGVzKS4NCj5Xcml0aW5nIHRvIHBlcnNpc3RlbnQgbWVtb3J5IG9uIGV2ZXJ5IHRyYW5zYWN0 aW9uIChzaHV0ZG93bnMgYXJlIG5vdA0KPmNsZWFuIG9uIHRob3NlIGRldmljZXMgaW4gbXkgZXhw ZXJpZW5jZSkgaXMgbm90IHByYWN0aWNhbCB0aGVyZS4NCj4NCj5JbiBpdHMgc2VuZGVyIGNvbnRl eHQsIGEgZGV2aWNlIGNvdWxkIGp1c3QgbGVhc2Ugb3V0IHNlcXVlbmNlIG51bWJlcnMNCj5mcm9t IGZsYXNoIGFuZCBsZWFwIGFoZWFkIG9uIHJlYm9vdDsgZWcuIGl0IHdvdWxkIHJlYWQgdGhlIGxh c3QgdXNlZA0KPnNlcXVlbmNlIG51bWJlciBhcyAxMDI0IG9uIHJlYm9vdCwgd3JpdGUgMjA0OCwg YW5kIGNvdW50IGZyb20gMTAyNSB0bw0KPjIwNDggaW4gUkFNIHdoaWxlIHNlbmRpbmcgdW50aWwg Zmxhc2ggZ2V0cyB3cml0dGVuIHRvIGFnYWluLiBBIHBvd2VyDQo+b3V0YWdlIHRoZW4gZG9lcyBu byBtb3JlIGhhcm0gdGhhbiB3YXN0aW5nIHNvbWUgc2VxdWVuY2UgbnVtYmVycy4NCg0KR29vZCBw cm9wb3NhbC4gVW5sZXNzIGEgbmV3IHNlY3VyaXR5IGNvbnRleHQgIGlzIGVzdGFibGlzaGVkLCB3 ZSBzaG91bGQNCm1hbmRhdGUgdGhlIHNlbmRlciB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGlzIHRv IHByZXZlbnQga2V5IGFuZCBzZXF1ZW5jZQ0KbnVtYmVyL0lWIHJlLXVzZS4gVGhpcyBhcHBsaWVz IGJvdGggdG8gY2xpZW50IGFuZCBzZXJ2ZXIuDQoNCj4NCj5JbiBpdHMgcmVjaXBpZW50IGNvbnRl eHQsIGlmIHRoZSBkZXZpY2Ugb25seSBzdG9yZXMgc29tZXRoaW5nIGxpa2UgdGhlDQo+ZW5kIG9m IGl0cyByZWNlaXZlIHdpbmRvdyBvbiBmbGFzaCwgaXQnbGwgdGFrZSB0aGUgY29tbXVuaWNhdGlv biBwYXJ0bmVyDQo+dXAgdG8gd2luZG93LXNpemUgZmFpbGVkIGF0dGVtcHRzICh3aGljaCBpdCBt aWdodCBub3QgZXZlbiBiZSBhbGxvd2VkIHRvDQo+cmVwZWF0KSB0byBnZXQgaW4gdGhlIGNsZWFy Lg0KDQoNCkJ1dCB0aGUgcmVwbGF5IHdpbmRvdyBtZWNoYW5pc20gT1NDT0FQIGhhcyBpbmhlcml0 ZWQgZnJvbSBEVExTIGFuZCBFU1AgaXMNCnNsaWRpbmcsIHNvIG1haW50YWluaW5nIHRoaXMgc3Rh dGUgaW4gdGhlIGV2ZW50IG9mIGEgc2h1dGRvd24gd291bGQNCnJlcXVpcmUgd3JpdGluZyB0aGUg 4oCccmlnaHQiIGVkZ2Ugb2YgdGhlIHdpbmRvdyB0byBmbGFzaCBlYWNoIHRpbWUgYSBuZXcNCmhp Z2hlc3Qgc2VxdWVuY2UgbnVtYmVyIGhhcyBiZWVuIHJlY2VpdmVkLiBJIGd1ZXNzIHRoaXMgaXMg bm90IGRlc2lyYWJsZT8NCg0KSG93ZXZlciwgaW4gdGhpcyBjYXNlIHJlcGxheSBwcm90ZWN0aW9u IGNhbiBiZSBhZGRyZXNzZWQgd2l0aCB0aGUgUmVwZWF0DQpvcHRpb24gZGVmaW5lZCBpbiANCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0 b3JzLTAyDQpPbiByZWJvb3QsIGEgc2VydmVyIG11c3Qgbm90IGFjY2VwdCB0aGUgZmlyc3QgbWVz c2FnZSByZWNlaXZlZCBpbiBhIHN0b3JlZA0Kc2VjdXJpdHkgY29udGV4dCwgYnV0IHJlc3BvbmQg d2l0aCBhIFJlcGVhdCBvcHRpb24gYXNraW5nIHRoZSBjbGllbnQgaWYgaXQNCnJlY2VudGx5IG1h ZGUgdGhlIHJlcXVlc3QsIGFuZCBpZiBzbywgdG8gcmVwZWF0IHRoZSByZXF1ZXN0IHVzaW5nIGl0 cw0KY3VycmVudCBzZXF1ZW5jZSBudW1iZXIsIGFuZCBpbmNsdWRlIHRoZSBzYW1lIFJlcGVhdCBw YXJhbWV0ZXIgZm9yIHNlcnZlcg0KdG8gdmVyaWZ5IGZyZXNobmVzcy4NCg0KKFRoZSBjbGllbnQg cmVjZXB0aW9uIGJlaGF2aW91ciBhZnRlciByZWJvb3QgaXMgc3RyYWlnaHRmb3J3YXJkIHNpbmNl IHRoZQ0KY2xpZW50IHNob3VsZCBvbmx5IGFjY2VwdCByZXNwb25zZXMgZm9yIHJlcXVlc3RzIG1h ZGUgYWZ0ZXIgcmVib290LikNCg0KSeKAmWxsIG1ha2UgaXNzdWVzIGFuZCBkcmFmdCB0ZXh0IG9u IHRoaXMuDQoNCg0KDQpHw7ZyYW4NCg0KDQo= From nobody Sun Jan 15 18:13:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAF112944B for ; Sun, 15 Jan 2017 18:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guSor8TJzYaA for ; Sun, 15 Jan 2017 18:13:25 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F782129449 for ; Sun, 15 Jan 2017 18:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ohxlUp0kRv90XbBo3i4cv2A76bGNVBf+Cjf0OCzLRL8=; b=jzEHweDZ8RNja1TjVqzzI86KWz iufRMT7ONSrZOcZRkFaFFgHPGDDVkAbTMKx+q2xpKJH2oYtM17hLCUJ05eu63Vl+zIQRW/TF2YwAA 0im3F3EIoY8UM0lN/PHVDAsEFgs1HRRjQ7ixogQct+pTpXET+0mdQHwG6NwdMBLS8nZa7Z89wi0F9 KxFq7yn0xuUIT2Kk6Dat4R0ZTtoPsi/SFkb06SJoLvsDqkRo8Gu0VQ75Ni1tk2Jh4SGxa0qhYgdVY 2VN3/YaelNqUatPsVH2hvJ61h2XvVlE34j7eERyyv5KT2AG7UgI+F8yeV+U32JBf09xISIGIJX991 VcUKUUdA==; Received: from ppp118-209-145-28.lns20.mel8.internode.on.net ([118.209.145.28]:58913 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cSwnT-002RaG-KS for core@ietf.org; Mon, 16 Jan 2017 13:13:23 +1100 To: core@ietf.org References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> From: Christian Groves Message-ID: Date: Mon, 16 Jan 2017 13:13:21 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 02:13:27 -0000 Hello, Changing lt in dynlink is easy enough for me to do. It seems to be the better choice than changing lt in RD as the dynlink draft isn't as far along as the RD draft. As LWM2M is the only "official" usage it probably comes down to which instance they'd like to change? With respect to the registry I agree this would be useful. I tend to favour the IANA rather than the formal informal approach as its more visible but I don't have a strong preference. Regards, Christian. On 12/01/2017 7:46 AM, Hannes Tschofenig wrote: > Hi Michael, > > On 01/11/2017 08:44 PM, Michael Koster wrote: >> If we must change something, I would recommend changing the conditional notification parameter instead. >> >> I think there is likely to be less impact changing dynlink vs. changing RD. I think there are more implementations of RD that would be affected. > I don't have an opinion about this aspect. > >> Also if we intend to have a policy of not reusing identifiers, should we have a registry of CoAP query parameters? > I believe a registry for the parameters would be useful. > > Ciao > Hannes > >> Best regards, >> >> MIchael >> >>> On Jan 11, 2017, at 9:36 AM, David Navarro wrote: >>> >>> Yes both are used in LwM2M but the OMA DM WG is willing to remove the possible confusion. >>> >>> As I wrote earlier, an hypothetical future confusion could be a lifetime attribute in an observation request so that this observation is automatically cancelled by the server: >>> /sensor/temperature/value?lt=10>=30&lft=86400 >>> Meaning "I want notifications when the temperature crosses the 10C or the 30C threshold during the next 24 hours. >>> >>> Regards, >>> David Navarro >>> >>> -----Message d'origine----- >>> De : core [mailto:core-bounces@ietf.org] De la part de Michael Koster >>> Envoyé : mercredi 11 janvier 2017 18:24 >>> À : Carsten Bormann >>> Cc : core@ietf.org >>> Objet : Re: [core] Lifetime (lt) and Less Than (lt) >>> >>> I believe LWM2M uses both registration lifetime and conditional notification less than parameters. David or Hannes could confirm. >>> >>> There is no issue with OCF >>> >>> Best regards, >>> >>> Michael >>> >>>> On Jan 11, 2017, at 9:02 AM, Carsten Bormann wrote: >>>> >>>> >>>>> On 11 Jan 2017, at 17:55, Michael Koster wrote: >>>>> >>>>> OK sorry, I was thinking about this in RFC6690 which refers to something a little different: >>>>> >>>>> reg-rel-type = LOALPHA *( LOALPHA / DIGIT / "." / "-“ ) >>>> Right, this (only allowing lower case) was probably done to evade the >>>> question of case-sensitivity. It is still compatible with the >>>> case-sensitive millennium were are living in :-) (And it is for >>>> relation-types, while we were talking about URI-query prefixes, IIRC.) >>>> >>>>> I still would not recommend only changing the case to differentiate. >>>> I’m actually with you on that point. Just wanted to curb as early as possible any potential myth-building about CoAP being case-insensitive in some way. >>>> >>>>> Carsten, do you think this is a potential conflict and should be changed? >>>> (If this = “lt" for both lifetime and less-than:) >>>> >>>> Well, it is certainly unfortunate. It seems it will not confuse the machines, so we don’t HAVE to fix it, but it might confuse humans, which are even more important. If none of these specifications were in actual use, I’d try to change it. Do we still have the liberty? >>>> >>>> Grüße, Carsten >>>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Jan 15 23:42:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C13129407 for ; Sun, 15 Jan 2017 23:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFBCzgdapH6f for ; Sun, 15 Jan 2017 23:42:11 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CAC126BF7 for ; Sun, 15 Jan 2017 23:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0G7g6Ep004492; Mon, 16 Jan 2017 08:42:06 +0100 (CET) Received: from [192.168.217.124] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3v24v23H6Sz3Zt1; Mon, 16 Jan 2017 08:42:06 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Mon, 16 Jan 2017 08:42:06 +0100 X-Mao-Original-Outgoing-Id: 506245325.734122-556b0ce69cceed0c03f65b50dfcebd5a Content-Transfer-Encoding: quoted-printable Message-Id: <1D0BB896-A49B-4849-A9D8-8AC8E64E7B6F@tzi.org> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> To: Christian Groves X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 07:42:13 -0000 On 16 Jan 2017, at 03:13, Christian Groves = wrote: >=20 > Changing lt in dynlink is easy enough for me to do. It seems to be the = better choice than changing lt in RD as the dynlink draft isn't as far = along as the RD draft. As LWM2M is the only "official" usage it probably = comes down to which instance they'd like to change? Right. If we want to change lt there, we probably should change gt as well. The pair of .LT. and .GT. has been with us as a representation of = =E2=80=9C<=E2=80=9C and =E2=80=9C>" since FORTRAN II. (There already is a bit of a surprise why there is no .LE. or .GE. =E2=80=94= are notification thresholds always exclusive?) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jan 16 15:00:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CD8129854; Mon, 16 Jan 2017 15:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 4EV8-g4_5L_M; Mon, 16 Jan 2017 14:59:59 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id DD48612984C; Mon, 16 Jan 2017 14:59:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 15C723F818; Mon, 16 Jan 2017 23:59:56 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RoTKwFlfBNRl; Mon, 16 Jan 2017 23:59:56 +0100 (CET) Received: from [192.168.1.206] (40.red-81-33-45.dynamicip.rima-tde.net [81.33.45.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon21.um.es (Postfix) with ESMTPSA id 93C143F807; Mon, 16 Jan 2017 23:59:53 +0100 (CET) From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2017 23:59:52 +0100 Message-Id: To: core@ietf.org, ace@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [core] App-layer security for CoAP using (D)TLS record layer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 23:00:01 -0000 Hello all:=20 We submitted some time ago an I-D proposing the use of an active (D)TLS = Record (e.g. running DTLS over CoAP or presenting a token with crypto = material that is used to create the required keys for the DTLS record) = to provide application level security for CoAP.=20 = https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-reco= rd-00 The idea is to use an active (D)TLS record to protect part of the CoAP = message following the rules established for OSCOAP: - The content to protect of a CoAP message (code, version, options to = protect and payload if any) is fed to the (D)TLS record.=20 - The output is the CoAP content to protect with a (D)TLS record header = prepended. - That would be set into the payload of a modified version of the = original CoAP message (before it is protected) that only contains = options that do not need to be protected. We think this could add to an interesting discussion to the subject of = Security for CoAP at application layer.=20 Comments are welcome,=20 Best Regards.= From nobody Tue Jan 17 04:42:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007C8129AA1; Tue, 17 Jan 2017 04:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9FN0Zv8BmsX; Tue, 17 Jan 2017 04:42:11 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF2F12943F; Tue, 17 Jan 2017 04:42:10 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9256E41FAF; Tue, 17 Jan 2017 13:42:07 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 493641DF; Tue, 17 Jan 2017 13:42:06 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B7D7E3B9; Tue, 17 Jan 2017 13:42:05 +0100 (CET) Received: (nullmailer pid 13017 invoked by uid 1000); Tue, 17 Jan 2017 12:42:04 -0000 Date: Tue, 17 Jan 2017 13:42:03 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-object-security@ietf.org, core@ietf.org, Jim Schaad , Francesca Palombini Message-ID: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hhhq5yfhspntd5vi" Content-Disposition: inline User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Subject: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 12:42:13 -0000 --hhhq5yfhspntd5vi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello OSCOAP authors and implementors, I'm taking a discussion from [oscoap:#49] to the list because it exceeds the topic of the issue, and maybe could use feedback from poeple not directly involved with the detail of the issue. I think that the protection currently drafted for the inner blockwise option (that is, using the MAC of the previous exchanged block as part of the AAD in securing the next block, thus creating a chain of authenticated messages), is rather intrusive: It requires retaining additional state, and requires the message protection part to interact with the blockwise transfer part). What I am advocating is a slimmer course of action, like determining resource consistency using an ETag, to achieve the same protection. (If an ETag is insufficient, maybe a Secure-ETag that's required to change under these or those conditions is.) I suggest thinking about the block2 case first, as if it turns out that tag chaining is absolutely required there, things won't be any easier for the block1 case. Jim Schaad wrote in [oscoap:#49]: > the reason for using the crypto tag is to have the ability to > establish that the entire message has been integrity protected rather > than just the independent pieces But does chaining the tags actually achieve that? All they establish is that both client and server agree that there was a continuous exchange of messages that led to the last block transferred. A client could have skipped a block during the transfer (eg. because it already has the block), finish a securely chained transfer, and then would then still work with a partially secured resource.[1] We would need to require block transfers to be strictly iterating / not use cached ETags, but IMO that would lose so much of blockwise that it feels more like its own fragmentation scheme. Best regards Christian [oscoap:#49]: https://github.com/core-wg/oscoap/issues/49 [1]: Following the letter of the draft, the resource could even change during the transfer (provided no ETags are used), and the server could sign off the stream. That can be fixed easily in the draft, but requires implementations to transfer additional information between components. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --hhhq5yfhspntd5vi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlh+ERcACgkQOY0REtOk veFhDg/5AeofMyTxOXI5aJihK61segqsamhB7eHALiA71fzDBHVrY2KCkUL8jbQa w7NJf0ko7/WXUro/AomkK8W66I/XxraQ8Dg8ir7eWk1/Zg3b1kaJ5aZxxj7rykO1 X3x7RBpsrj8PEvFTpydEHS2Hdt8xrt6DAzeeHXhL/RTS1yiaB9ywueIIkiRrocWZ 087WMjUcD4sf+lqmMXc/l//BSklS3deFHSsk0MzN+d9JWCodSG9uAXtxG9jX72po L2X/BU4DTCOPhVli60GM2fK+aVTdgLL3KZapnrwJp+4QOQA5jwE8d3NzeRaa9wjw oRWh5LX63Wc6isn8vSdqTWrDVMt3q1KkAQ6MUU+oM59Wd1nOo46nHEK7cS7syHT2 057VPlmyth2YXiMGsiWuDmY8v0t+fpZTCCyPXm0gWf3Z+ZgT+F2vTEtrYs/IRULX Qrl/Vg8Fjh7PBbKcOWfwG8yJhSc7/M2r0xhMVMfmZKe76B1MPpu0fuW0LWdys0g8 zPkePQTRciOXwW5IHC/gOFtMmFPIdglPrDOC8H3A8vz5ki+aCDdsi9wdMkoaIyv1 wrF0tg+yW2OdlTAUGWcj3O6YsDC5ax90BdQsgfMlgF7vYBgkaO4G11XYvUo7+OGY 8N/8BtgjLPTRM3TEed7POIZpfOdevjxZtW+/f5VbfZ5uBzH4q+w= =Msi0 -----END PGP SIGNATURE----- --hhhq5yfhspntd5vi-- From nobody Tue Jan 17 05:38:53 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C42D128E18; Tue, 17 Jan 2017 05:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjNWPrkTbDd2; Tue, 17 Jan 2017 05:38:49 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC480127076; Tue, 17 Jan 2017 05:38:49 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id E95F241FAF; Tue, 17 Jan 2017 14:38:47 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 465891DF; Tue, 17 Jan 2017 14:38:46 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1977C3B9; Tue, 17 Jan 2017 14:38:46 +0100 (CET) Received: (nullmailer pid 17887 invoked by uid 1000); Tue, 17 Jan 2017 13:38:45 -0000 Date: Tue, 17 Jan 2017 14:38:45 +0100 From: chrysn To: =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20170117133845.j5klu7t5z42tqhmt@hephaistos.amsuess.com> References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r4xndosgd4xqlct5" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP: [...], sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 13:38:51 -0000 --r4xndosgd4xqlct5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello G=C3=B6ran, On Fri, Jan 13, 2017 at 05:46:22PM +0000, G=C3=B6ran Selander wrote: > >In its recipient context, if the device only stores something like the > >end of its receive window on flash, it'll take the communication partner > >up to window-size failed attempts (which it might not even be allowed to > >repeat) to get in the clear. >=20 > But the replay window mechanism OSCOAP has inherited from DTLS and ESP is > sliding, so maintaining this state in the event of a shutdown would > require writing the =E2=80=9Cright" edge of the window to flash each time= a new > highest sequence number has been received. I guess this is not desirable? My impression was that the requirements of OSCOAP are only that duplicate sequence numbers must not be accepted, and that all numbers much smaller than the highest seen one may be considered seen. ("much smaller" here means the window size, nothing should break if it's not implemented as a bitfield but for example as a sufficiently long list of numbers). Anyway, ... > However, in this case replay protection can be addressed with the Repeat > option defined in=20 > https://tools.ietf.org/html/draft-mattsson-core-coap-actuators-02 > On reboot, a server must not accept the first message received in a stored > security context, but respond with a Repeat option asking the client if it > recently made the request, and if so, to repeat the request using its > current sequence number, and include the same Repeat parameter for server > to verify freshness. >=20 > (The client reception behaviour after reboot is straightforward since the > client should only accept responses for requests made after reboot.) =2E.., I don't see how either of this would help in the situation I envisioned, which I might not have outlined to match my state of mind, so I'd try again: * We have a server and a client. * Both can face unannounced shutdowns with no reserve to do a last-moment persistent write. * Neither have the capability to do persistent writes after every network transaction. WLOG I'll assume that they'll only write to flash every 1000 network transactions. (I'll focus on the server side of those constraints). * The client starts using its seqno 1. The server accepts it, and marks all sequence numbers up to 1000 as seen in persistent memory, in order to function for 999 more transactions without flash writing. (It does keep a more detailed state in RAM). * The server responds with its seqno 1, marking all seqnos up to 1000 as used. The server now faces a power outage as above, and the client (none the wiser) asks again: * The client sends a request with seqno 2. The server discards it, because it was marked as "possibly already used". * The server responds with unproteted 4.01[1], because it stopped processing the request as per 6.3 par. 1. Even if the server used the actuators-02 Repeat option early enough (ie. before OSCOAP validation kicks in and discards the message), it would still not tell the client that it needs to advance it sequence number. (And if it were to tell that, it'd need to be tightly interleaved with the OSCOAP verification, because the "advance your seqno" information could only be given to a client whose request passes all checks *except* the early Partial IV check.) How can we go about this? All the best Christian [1]: or whatever is actually appropriate here, see https://github.com/core-wg/oscoap/issues/53 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --r4xndosgd4xqlct5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlh+HlwACgkQOY0REtOk veFWuA//cDCacOPVyuZbnQAPQYQA+qatPLxp2uXOU3JIxyC1TwhuaivBvQbX7THj XhmBObC0h1P+gcBo0aOu1ZuXZngll1AYimCsDUYerVsprGq+TrCeHl6re1GlXlG3 u8zhcKJpeB1wC+fpPCrYJ4sbB+KdxXtVwbhaDyR5L/0v+jXQ+nt1GBEpn5wRBLbb SyLdZc7d2bZnIYxa+vQvutH2AWkQD/OpTF1qnV5p11YgD7OWpuy8+eCQBBWv13B3 iogNW+KEKStCYlGHyL0QceCOpzEIGMPyRlZ5fDA6JLGoVKEGC4kDyqaE+IByaXtH 2KNL2dRQhje//KcpRRoPHZTSKJtRqeCAjIqxiDKDnqaZA/iwc3yDWVjCfGWR7QDK 0H26TU55OAVwuvE1ymzJoYxnV0qANUhWZc7SJKJmoObYsdXoPFwoO0/w/vzpxHFp MHZLAFDAnyFzprQf9KKFpme1Mbb/DHqCizTb7zFMB3Vl70V7Cgj+UDMRnsy8tyd3 G1EXdVI6vhV4cudZ2dcL7rPpXP1MCTtp6R/voFRvHzmZA91fTWafbYp3tzuhza34 WOfNVp86bBd8vlUgZI70/W+5FkKt5HzGHWIIr9ww6syT62GpEq8jCsyroYWsSMfJ Ymw3dHmzijXKKmosrA8sxnganMHInRzLHuKAlpgUT+wNTINypa4= =DvJU -----END PGP SIGNATURE----- --r4xndosgd4xqlct5-- From nobody Tue Jan 17 12:37:09 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DE612946E for ; Tue, 17 Jan 2017 12:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UeVT9HjvsDf for ; Tue, 17 Jan 2017 12:37:06 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E7B1293E4 for ; Tue, 17 Jan 2017 12:37:06 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id y143so64592995pfb.0 for ; Tue, 17 Jan 2017 12:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ilk4HRp1nM2/NZpIMCYQn4tiwg3js+Wwv8Ur6aHI5go=; b=NcpkzkIq/LvqVFjh1BMY6p5picwaraydlv5UhoJLPaGRztLHCwolH2qJDdMfbGBwin KwyZn5/JTpL81NopGJHssqfmrK16bNMndWedOjnVsAWmaDjKu5g/mvykKVcCPWSW+SlZ fW5iggOp+MegtILIoKY3sc4tug9oFyOk4CNGLlcKSj/92Yzvu9C1MUAnHY984PV7YcdA 0bzT0BfX84B8TRUY752ItGGyT81/CMAxAbUz4WOnbgVq9HAas6evQ4Pjp3Xvr0vQddBG 6LUFqCsbQlNJR6VY4W5WlpfKvmpun6lU+Fn4GGXdxve4CTof2s4sTGILFFNaKh72xzHq /m9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ilk4HRp1nM2/NZpIMCYQn4tiwg3js+Wwv8Ur6aHI5go=; b=BwPmxbARoQvOQi8zZ3UAg1b8fVxDq0RpFULeeGEL4RHhPMEtl/0MttTdveWGs1j+au YZbs4GuCbZ/JGRQ+EZeq5IjRWrf/uVIGJxZGdSVlftqe9Y8T9m89NHyPizlk/Kmik0y3 lLeXiIeVgnSul4Xkb7qlTsoR78oNqu6eNcFjCPRvANS0OrmhkxNtwq8v0pJZCZc2CfbY M+LR3tK5zz0kd9RNtPT8cy6EqyOQfOGEL9+9w06Ake81nTd5Ntm+2SxQlB1DJSyciwky lmrFYmfncIv2niIZobJJcJN63sE4EXlv20s+9JUQPXdyNofSuzz8jQtokky4KOb9F9sU 6XYA== X-Gm-Message-State: AIkVDXJR9l5xXAFy4PoXfK+s9SNdzLuaNIEfWSvyf7OLtDEhimkcjvGvDz22EKUFQ1wv9g== X-Received: by 10.84.197.1 with SMTP id m1mr42540328pld.123.1484685426092; Tue, 17 Jan 2017 12:37:06 -0800 (PST) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id a68sm58176549pgc.31.2017.01.17.12.37.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 Jan 2017 12:37:05 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_44184195-98D7-4523-9D5C-CA9EC8F929B0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <1D0BB896-A49B-4849-A9D8-8AC8E64E7B6F@tzi.org> Date: Tue, 17 Jan 2017 12:37:03 -0800 Message-Id: <8D1B7B4B-7D5D-4AB1-BF98-12A0CEB01DC7@gmail.com> References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> <1D0BB896-A49B-4849-A9D8-8AC8E64E7B6F@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:37:08 -0000 --Apple-Mail=_44184195-98D7-4523-9D5C-CA9EC8F929B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 15, 2017, at 11:42 PM, Carsten Bormann wrote: >=20 > If we want to change lt there, we probably should change gt as well. > The pair of .LT. and .GT. has been with us as a representation of = =E2=80=9C<=E2=80=9C and =E2=80=9C>" since FORTRAN II. > (There already is a bit of a surprise why there is no .LE. or .GE. =E2=80= =94 are notification thresholds always exclusive?) >=20 Some observations: I think in general equality is a weaker concept in systems without = naturally occuring values. However, there are naturally occuring values we see frequently in the = systems we are building; these are the minimum and maximum scale values = frequently represented by 0 and 100, respectively. It seems to me that le and ge would be more useful, simply by being able = to express le=3D0 and ge=3D100, where I only want to know if the scale = limit is reached In quantized linear systems it seems like the concepts gt and lt could = be synthesized using ge and le lt=3D0 and gt=3D100 do not have any useful meaning other than an = roundabout disable mechanism. Best regards, Michael --Apple-Mail=_44184195-98D7-4523-9D5C-CA9EC8F929B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 15, 2017, at 11:42 PM, Carsten Bormann <cabo@tzi.org> = wrote:

If we want to change lt there, we probably = should change gt as well.
The pair of .LT. and .GT. = has been with us as a representation of =E2=80=9C<=E2=80=9C and = =E2=80=9C>" since FORTRAN II.
(There already is a bit of a surprise why there = is no .LE. or .GE. =E2=80=94 are notification thresholds always = exclusive?)


Some observations:

I think in general equality is a weaker concept in systems = without naturally occuring values.

However, there are naturally occuring = values we see frequently in the systems we are building; these are the = minimum and maximum scale values frequently represented by 0 and 100, = respectively.

It= seems to me that le and ge would be more useful, simply by being able = to express le=3D0 and ge=3D100, where I only want to know if the scale = limit is reached

In quantized linear systems it seems like the concepts gt and = lt could be synthesized using ge and le

lt=3D0 and gt=3D100 do not have any = useful meaning other than an roundabout disable mechanism.

Best regards,

Michael


= --Apple-Mail=_44184195-98D7-4523-9D5C-CA9EC8F929B0-- From nobody Tue Jan 17 21:20:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5512944B for ; Tue, 17 Jan 2017 21:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubbQBUR0ZPYR for ; Tue, 17 Jan 2017 21:20:35 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0094.outbound.protection.outlook.com [104.47.34.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2BB1200A0 for ; Tue, 17 Jan 2017 21:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Aw9p0ZiezUWWSxSmBnVYLRAQNuwkdFKZxGufMbOlXwg=; b=DX821AKAaci9lwYGESBPx4908TNGRNFZ6BHUoPO9dSygFFmb8OfxCpQIXaIPiZvv9QdIcP9KM/n93gyNJQguB2jGtDMa8m6QUPpO2aeRdQicdKZMSZ2XJ2QBjxJRLrVI9VUMiSPfBq807+CkUr/ucN8FEddVNXTMLNeqhFjBWgw= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2379.namprd03.prod.outlook.com (10.166.207.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 18 Jan 2017 05:20:33 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0845.013; Wed, 18 Jan 2017 05:20:32 +0000 From: Brian Raymor To: "core@ietf.org WG" Thread-Topic: Update on coap-tcp-tls Thread-Index: AdJxScsC6iI1fqrBQMWxOzkXD5og6w== Date: Wed, 18 Jan 2017 05:20:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: cf996708-cd98-4051-39fa-08d43f61b9e9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2379; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 7:fq98NpqPT8Xy5TxvyYXjZF5vLDltFcsOvT5/8m+F3wYimLgWzpxTtfzVjVTkH+sBC0H2H8j3A09YXU862buqVlEVsgXKzYBzcqoL1xICm8u6GoVMinWN54KnVbvzytXDPIsEKZPPDYhP65rbMTMR8gMnqYXHd3hlJRDwePAamgfGIkJUuynI1rLZROjOHGNmjAUbwiUHfcairwP7pwNKH0V3duL2YkmEexzTifoXkofNPfDje8WD2IFri0BZj9kzSSiwInk9oidUr8/q+hb/e5BM8e+a6w1UgUmoZgde9LbxBHM81mAAdj9Hfk0PnCWMnNrUqZcFimari/t4KGLGQsSUWxe71K3CAta79G5rfudKsHqboOKd9+c2EOR/b1jJNZV3Mkv9o+j1iUEfaAg9/sOJDSmWJ4wieIq9FjodYR2O5saxbhWyNPlgeXnhHJClcebTuH6BoU1mNXIn2jG/aRk8ZsC4n/Q5yTCA0Eyg+EU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39850400002)(39410400002)(39860400002)(189002)(199003)(92566002)(102836003)(50986999)(74316002)(561944003)(7906003)(606005)(8990500004)(54356999)(33656002)(5660300001)(3846002)(6116002)(107886002)(101416001)(2900100001)(10290500002)(25786008)(6916009)(2906002)(66066001)(86612001)(7736002)(105586002)(5005710100001)(6436002)(3280700002)(86362001)(450100001)(6506006)(81156014)(790700001)(8676002)(53936002)(9686003)(97736004)(6306002)(54896002)(236005)(81166006)(99286003)(189998001)(55016002)(3660700001)(106356001)(8936002)(110136003)(68736007)(7696004)(230783001)(38730400001)(122556002)(77096006)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2379; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2380E0AFC872AB2FAAB1CF08837F0CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 05:20:32.6637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2379 Archived-At: Subject: [core] Update on coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 05:20:38 -0000 --_000_CY1PR03MB2380E0AFC872AB2FAAB1CF08837F0CY1PR03MB2380namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Most (21) of the WGLC issues have been addressed in the editor's draft and = closed: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=3D1 7 open issues remain - https://github.com/core-wg/coap-tcp-tls/issues: Signaling (5) Could the authors/contributors (Carsten, Hannes, Klaus) of draft-bormann-co= re-coap-sig-02 help clarify this set of issues - https://github.com/core-w= g/coap-tcp-tls/labels/request-clarification - Let me know if you'd prefer a= conference call to address. The remaining Signaling issue explores whether there are new requirements w= hen responding to a Ping - https://github.com/core-wg/coap-tcp-tls/issues/6= 9. Please review the issue for background and potential solutions. I'd welc= ome your thoughts. Securing CoAP issues (2) The Securing CoAP proposal was reviewed by G=F6ran and Hannes and "baked" o= n the list. It's ready to be closed: https://github.com/core-wg/coap-tcp-tls/issues/11 Bill has proposed an amendment for Securing WebSockets. Any WG comments? https://github.com/core-wg/coap-tcp-tls/issues/102 Thanks, ...Brian --_000_CY1PR03MB2380E0AFC872AB2FAAB1CF08837F0CY1PR03MB2380namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Most (21) of the WGLC issues have been addressed in = the editor’s draft and closed:

https://github.com/core-wg/coap-tcp-tls/milestone/4?= closed=3D1

 

7 open issues remain - https://github.c= om/core-wg/coap-tcp-tls/issues:

 

Signaling (5)

 

Could the authors/contributors (Carsten, Hannes, Kla= us) of draft-bormann-core-coap-sig-02 help clarify this set of issues - &nb= sp;https://github.com/core-wg/coap-tcp-tls/labels/request-clarificati= on – Let me know if you’d prefer a conference call to address.

 

The remaining Signaling issue explores whether there= are new requirements when responding to a Ping - https://githu= b.com/core-wg/coap-tcp-tls/issues/69. Please review the issue for backg= round and potential solutions. I’d welcome your thoughts.<= /span>

 

Securing CoAP issues (2)

 

The Securing CoAP proposal was reviewed by G=F6ran a= nd Hannes and “baked” on the list. It’s ready to be close= d:

https://github.com/core-wg/coap-tcp-tls/issues/11<= /span>

 

Bill has proposed an amendment for Securing WebSocke= ts. Any WG comments?

https://github.com/core-wg/coap-tcp-tls/issues/102

 

Thanks,

…Brian

 

 

 

 

--_000_CY1PR03MB2380E0AFC872AB2FAAB1CF08837F0CY1PR03MB2380namp_-- From nobody Tue Jan 17 22:05:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9E9129682 for ; Tue, 17 Jan 2017 22:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUaijq4unXFf for ; Tue, 17 Jan 2017 22:05:48 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53304129459 for ; Tue, 17 Jan 2017 22:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q+OS78hT5AeJe70Xs1naBNMgb1nzsRynbJU4qP9iG2g=; b=H0HsXOXt7+I0YZR5r9bZfu+0tP a8eln3a1jkvI2BEQ4AH18iOTOFuVF6rvw/NY+7LhUtVX9x82L9NZFCt0Q3AmAWOuvoZoSRLA16V3E /lFiNHFXzTi4kLbER9tSvUNbB6JoCnuKC7dit5L+W+e9NqrokK+R8gj/0a1Cle0j5bK3k3grm94vQ xLAm0HyVrWPk6S6ASTBurW3ASHOYXI0Gcxh4p3volUP0z92cU68I01H9Tgtbk2dj1ekCxd39gCOtb gY6aV8tC7k2YCBb6WLa5Yq2qG/kpFuHHuXCSFev9nRKTnC0pFiIzqCJAdncWSnWgOGThC7mO5/Wrb X+AiNJvg==; Received: from ppp118-209-149-35.lns20.mel8.internode.on.net ([118.209.149.35]:63036 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cTjNO-001zgP-J8; Wed, 18 Jan 2017 17:05:42 +1100 To: Michael Koster , Carsten Bormann References: <18846994-AC47-48A0-B32E-D7FD785A0E45@gmail.com> <003501d26c22$8e7fe540$ab7fafc0$@ioterop.com> <580A8B4F-919C-4420-897F-3C07056C5860@tzi.org> <8A2A0B1D-637E-47DD-875B-CCE7E0403A11@gmail.com> <0CA78EE9-41EC-4F01-8A5F-CCB0EE85BD7E@gmail.com> <005f01d26c31$3d1131a0$b73394e0$@ioterop.com> <1D0BB896-A49B-4849-A9D8-8AC8E64E7B6F@tzi.org> <8D1B7B4B-7D5D-4AB1-BF98-12A0CEB01DC7@gmail.com> From: Christian Groves Message-ID: Date: Wed, 18 Jan 2017 17:05:37 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <8D1B7B4B-7D5D-4AB1-BF98-12A0CEB01DC7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core@ietf.org Subject: Re: [core] Lifetime (lt) and Less Than (lt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 06:05:50 -0000 The band parameters we've previously discussed are essentially <= and >=. So if we rename the parameters what do people prefer? let, grt or lth, gth or something else? Regards, Christian On 18/01/2017 7:37 AM, Michael Koster wrote: > >> On Jan 15, 2017, at 11:42 PM, Carsten Bormann > > wrote: >> >> If we want to change lt there, we probably should change gt as well. >> The pair of .LT. and .GT. has been with us as a representation of “<“ >> and “>" since FORTRAN II. >> (There already is a bit of a surprise why there is no .LE. or .GE. — >> are notification thresholds always exclusive?) >> > > Some observations: > > I think in general equality is a weaker concept in systems without > naturally occuring values. > > However, there are naturally occuring values we see frequently in the > systems we are building; these are the minimum and maximum scale > values frequently represented by 0 and 100, respectively. > > It seems to me that le and ge would be more useful, simply by being > able to express le=0 and ge=100, where I only want to know if the > scale limit is reached > > In quantized linear systems it seems like the concepts gt and lt could > be synthesized using ge and le > > lt=0 and gt=100 do not have any useful meaning other than an > roundabout disable mechanism. > > Best regards, > > Michael > > From nobody Wed Jan 18 00:00:39 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77460129585; Wed, 18 Jan 2017 00:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-3.199, 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 1oe4Rb-UhVCq; Wed, 18 Jan 2017 00:00:37 -0800 (PST) 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 CFDF21294A8; Wed, 18 Jan 2017 00:00:36 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jan 2017 00:23:24 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , , References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> In-Reply-To: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> Date: Wed, 18 Jan 2017 00:00:14 -0800 Message-ID: <017f01d27160$e7ffb620$b7ff2260$@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: AQKtQcEG0jyjNh7M+HUa8yeT6gtoT5+IEeuA Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 08:00:38 -0000 Going back to first principles. My goals are: 1. The ability to prevent eavesdroppers from knowing what is being transmitted. 2. The ability to have end-to-end integrity on the entirety of the = content being sent. 3. The ability to do something about making traffic analysis harder. The first can be address with encryption. The second can be addressed with encryption as long as blocking does not rear its ugly head. The last I am ignoring at present. Doing the integrity protection on large items is simple if one only does outer blocking of the data. Simply encrypt the entire message and then = do the necessary blocking of the message. This breaks down if one wants to = do random access of the large block of data. G=F6ran has some additional problems with this approach as if a single block is corrupted, but = passes the checksum, then the entire set of block transfers needs to be done = again as it is impossible to know which of them was corrupted. The = introduction of inner blocking allowed for a simple way to address this issue, but = with the loss of the end-to-end integrity on the entirety of the message. At the time, I was not aware of the abilities to do random access of blocking. It is difficult to understand a couple of things about what = this means without knowing what the expected use cases of random access is supposed to be doing. I am not sure at the moment that I have any understanding of the = expected scenarios where random access would be used. The ones that I can think = of are: 1. I receive a message that provides a set of instructions with what = has changed and I can get incremental updates.=20 2. It is something that is large, but I might only care about pieces of = the data rather than the whole thing - such as a log file. In the first case, the integrity is probably better covered by the = contents of the set of instructions. In the second case I only care about the integrity of what has been transferred rather than the entire content. What other scenarios are there that people can think of where random = access is useful and what type of integrity checking of the data would be required/needed? Jim From nobody Wed Jan 18 02:18:59 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8A1294FE; Wed, 18 Jan 2017 02:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I5zY7ayQ3_p; Wed, 18 Jan 2017 02:18:56 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361CD129466; Wed, 18 Jan 2017 02:18:56 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-f5-587f410eca31 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 38.D4.25710.E014F785; Wed, 18 Jan 2017 11:18:54 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.95]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 18 Jan 2017 11:18:44 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: chrysn Thread-Topic: [core] OSCOAP: [...], sequence numbers Thread-Index: AQHSaxCGFcqj/qEuz0qLdPYr3fiZf6E2s4KAgAXzpYCAAXv1AA== Date: Wed, 18 Jan 2017 10:19:35 +0000 Message-ID: References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> <20170117133845.j5klu7t5z42tqhmt@hephaistos.amsuess.com> In-Reply-To: <20170117133845.j5klu7t5z42tqhmt@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <17C3E2D799AD2645A27481559768EFB6@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7pS6fY32EwdSX8habF9xms9j3dj2z xbR/Z1gcmD32Lr7G5LFkyU+mAKYoLpuU1JzMstQifbsEroxVqxexF/xwrpjWodrAOMOpi5GT Q0LAROLDrVtMXYxcHEIC6xglXs9cwwjhLGaUOLhhEhtIFZuAi8SDhkdMILaIgIzEyV3n2EFs ZoEaiRNHtoPZwgLGErf/PmeGqDGRWLd1FVCcA8h2kni73w4kzCKgKrFs9l8WEJtXwEJi0aYf bBC7zjFJdL3oA5vPKeAq8f7vK7C9jAJiEt9PrWGC2CUucevJfCaIqwUkluw5zwxhi0q8fPyP FcQWFdCTWP58DVRcSaJxyRNWkBuYBTQl1u/ShxhjLXH/4EdWCFtRYkr3Q3aIewQlTs58wjKB UXwWkm2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECo+7glt+6 OxhXv3Y8xCjAwajEw1tgWBchxJpYVlyZe4hRgoNZSYR3vm19hBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2Mfg1fN624uUNwc5WJUNUZceMLWV8aZ30t FlX2XaP362Ov1tdT5ds4107ZpvR8287zhyMzLQ4pLSsPeLNG0N9GtZ5lpfPaK+WsM7rm7e5U S/q34Zwwf6CY+t3ZN6bwBvcpfBA55vnZNKOmf2+76p4dM8o0P32oOS99T23q3Bdf19vI2sc6 ZSisUGIpzkg01GIuKk4EACROvIO2AgAA Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP: [...], sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 10:18:58 -0000 SGkgQ2hyaXN0aWFuLCANCg0KSW5saW5lDQoNCk9uIDIwMTctMDEtMTcgMTQ6MzgsICJjaHJ5c24i IDxjaHJ5c25AZnNmZS5vcmc+IHdyb3RlOg0KDQo+SGVsbG8gR8O2cmFuLA0KPg0KPk9uIEZyaSwg SmFuIDEzLCAyMDE3IGF0IDA1OjQ2OjIyUE0gKzAwMDAsIEfDtnJhbiBTZWxhbmRlciB3cm90ZToN Cj4+ID5JbiBpdHMgcmVjaXBpZW50IGNvbnRleHQsIGlmIHRoZSBkZXZpY2Ugb25seSBzdG9yZXMg c29tZXRoaW5nIGxpa2UgdGhlDQo+PiA+ZW5kIG9mIGl0cyByZWNlaXZlIHdpbmRvdyBvbiBmbGFz aCwgaXQnbGwgdGFrZSB0aGUgY29tbXVuaWNhdGlvbg0KPj5wYXJ0bmVyDQo+PiA+dXAgdG8gd2lu ZG93LXNpemUgZmFpbGVkIGF0dGVtcHRzICh3aGljaCBpdCBtaWdodCBub3QgZXZlbiBiZSBhbGxv d2VkDQo+PnRvDQo+PiA+cmVwZWF0KSB0byBnZXQgaW4gdGhlIGNsZWFyLg0KPj4gDQo+PiBCdXQg dGhlIHJlcGxheSB3aW5kb3cgbWVjaGFuaXNtIE9TQ09BUCBoYXMgaW5oZXJpdGVkIGZyb20gRFRM UyBhbmQgRVNQDQo+PmlzDQo+PiBzbGlkaW5nLCBzbyBtYWludGFpbmluZyB0aGlzIHN0YXRlIGlu IHRoZSBldmVudCBvZiBhIHNodXRkb3duIHdvdWxkDQo+PiByZXF1aXJlIHdyaXRpbmcgdGhlIOKA nHJpZ2h0IiBlZGdlIG9mIHRoZSB3aW5kb3cgdG8gZmxhc2ggZWFjaCB0aW1lIGEgbmV3DQo+PiBo aWdoZXN0IHNlcXVlbmNlIG51bWJlciBoYXMgYmVlbiByZWNlaXZlZC4gSSBndWVzcyB0aGlzIGlz IG5vdA0KPj5kZXNpcmFibGU/DQo+DQo+TXkgaW1wcmVzc2lvbiB3YXMgdGhhdCB0aGUgcmVxdWly ZW1lbnRzIG9mIE9TQ09BUCBhcmUgb25seSB0aGF0DQo+ZHVwbGljYXRlIHNlcXVlbmNlIG51bWJl cnMgbXVzdCBub3QgYmUgYWNjZXB0ZWQsDQoNCkp1c3QgdG8gY2xhcmlmeSwgZGlmZmVyZW50IG1l c3NhZ2VzIGNyZWF0ZWQgd2l0aCB0aGUgc2FtZSBzZWN1cml0eSBjb250ZXh0DQphbmQgSVYvc2Vx dWVuY2UgbnVtYmVyIG11c3QgYmUgcHJldmVudGVkIGJlY2F1c2UgaXQgYnJlYWtzIHRoZSBzZWN1 cml0eSBvZg0KdGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtLiBSZXBsYXkgb2Ygb2xkIG1lc3NhZ2Vz IG11c3QgYmUgcHJldmVudGVkIHRvDQpwcm90ZWN0IGZyb20gdW5uZWNlc3NhcnkgbWVzc2FnZSBo YW5kbGluZy4NCg0KDQo+YW5kIHRoYXQgYWxsIG51bWJlcnMNCj5tdWNoIHNtYWxsZXIgdGhhbiB0 aGUgaGlnaGVzdCBzZWVuIG9uZSBtYXkgYmUgY29uc2lkZXJlZCBzZWVuLiAoIm11Y2gNCj5zbWFs bGVyIiBoZXJlIG1lYW5zIHRoZSB3aW5kb3cgc2l6ZSwgbm90aGluZyBzaG91bGQgYnJlYWsgaWYg aXQncyBub3QNCj5pbXBsZW1lbnRlZCBhcyBhIGJpdGZpZWxkIGJ1dCBmb3IgZXhhbXBsZSBhcyBh IHN1ZmZpY2llbnRseSBsb25nIGxpc3Qgb2YNCj5udW1iZXJzKS4gQW55d2F5LCAuLi4NCj4NCj4+ IEhvd2V2ZXIsIGluIHRoaXMgY2FzZSByZXBsYXkgcHJvdGVjdGlvbiBjYW4gYmUgYWRkcmVzc2Vk IHdpdGggdGhlIFJlcGVhdA0KPj4gb3B0aW9uIGRlZmluZWQgaW4NCj4+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3JzLTAyDQo+PiBP biByZWJvb3QsIGEgc2VydmVyIG11c3Qgbm90IGFjY2VwdCB0aGUgZmlyc3QgbWVzc2FnZSByZWNl aXZlZCBpbiBhDQo+PnN0b3JlZA0KPj4gc2VjdXJpdHkgY29udGV4dCwgYnV0IHJlc3BvbmQgd2l0 aCBhIFJlcGVhdCBvcHRpb24gYXNraW5nIHRoZSBjbGllbnQgaWYNCj4+aXQNCj4+IHJlY2VudGx5 IG1hZGUgdGhlIHJlcXVlc3QsIGFuZCBpZiBzbywgdG8gcmVwZWF0IHRoZSByZXF1ZXN0IHVzaW5n IGl0cw0KPj4gY3VycmVudCBzZXF1ZW5jZSBudW1iZXIsIGFuZCBpbmNsdWRlIHRoZSBzYW1lIFJl cGVhdCBwYXJhbWV0ZXIgZm9yDQo+PnNlcnZlcg0KPj4gdG8gdmVyaWZ5IGZyZXNobmVzcy4NCj4+ IA0KPj4gKFRoZSBjbGllbnQgcmVjZXB0aW9uIGJlaGF2aW91ciBhZnRlciByZWJvb3QgaXMgc3Ry YWlnaHRmb3J3YXJkIHNpbmNlDQo+PnRoZQ0KPj4gY2xpZW50IHNob3VsZCBvbmx5IGFjY2VwdCBy ZXNwb25zZXMgZm9yIHJlcXVlc3RzIG1hZGUgYWZ0ZXIgcmVib290LikNCj4NCj4uLi4sIEkgZG9u J3Qgc2VlIGhvdyBlaXRoZXIgb2YgdGhpcyB3b3VsZCBoZWxwIGluIHRoZSBzaXR1YXRpb24gSQ0K PmVudmlzaW9uZWQsIHdoaWNoIEkgbWlnaHQgbm90IGhhdmUgb3V0bGluZWQgdG8gbWF0Y2ggbXkg c3RhdGUgb2YgbWluZCwNCj5zbyBJJ2QgdHJ5IGFnYWluOg0KPg0KPiogV2UgaGF2ZSBhIHNlcnZl ciBhbmQgYSBjbGllbnQuDQo+KiBCb3RoIGNhbiBmYWNlIHVuYW5ub3VuY2VkIHNodXRkb3ducyB3 aXRoIG5vIHJlc2VydmUgdG8gZG8gYQ0KPiAgbGFzdC1tb21lbnQgcGVyc2lzdGVudCB3cml0ZS4N Cj4qIE5laXRoZXIgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBkbyBwZXJzaXN0ZW50IHdyaXRlcyBh ZnRlciBldmVyeQ0KPiAgbmV0d29yayB0cmFuc2FjdGlvbi4gV0xPRyBJJ2xsIGFzc3VtZSB0aGF0 IHRoZXknbGwgb25seSB3cml0ZSB0byBmbGFzaA0KPiAgZXZlcnkgMTAwMCBuZXR3b3JrIHRyYW5z YWN0aW9ucy4NCj4NCj4oSSdsbCBmb2N1cyBvbiB0aGUgc2VydmVyIHNpZGUgb2YgdGhvc2UgY29u c3RyYWludHMpLg0KPg0KPiogVGhlIGNsaWVudCBzdGFydHMgdXNpbmcgaXRzIHNlcW5vIDEuIFRo ZSBzZXJ2ZXIgYWNjZXB0cyBpdCwgYW5kIG1hcmtzDQo+ICBhbGwgc2VxdWVuY2UgbnVtYmVycyB1 cCB0byAxMDAwIGFzIHNlZW4gaW4gcGVyc2lzdGVudCBtZW1vcnkgaW4gb3JkZXINCj4gIHRvIGZ1 bmN0aW9uIGZvciA5OTkgbW9yZSB0cmFuc2FjdGlvbnMgd2l0aG91dCBmbGFzaCB3cml0aW5nLiAo SXQgZG9lcw0KPiAga2VlcCBhIG1vcmUgZGV0YWlsZWQgc3RhdGUgaW4gUkFNKS4NCj4qIFRoZSBz ZXJ2ZXIgcmVzcG9uZHMgd2l0aCBpdHMgc2Vxbm8gMSwgbWFya2luZyBhbGwgc2Vxbm9zIHVwIHRv IDEwMDAgYXMNCj4gIHVzZWQuDQo+DQo+VGhlIHNlcnZlciBub3cgZmFjZXMgYSBwb3dlciBvdXRh Z2UgYXMgYWJvdmUsIGFuZCB0aGUgY2xpZW50IChub25lIHRoZQ0KPndpc2VyKSBhc2tzIGFnYWlu Og0KPg0KPiogVGhlIGNsaWVudCBzZW5kcyBhIHJlcXVlc3Qgd2l0aCBzZXFubyAyLiBUaGUgc2Vy dmVyIGRpc2NhcmRzIGl0LA0KPiAgYmVjYXVzZSBpdCB3YXMgbWFya2VkIGFzICJwb3NzaWJseSBh bHJlYWR5IHVzZWQiLg0KPiogVGhlIHNlcnZlciByZXNwb25kcyB3aXRoIHVucHJvdGV0ZWQgNC4w MVsxXSwgYmVjYXVzZSBpdCBzdG9wcGVkDQo+ICBwcm9jZXNzaW5nIHRoZSByZXF1ZXN0IGFzIHBl ciA2LjMgcGFyLiAxLg0KPg0KPkV2ZW4gaWYgdGhlIHNlcnZlciB1c2VkIHRoZSBhY3R1YXRvcnMt MDIgUmVwZWF0IG9wdGlvbiBlYXJseSBlbm91Z2ggKGllLg0KPmJlZm9yZSBPU0NPQVAgdmFsaWRh dGlvbiBraWNrcyBpbiBhbmQgZGlzY2FyZHMgdGhlIG1lc3NhZ2UpLCBpdCB3b3VsZA0KPnN0aWxs IG5vdCB0ZWxsIHRoZSBjbGllbnQgdGhhdCBpdCBuZWVkcyB0byBhZHZhbmNlIGl0IHNlcXVlbmNl IG51bWJlci4NCj4oQW5kIGlmIGl0IHdlcmUgdG8gdGVsbCB0aGF0LCBpdCdkIG5lZWQgdG8gYmUg dGlnaHRseSBpbnRlcmxlYXZlZCB3aXRoDQo+dGhlIE9TQ09BUCB2ZXJpZmljYXRpb24sIGJlY2F1 c2UgdGhlICJhZHZhbmNlIHlvdXIgc2Vxbm8iIGluZm9ybWF0aW9uDQo+Y291bGQgb25seSBiZSBn aXZlbiB0byBhIGNsaWVudCB3aG9zZSByZXF1ZXN0IHBhc3NlcyBhbGwgY2hlY2tzICpleGNlcHQq DQo+dGhlIGVhcmx5IFBhcnRpYWwgSVYgY2hlY2suKQ0KPg0KPkhvdyBjYW4gd2UgZ28gYWJvdXQg dGhpcz8NCg0KVGhhbmtzIGZvciBzcGVsbGluZyBvdXQgdGhlIGRldGFpbHMuIEkgdGhpbmsgeW91 IGFyZSByaWdodCB3ZSBuZWVkDQpzb21ldGhpbmcgc2xpZ2h0bHkgbW9yZSBlbGFib3JhdGUgaGVy ZS4gSSBiZWxpZXZlIHRoZXJlIGFyZSB0d28gd2F5cyB0bw0KcmVzb2x2ZSB0aGUgaXNzdWU6IEVp dGhlciB0aGUgc2VydmVyIGdldHMgdmVyaWZpYWJsZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCmN1 cnJlbnQgc2VxdWVuY2UgbnVtYmVyIGJ5IHRoZSBjbGllbnQsIG9yIHRoZSBjbGllbnQgZ2V0cyBp bmZvcm1hdGlvbiB0aGF0DQppdCBzaG91bGQgY29udGludWUgY291bnRpbmcgZnJvbSB0aGUgcGVy c2lzdGVudGx5IHN0b3JlZCBzZXF1ZW5jZSBudW1iZXIuDQpIZXJlIGlzIGFuIGF0dGVtcHQgdG8g YWRkcmVzcyB0aGUgbGF0dGVyOg0KDQpXaGVuIHRoZSBzZXJ2ZXIgcmVib290cyBhbmQgbG9hZHMg dGhlIHNlcXVlbmNlIG51bWJlciBmcm9tIHBlcnNpc3RlbnQNCnN0b3JhZ2UgaXQgaXMgaW4gYSBz ZXF1ZW5jZSBudW1iZXIg4oCcaWdub3JhbnQiIHN0YXRlIGFuZCB0aGlzIHN0YXRlIG11c3QgYmUN Cm1vbml0b3JlZCBieSBPU0NPQVA6IEFzc3VtZSBhIHNlcXVlbmNlIG51bWJlciBzdGF0ZSBwYXJh bWV0ZXIga2VwdCBpbiB0aGUNCnJlY2lwaWVudCBjb250ZXh0IGFuZCByZWFkIG91dCBmcm9tIHBl cnNpc3RlbnQgc3RvcmFnZSAod2hlcmUgaXQgaXMgYQ0KY29uc3RhbnQgc2V0IHRvICJpZ25vcmFu dOKAnSkgd2hlbiB0aGUgc2VjdXJpdHkgY29udGV4dCBpcyBsb2FkZWQgaW50byBSQU0uDQoNCklm IHRoZSBhIHNlcXVlbmNlIG51bWJlciBzdGF0ZSBwYXJhbWV0ZXIgaXMgc2V0IHRvIOKAnGlnbm9y YW504oCdIGFuZCBhDQptZXNzYWdlIGlzIHJlY2VpdmVkIGFuZCB2ZXJpZmllZCBoYXZpbmcgYSBz ZXF1ZW5jZSBudW1iZXIgaGlnaGVyIHRoYW4gdGhhdA0KaW4gdGhlIHJlY2lwaWVudCBjb250ZXh0 LCB0aGVuIHRoZSBzdGF0ZSBpcyBzZXQgdG8g4oCcbm90IGlnbm9yYW504oCdLiBJZiB0aGUNCnN0 YXRlIGlzIHNldCB0byAibm90IGlnbm9yYW504oCdIHRoZW4gdGhlIGN1cnJlbnRseSBkZWZpbmVk IHByb2Nlc3NpbmcNCmFwcGxpZXMuIA0KDQpJZiB0aGUgYSBzZXF1ZW5jZSBudW1iZXIgc3RhdGUg cGFyYW1ldGVyIGlzIHNldCB0byDigJxpZ25vcmFudOKAnSBhbmQgYQ0KbWVzc2FnZSBpcyByZWNl aXZlZCB3aGljaCBoYXMgYSBzZXF1ZW5jZSBudW1iZXIgbG93ZXIgdGhhdCB0aGFuIHRoYXQgb2YN CnRoZSByZWNpcGllbnQgY29udGV4dCAoYW5kIGdyZWF0ZXIgdGhhbiAwIHRvIGF2b2lkIHRoaXMg cHJvY2VkdXJlIHdoZW4gdGhlDQpmaXJzdCBtZXNzYWdlIGlzIHNlbnQgdXNpbmcgdGhpcyBjb250 ZXh0KSwgdGhlbiB0aGUgc2VydmVyIHJlc3BvbmRzIHdpdGgNCmFuIGVycm9yIG1lc3NhZ2UgVEJE IGluZGljYXRpbmcgdGhhdCBpdCBoYXMgbG9zdCB0cmFjayBvZiBpdHMgcmVjaXBpZW50DQpzZXF1 ZW5jZSBudW1iZXJzLg0KDQpUaGUgY2xpZW50IHJlY2VpdmluZyB0aGlzIGVycm9yIG1lc3NhZ2Ug bG9hZHMgdGhlIHNlcXVlbmNlIG51bWJlciBmb3IgdGhpcw0KY29udGV4dCBmcm9tIHBlcnNpc3Rl bnQgc3RvcmFnZSBhbmQgcmVzZW5kcyB0aGUgcmVxdWVzdC4NCg0KV291bGQgc29tZXRoaW5nIGxp a2UgdGhhdCBtYWtlIHNlbnNlPw0KDQooV2Ugd291bGQgbmVlZCB0byB0aGluayBtb3JlIGFib3V0 IHRoZSBjb250ZW50IG9mIHRoZSBlcnJvciBtZXNzYWdlLCBzaW5jZQ0KdGhhdCBtYXkgZWl0aGVy IHJlcXVpcmUgdGhlIHNlcnZlciB0byBwcm9kdWNlIGEgdmVyaWZpYWJsZSByZXNwb25zZSBldmVu DQp0aG91Z2ggdGhlIHJlcXVlc3QgaXMgbm90IHZlcmlmaWVkLCBvciBleHBvc2UgdGhlIGNsaWVu dCB0byBzZXF1ZW5jZQ0KbnVtYmVyIGp1bXAgYXR0YWNrcyBmcm9tIGFjdGl2ZSBhdHRhY2tlcnMu IFRoZSBmb3JtZXIgaXMgcG9zc2libGUgc2luY2UNCnRoZSBzZXJ2ZXIgaGFzIGxvYWRlZCB0aGUg c2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgc2VuZGVyIGNvbnRleHQgZnJvbSB0aGUNCnBlcnNpc3Rl bnQgc3RvcmFnZSwgYW5kIHNlZW1zIG1vc3QgcmVsZXZhbnQgc2luY2UgdGhpcyBzaG91bGQgYmUg YW4NCmV4Y2VwdGlvbmFsIHN0YXRlIG9mIHRoZSBzZXJ2ZXIuIE5vdGUgdGhhdCB0aGlzIHdvcmtz IGFsc28gaW4gdGhlIGNhc2Ugb2YNCnRoZSBjbGllbnQgcmVib290aW5nLCBlLmcuIGR1ZSB0byB0 aGUgc2FtZSBwb3dlciBvdXRhZ2UuKQ0KDQoNCg0KDQoNCg0KVGhhbmtzDQpHw7ZyYW4NCg0KDQoN Cj4NCj5BbGwgdGhlIGJlc3QNCj5DaHJpc3RpYW4NCj4NCj5bMV06IG9yIHdoYXRldmVyIGlzIGFj dHVhbGx5IGFwcHJvcHJpYXRlIGhlcmUsIHNlZQ0KPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L29zY29hcC9pc3N1ZXMvNTMNCj4NCj4tLSANCj5UbyB1c2UgcmF3IHBvd2VyIGlzIHRvIG1ha2Ug eW91cnNlbGYgaW5maW5pdGVseSB2dWxuZXJhYmxlIHRvIGdyZWF0ZXINCj5wb3dlcnMuDQo+ICAt LSBCZW5lIEdlc3Nlcml0IGF4aW9tDQoNCg== From nobody Wed Jan 18 03:46:16 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91012948A for ; Wed, 18 Jan 2017 03:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G57Nrg3wSxV0 for ; Wed, 18 Jan 2017 03:46:13 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF0312941E for ; Wed, 18 Jan 2017 03:46:12 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.203]) by smtp-cloud3.xs4all.net with ESMTP id ZnmA1u00B4NtgTm01nmAwm; Wed, 18 Jan 2017 12:46:11 +0100 Received: from AMontpellier-654-1-132-207.w90-0.abo.wanadoo.fr ([90.0.91.207]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Jan 2017 12:46:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Jan 2017 12:46:10 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> Message-ID: <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 11:46:15 -0000 Hi all, A new version of I-D, draft-vanderstok-core-comi-11.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. @chairs, this is the version to confirm the adoption over the mailing list. Greetings, Peter Name: draft-vanderstok-core-comi Revision: 11 Title: CoAP Management Interface Document date: 2017-01-18 Group: Individual Submission Pages: 46 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-11.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-comi-11 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-11 Abstract: This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access data resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CoMI extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Jan 18 03:53:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDC8129599 for ; Wed, 18 Jan 2017 03:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbe5p89IpQeA for ; Wed, 18 Jan 2017 03:53:16 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676AF12940C for ; Wed, 18 Jan 2017 03:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0IBrCM4018206 for ; Wed, 18 Jan 2017 12:53:12 +0100 (CET) Received: from [172.20.10.9] (ip-109-45-0-54.web.vodafone.de [109.45.0.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3v3QMf2dgJz3Zjm; Wed, 18 Jan 2017 12:52:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> Date: Wed, 18 Jan 2017 12:52:48 +0100 Cc: Core X-Mao-Original-Outgoing-Id: 506433168.471433-9e8e98d193ec62997fabea56eb149b71 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_WG_adoption_o?= =?utf-8?q?f_draft-vanderstok-core-comi-11=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 11:53:18 -0000 > On 18 Jan 2017, at 12:46, peter van der Stok = wrote: >=20 > Hi all, >=20 > A new version of I-D, draft-vanderstok-core-comi-11.txt > has been successfully submitted by Peter van der Stok and posted to = the > IETF repository. >=20 > @chairs, this is the version to confirm the adoption over the mailing = list. Indeed. In Seoul, we had in-room consensus to adopt this draft as a WG document, = filling in the remaining gap of the COMI/COOL series of documents. We = said we needed to confirm that consensus on the mailing list, but = didn=E2=80=99t do that immediately, and then there was a new version = impending. That new version is now available. So if you do not agree with the = in-room consensus that we had in Seoul to adopt this as a WG document, = please speak up until the end of 2017-01-25. (If you weren=E2=80=99t in = the room but do agree with adopting this document, you can also tell = us.) Gr=C3=BC=C3=9Fe, Carsten > Name: draft-vanderstok-core-comi > Revision: 11 > Title: CoAP Management Interface > Document date: 2017-01-18 > Group: Individual Submission > Pages: 46 > URL: = https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-11.txt > Status: = https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ > Htmlized: = https://tools.ietf.org/html/draft-vanderstok-core-comi-11 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-core-comi-11 >=20 > Abstract: > This document describes a network management interface for > constrained devices and networks, called CoAP Management Interface > (CoMI). The Constrained Application Protocol (CoAP) is used to > access data resources specified in YANG, or SMIv2 converted to YANG. > CoMI uses the YANG to CBOR mapping and converts YANG identifier > strings to numeric identifiers for payload size reduction. CoMI > extends the set of YANG based protocols, NETCONF and RESTCONF, with > the capability to manage constrained devices and networks. From nobody Wed Jan 18 09:33:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8C812954D for ; Wed, 18 Jan 2017 09:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX1huMs4Z71c for ; Wed, 18 Jan 2017 09:33:27 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6811294EF for ; Wed, 18 Jan 2017 09:33:27 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id x49so19984131qtc.2 for ; Wed, 18 Jan 2017 09:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2VeKROhyYEoQyEXCHAbATbN+sRfzFmpLuo5yeMBv1sE=; b=jSQnp09krfGW8mXolZBAlU+Jg9MekZW9ll1raGyoKntxUZstUCrgF2sgviQbLKnU2Y 8t8oTAYTGDo6EVlsQV7pQ66HTzJoAe6jXAovLNvJmBrbBuHA5AtEZx2ckJQewasv7dTn aOkrBP9VOUKmQ0wuj1dd5SRpnqc69MFJYAdzQjcxmwkUOaL/UJQFdUEkoNkoMJ1s+4J9 0wlfV/V7nAn9hsl1dhuFlqUsR6NK0oDLodHlDLdV8F5PkNgnWpEcQ6iquixC0Xt4SYzT UvB2bzGTzCUgMUxhxFjZj+s8TADEzP9VHmWU1HpZND2SNrAORYgdm/b28Rfh24N6rQyo 8uow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2VeKROhyYEoQyEXCHAbATbN+sRfzFmpLuo5yeMBv1sE=; b=GZzDJwNI/ja/czjm4YMKuInLAC0jZpERAsWLRfMkyfdrgfqYTjcqbuTW0FLHQPJrtW EPLSuhTTPNL2+c8DxeV9x7mADNBNG5AX5DJYSEUb/ifUrAxXegc0sg64hScQcl2j3UBn 7N5ddBRTffS6vtA6oRaKemR7PtMuKZqkUthvZbwkuNEbm/sKvz6+4nGY1gxYXLdDWj0t JFCQd+duyfnQbWM8tVZ91lTb0dKGo739yeISTY8hxf2bFN2CxXAajuB0lxYK7bCdzuYc fkn3j4FqTlVP/BKaP7ENiT7NKW04ys9gamCLS2Yb+JFrjRigZmviIe2OyLrn0N5chdf1 1p0A== X-Gm-Message-State: AIkVDXLC3rQqtJj4OUMJOzEIpKdTQHktrahzfSJNBcuh+juG+hjnzUDpshQciIgNwPc4Wg== X-Received: by 10.55.69.68 with SMTP id s65mr4460861qka.72.1484760806076; Wed, 18 Jan 2017 09:33:26 -0800 (PST) Received: from [10.29.123.28] (mobile-166-171-058-132.mycingular.net. [166.171.58.132]) by smtp.gmail.com with ESMTPSA id c198sm704489qka.48.2017.01.18.09.33.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 09:33:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: James Nguyen X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Wed, 18 Jan 2017 12:33:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> To: Carsten Bormann Archived-At: Cc: Core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_WG_adoption_o?= =?utf-8?q?f_draft-vanderstok-core-comi-11=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:33:29 -0000 Hi WG, I strongly support this document. James > On Jan 18, 2017, at 6:52 AM, Carsten Bormann wrote: >=20 >=20 >> On 18 Jan 2017, at 12:46, peter van der Stok wrote: >>=20 >> Hi all, >>=20 >> A new version of I-D, draft-vanderstok-core-comi-11.txt >> has been successfully submitted by Peter van der Stok and posted to the >> IETF repository. >>=20 >> @chairs, this is the version to confirm the adoption over the mailing lis= t. >=20 > Indeed. >=20 > In Seoul, we had in-room consensus to adopt this draft as a WG document, f= illing in the remaining gap of the COMI/COOL series of documents. We said w= e needed to confirm that consensus on the mailing list, but didn=E2=80=99t d= o that immediately, and then there was a new version impending. >=20 > That new version is now available. So if you do not agree with the in-roo= m consensus that we had in Seoul to adopt this as a WG document, please spea= k up until the end of 2017-01-25. (If you weren=E2=80=99t in the room but d= o agree with adopting this document, you can also tell us.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >> Name: draft-vanderstok-core-comi >> Revision: 11 >> Title: CoAP Management Interface >> Document date: 2017-01-18 >> Group: Individual Submission >> Pages: 46 >> URL: https://www.ietf.org/internet-drafts/draft-vanderstok-cor= e-comi-11.txt >> Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-co= mi/ >> Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-comi-11= >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-core= -comi-11 >>=20 >> Abstract: >> This document describes a network management interface for >> constrained devices and networks, called CoAP Management Interface >> (CoMI). The Constrained Application Protocol (CoAP) is used to >> access data resources specified in YANG, or SMIv2 converted to YANG. >> CoMI uses the YANG to CBOR mapping and converts YANG identifier >> strings to numeric identifiers for payload size reduction. CoMI >> extends the set of YANG based protocols, NETCONF and RESTCONF, with >> the capability to manage constrained devices and networks. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 18 10:42:08 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7575E128874 for ; Wed, 18 Jan 2017 10:42:06 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YEEOChbGoU0F for ; Wed, 18 Jan 2017 10:42:04 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F60D12956C for ; Wed, 18 Jan 2017 10:41:52 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 104so15058340otd.3 for ; Wed, 18 Jan 2017 10:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hTM+n040WZodP0Lhp6FHeyXx3PDXaNS68QAWmWZS8OU=; b=WdZZybVu+cobqtlw2HjAmk7o3kFdyx1vnGno24i5y8HbCvwIg5B9ShRv3Lenz7biGU wedns5nzIDqyKY+Y4FDYMg4XfK5+MI27NPgHcWvHamPvYtQK4OwI/WpSztYkRZVuky6q WylR7BXuyHG6LuRBncWzNGEIqQsAtvrdsuXStdKs6lJ3NaaJtv7PWO3G2UCh8eSQ7NNv +27CByoJ6DiIbJMuaKblRHw099WapOk8IYnhI9tqnI9g0RfSJOT0VLFaoPpyAvqPD2l8 RfquwH4l0X9342e+NUgOiYNuXNu6TLyZn6GK2k6+rDgXFR/3t8wInKPsQD1uWwA16aJk G3JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hTM+n040WZodP0Lhp6FHeyXx3PDXaNS68QAWmWZS8OU=; b=qHMuin0W1wTChSOIPZvpWRHEu+Hii5zb7fhzfGsnI71S9Flj+yejruLA58tiWsBQrH 4GGPBTnMXTFOf9+dX/YN3kS6C3x3605xD4dLML7CMxsQ64vWsnFQBYc4iwIvoWQmmCuq 391+ma80OiUK7j+XFCEA/g1Ctyvo/8lMguBHJ+abXPat2HXmKL2zTQMiifA3vwskl67z ssoN3mgCOXAJc5B2cGGO3cle/tbQad4TTsuRGiJBYgj0B0H0+Ts3j9Zmc7k2fGnIrjIX hegp9m73hwxVyXUVhgSQZ+rHTDq/bA9vfuL0JyqPqSr+NgN3ccB7QYk8cIQ2XRUDslWa rEhQ== X-Gm-Message-State: AIkVDXJs+fHFH8qaO/VQLjozgBP4VZA2QcTX32+XwsJYWgImKuvQqI4Z3lckc/3cnyncwMD0hs1qbtd+td/dJA== X-Received: by 10.157.27.169 with SMTP id z38mr2185313otd.262.1484764911968; Wed, 18 Jan 2017 10:41:51 -0800 (PST) MIME-Version: 1.0 Sender: anaminaburo@gmail.com Received: by 10.202.68.131 with HTTP; Wed, 18 Jan 2017 10:41:31 -0800 (PST) In-Reply-To: References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> From: Ana Minaburo Date: Wed, 18 Jan 2017 19:41:31 +0100 X-Google-Sender-Auth: Cx9BMn_56GpxR_H6BuRCLyfCuFs Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113cc7fa2725a2054662c5a6 Archived-At: Cc: Core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_WG_adoption_o?= =?utf-8?q?f_draft-vanderstok-core-comi-11=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:42:06 -0000 --001a113cc7fa2725a2054662c5a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I also supports this document. Ana On Wed, Jan 18, 2017 at 12:52 PM, Carsten Bormann wrote: > > > On 18 Jan 2017, at 12:46, peter van der Stok wrote= : > > > > Hi all, > > > > A new version of I-D, draft-vanderstok-core-comi-11.txt > > has been successfully submitted by Peter van der Stok and posted to the > > IETF repository. > > > > @chairs, this is the version to confirm the adoption over the mailing > list. > > Indeed. > > In Seoul, we had in-room consensus to adopt this draft as a WG document, > filling in the remaining gap of the COMI/COOL series of documents. We sa= id > we needed to confirm that consensus on the mailing list, but didn=E2=80= =99t do that > immediately, and then there was a new version impending. > > That new version is now available. So if you do not agree with the > in-room consensus that we had in Seoul to adopt this as a WG document, > please speak up until the end of 2017-01-25. (If you weren=E2=80=99t in = the room > but do agree with adopting this document, you can also tell us.) > > Gr=C3=BC=C3=9Fe, Carsten > > > Name: draft-vanderstok-core-comi > > Revision: 11 > > Title: CoAP Management Interface > > Document date: 2017-01-18 > > Group: Individual Submission > > Pages: 46 > > URL: https://www.ietf.org/internet- > drafts/draft-vanderstok-core-comi-11.txt > > Status: https://datatracker.ietf.org/doc/draft-vanderstok-core- > comi/ > > Htmlized: https://tools.ietf.org/html/ > draft-vanderstok-core-comi-11 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-co= re- > comi-11 > > > > Abstract: > > This document describes a network management interface for > > constrained devices and networks, called CoAP Management Interface > > (CoMI). The Constrained Application Protocol (CoAP) is used to > > access data resources specified in YANG, or SMIv2 converted to YANG. > > CoMI uses the YANG to CBOR mapping and converts YANG identifier > > strings to numeric identifiers for payload size reduction. CoMI > > extends the set of YANG based protocols, NETCONF and RESTCONF, with > > the capability to manage constrained devices and networks. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a113cc7fa2725a2054662c5a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I also supports this document.

Ana

On Wed, Jan 18, 2017 at 12:52 PM, Carsten Bormann <cabo@t= zi.org> wrote:

> On 18 Jan 2017, at 12:46, peter van der Stok <stokcons@xs4all.nl> wrote:
>
> Hi all,
>
> A new version of I-D, draft-vanderstok-core-comi-11.txt
> has been successfully submitted by Peter van der Stok and posted to th= e
> IETF repository.
>
> @chairs, this is the version to confirm the adoption over the mailing = list.

Indeed.

In Seoul, we had in-room consensus to adopt this draft as a WG document, fi= lling in the remaining gap of the COMI/COOL series of documents.=C2=A0 We s= aid we needed to confirm that consensus on the mailing list, but didn=E2=80= =99t do that immediately, and then there was a new version impending.

That new version is now available.=C2=A0 So if you do not agree with the in= -room consensus that we had in Seoul to adopt this as a WG document, please= speak up until the end of 2017-01-25.=C2=A0 (If you weren=E2=80=99t in the= room but do agree with adopting this document, you can also tell us.)

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

> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-vanderstok-core-comi
> Revision:=C2=A0 =C2=A0 =C2=A011
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CoAP Man= agement Interface
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-01-18
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 46
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-vander= stok-core-comi-11.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-vanderstok-core-comi= /
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-vanderstok-core-comi-11
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-c= ore-comi-11
>
> Abstract:
>=C2=A0 =C2=A0This document describes a network management interface for=
>=C2=A0 =C2=A0constrained devices and networks, called CoAP Management I= nterface
>=C2=A0 =C2=A0(CoMI).=C2=A0 The Constrained Application Protocol (CoAP) = is used to
>=C2=A0 =C2=A0access data resources specified in YANG, or SMIv2 converte= d to YANG.
>=C2=A0 =C2=A0CoMI uses the YANG to CBOR mapping and converts YANG ident= ifier
>=C2=A0 =C2=A0strings to numeric identifiers for payload size reduction.= =C2=A0 CoMI
>=C2=A0 =C2=A0extends the set of YANG based protocols, NETCONF and RESTC= ONF, with
>=C2=A0 =C2=A0the capability to manage constrained devices and networks.=

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

--001a113cc7fa2725a2054662c5a6-- From nobody Wed Jan 18 11:52:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF15129510 for ; Wed, 18 Jan 2017 11:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etd4mRcX2hX2 for ; Wed, 18 Jan 2017 11:51:57 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BD51294FF for ; Wed, 18 Jan 2017 11:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lKG3/iBNv57q4Ke1crBz9Owq7puP/RzbgfGgJUUsjjk=; b=TdY2kT/3Wk2Buls6HvDt/tbIS1zX4xOOuo9db1v58TwvP38TW97Gco/tkHAJff3xsP0nVE/DPcM1OtqW/gCrxycSVYqDlaw4ibAZ0bP8H5lthnhxWAt20rF6RV83bIhsKJCYTVKsaaVFzX/dcfitiZubxKHG/SrTMD3PFLDw9l8= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2306.namprd06.prod.outlook.com (10.173.19.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 18 Jan 2017 19:51:55 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0845.013; Wed, 18 Jan 2017 19:51:55 +0000 From: Michel Veillette To: Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgQ29uZmlybWF0aW9uIGNhbGwgZm9yIFdHIGFkb3B0aW9u?= =?utf-8?Q?_of_draft-vanderstok-core-comi-11.txt?= Thread-Index: AQHScYF5BJiGrJQ4GUG4Ro8xnyfMTaE+oKnQ Date: Wed, 18 Jan 2017 19:51:55 +0000 Message-ID: References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: c85c628b-0424-4bd4-578c-08d43fdb74b1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2306; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2306; 7:PQiqeIxyChVy4RB48iAwYKpX9RB5voXkmMhLMpjJWrNZskb5U1VOCgKxnjGG8R/2U9vS5j7oczaRRglI0w7bHU+Du43TZvA3EftrCcdXjCi5KPGWhAfEXo8fevkXDN1+uH93sATnBPxcua9nSdMERtJ43Krr9Oz8GjieECQ3fDRLz2cWX057d79MnXVLlHHgcE3fsaM7AusRDfZNZ6k6p7kakKGjfep8AMKEgDaJyYmPXzXG3yTAmLmM7Jn9yRFb44G9Mo8xXEUT5z9ZyUFEnLFRI9op3qaw/lz3Nby0aXtAb8+dYcwXuMQ01XidVoQaudOp1ThIPJRPP33Qtm+UroVYLVly80//9lAjHtjqWjEuF8AHs77kVyRpmz3iZapuACe1taEuHbL/ZOswCAAAkZg+djYpa00RiAVyRfpixwr2CwbwZfjEncvEq4so0tvk9uyYDXMHUFbTQzMRVSjjRQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN6PR06MB2306; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2306; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(199003)(189002)(377454003)(24454002)(53754006)(377424004)(13464003)(102836003)(3846002)(230783001)(6116002)(81156014)(81166006)(86362001)(53936002)(2900100001)(8936002)(92566002)(97736004)(189998001)(106356001)(106116001)(105586002)(229383001)(68736007)(122556002)(3660700001)(33656002)(66066001)(2950100002)(6916009)(2906002)(76176999)(99286003)(54356999)(25786008)(5660300001)(6306002)(9686003)(4326007)(110136003)(50986999)(7696004)(55016002)(77096006)(6436002)(38730400001)(229853002)(101416001)(3280700002)(305945005)(6506006)(74316002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2306; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 19:51:55.2928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2306 Archived-At: Cc: Core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_WG_adoption_o?= =?utf-8?q?f_draft-vanderstok-core-comi-11=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:52:00 -0000 SGkgQ2Fyc3Rlbg0KDQpJJ20gYWxzbyBzdXBwb3J0aW5nIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBv ZiBkcmFmdC12YW5kZXJzdG9rLWNvcmUtY29taS0xMS4NCg0KU29tZSBtaW5vciBkZXRhaWxzIHN0 aWxsIG5lZWQgdG8gYmUgcmVzb2x2ZWQsIGJ1dCBtb3N0IG9mIHRoZSB3b3JrIHJlcXVpcmVkIHRv IG1lcmdlIHRoZSBvcmlnaW5hbCBDb01JIHdpdGggdGhlIGFsdGVybmF0ZSBhcHByb2FjaCBwcm9w b3NlZCBieSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVpbGxldHRlLWNvcmUt Y29vbC0wMiBoYXZlIGJlZW4gcmVzb2x2ZWQuIFRoZSBlbmQgcHJvZHVjdCBjb21iaW5lcyB0aGUg ZGF0YSByZXNvdXJjZSBhY2Nlc3MgbGV2ZWwgb2YgQ29NSSBhbmQgdGhlIGRhdGFzdG9yZSBhY2Nl c3MgbGV2ZWwgYXMgcHJvcG9zZWQgYnkgQ29PTC4gQWxsIHRoaXMgYmFzZWQgb24gYSBjb21tb24g bmFtaW5nIG1vZGVsIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LXNpZC0wMCkgYW5kIGVuY29kaW5nIG1vZGVsIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci0wMykuIA0KDQpUaGUgYWRvcHRpb24gb2YgQ29NSSB3 aWxsIGVuYWJsZSBhIGNoYW5nZSBvZiBmb2N1cyB0b3dhcmQgdGhlIGRldmVsb3BtZW50IG9mIFlB TkcgbW9kdWxlcyB0byBiZSB1c2VkIGJ5IHRoaXMgcHJvdG9jb2wgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtdmVpbGxldHRlLWNvcmUtY29vbC1saWJyYXJ5LywgbG9nZ2Vy IGFjY2VzcyBhbmQgY29udHJvbCwgT1RBIHVwZ3JhZGUsIGRhdGFzdG9yZSBtYW5hZ2VtZW50LCAu Li4NCg0KUmVnYXJkcywNCk1pY2hlbCBWZWlsbGV0dGUNCihTeXN0ZW0gYXJjaGl0ZWN0LCBUcmls bGlhbnQgTmV0d29yaykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUg W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1h bm4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxNyA2OjUzIEFNDQpDYzogQ29yZSA8 Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtjb3JlXSDwn5SUIENvbmZpcm1hdGlvbiBjYWxsIGZv ciBXRyBhZG9wdGlvbiBvZiBkcmFmdC12YW5kZXJzdG9rLWNvcmUtY29taS0xMS50eHQNCg0KDQo+ IE9uIDE4IEphbiAyMDE3LCBhdCAxMjo0NiwgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4 czRhbGwubmw+IHdyb3RlOg0KPiANCj4gSGkgYWxsLA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXZhbmRlcnN0b2stY29yZS1jb21pLTExLnR4dCBoYXMgYmVlbiANCj4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBQZXRlciB2YW4gZGVyIFN0b2sgYW5kIHBvc3RlZCB0byB0aGUg SUVURiANCj4gcmVwb3NpdG9yeS4NCj4gDQo+IEBjaGFpcnMsIHRoaXMgaXMgdGhlIHZlcnNpb24g dG8gY29uZmlybSB0aGUgYWRvcHRpb24gb3ZlciB0aGUgbWFpbGluZyBsaXN0Lg0KDQpJbmRlZWQu DQoNCkluIFNlb3VsLCB3ZSBoYWQgaW4tcm9vbSBjb25zZW5zdXMgdG8gYWRvcHQgdGhpcyBkcmFm dCBhcyBhIFdHIGRvY3VtZW50LCBmaWxsaW5nIGluIHRoZSByZW1haW5pbmcgZ2FwIG9mIHRoZSBD T01JL0NPT0wgc2VyaWVzIG9mIGRvY3VtZW50cy4gIFdlIHNhaWQgd2UgbmVlZGVkIHRvIGNvbmZp cm0gdGhhdCBjb25zZW5zdXMgb24gdGhlIG1haWxpbmcgbGlzdCwgYnV0IGRpZG7igJl0IGRvIHRo YXQgaW1tZWRpYXRlbHksIGFuZCB0aGVuIHRoZXJlIHdhcyBhIG5ldyB2ZXJzaW9uIGltcGVuZGlu Zy4NCg0KVGhhdCBuZXcgdmVyc2lvbiBpcyBub3cgYXZhaWxhYmxlLiAgU28gaWYgeW91IGRvIG5v dCBhZ3JlZSB3aXRoIHRoZSBpbi1yb29tIGNvbnNlbnN1cyB0aGF0IHdlIGhhZCBpbiBTZW91bCB0 byBhZG9wdCB0aGlzIGFzIGEgV0cgZG9jdW1lbnQsIHBsZWFzZSBzcGVhayB1cCB1bnRpbCB0aGUg ZW5kIG9mIDIwMTctMDEtMjUuICAoSWYgeW91IHdlcmVu4oCZdCBpbiB0aGUgcm9vbSBidXQgZG8g YWdyZWUgd2l0aCBhZG9wdGluZyB0aGlzIGRvY3VtZW50LCB5b3UgY2FuIGFsc28gdGVsbCB1cy4p DQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KPiBOYW1lOgkJZHJhZnQtdmFuZGVyc3Rvay1jb3JlLWNv bWkNCj4gUmV2aXNpb246CTExDQo+IFRpdGxlOgkJQ29BUCBNYW5hZ2VtZW50IEludGVyZmFjZQ0K PiBEb2N1bWVudCBkYXRlOgkyMDE3LTAxLTE4DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+IFBhZ2VzOgkJNDYNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC12YW5kZXJzdG9rLWNvcmUtY29taS0xMS50eHQNCj4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZhbmRl cnN0b2stY29yZS1jb21pLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXZhbmRlcnN0b2stY29yZS1jb21pLTExDQo+IERpZmY6ICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdmFuZGVyc3Rvay1jb3JlLWNv bWktMTENCj4gDQo+IEFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbmV0 d29yayBtYW5hZ2VtZW50IGludGVyZmFjZSBmb3INCj4gICBjb25zdHJhaW5lZCBkZXZpY2VzIGFu ZCBuZXR3b3JrcywgY2FsbGVkIENvQVAgTWFuYWdlbWVudCBJbnRlcmZhY2UNCj4gICAoQ29NSSku ICBUaGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIGlzIHVzZWQgdG8N Cj4gICBhY2Nlc3MgZGF0YSByZXNvdXJjZXMgc3BlY2lmaWVkIGluIFlBTkcsIG9yIFNNSXYyIGNv bnZlcnRlZCB0byBZQU5HLg0KPiAgIENvTUkgdXNlcyB0aGUgWUFORyB0byBDQk9SIG1hcHBpbmcg YW5kIGNvbnZlcnRzIFlBTkcgaWRlbnRpZmllcg0KPiAgIHN0cmluZ3MgdG8gbnVtZXJpYyBpZGVu dGlmaWVycyBmb3IgcGF5bG9hZCBzaXplIHJlZHVjdGlvbi4gIENvTUkNCj4gICBleHRlbmRzIHRo ZSBzZXQgb2YgWUFORyBiYXNlZCBwcm90b2NvbHMsIE5FVENPTkYgYW5kIFJFU1RDT05GLCB3aXRo DQo+ICAgdGhlIGNhcGFiaWxpdHkgdG8gbWFuYWdlIGNvbnN0cmFpbmVkIGRldmljZXMgYW5kIG5l dHdvcmtzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Wed Jan 18 13:04:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66671293E4; Wed, 18 Jan 2017 13:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEuPhbha1sBl; Wed, 18 Jan 2017 13:04:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327AD127077; Wed, 18 Jan 2017 13:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1794; q=dns/txt; s=iport; t=1484773475; x=1485983075; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Zgt7CbbSWYwiNvpEEvj+vpBTZNBAXMGNptb5TDmrSvU=; b=PVGCzqMy9IHEbK6+jYQ4ynSIWe8LXfdLf8pBSxNvZt+qVD8zsLhQUBOU xV9Bj4r5jfPB7nVEg8ZBBXY5YaUaIamweTNgtF9qnjeakiXwxh2eBb4Ba /Ffbh690d90ye31YdjaQruXuSsjq7lYF/7UcLHmFJVoaLARbNqtmLdCy1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQD01n9Y/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9ggQkHjVKSApUsggsfDYV2AoIEPxgBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBBAEBZQcXBAIBCBEEAQEoBycLFAkIAgQBEgiIew6yPYpAAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGS4Ruii0Fj2eLWgGGXop6kHaSbgEfOIFEFTqGM3O?= =?us-ascii?q?HdAGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,250,1477958400"; d="scan'208";a="194888106" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 21:04:34 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0IL4YdW025806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Jan 2017 21:04:34 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jan 2017 15:04:33 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Wed, 18 Jan 2017 15:04:33 -0600 From: "Panos Kampanakis (pkampana)" To: =?iso-8859-1?Q?Dan_Garc=EDa_Carrillo?= , "core@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] App-layer security for CoAP using (D)TLS record layer Thread-Index: AQHScExKzJMWx75El0epERyGvy0pMqE+ujrA Date: Wed, 18 Jan 2017 21:04:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.102.61.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] [Ace] App-layer security for CoAP using (D)TLS record layer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:04:37 -0000 Hi Dan, So if I understand this correctly, the intention of this draft is to descri= be how COAP header fields, options and data can be protected with DTLS (hen= ce DTLS record) regardless of the key exchange mechanism. Is it intended as= an alternative to OSCOAP/EDHOC? Thanks, Panos -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Dan Garc=EDa Carrillo Sent: Monday, January 16, 2017 6:00 PM To: core@ietf.org; ace@ietf.org Cc: Dan Garc=EDa Carrillo Subject: [Ace] App-layer security for CoAP using (D)TLS record layer Hello all:=20 We submitted some time ago an I-D proposing the use of an active (D)TLS Rec= ord (e.g. running DTLS over CoAP or presenting a token with crypto materia= l that is used to create the required keys for the DTLS record) to provide = application level security for CoAP.=20 https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-reco= rd-00 The idea is to use an active (D)TLS record to protect part of the CoAP mess= age following the rules established for OSCOAP: - The content to protect of a CoAP message (code, version, options to prot= ect and payload if any) is fed to the (D)TLS record.=20 - The output is the CoAP content to protect with a (D)TLS record header pr= epended. - That would be set into the payload of a modified version of the original= CoAP message (before it is protected) that only contains options that do n= ot need to be protected. We think this could add to an interesting discussion to the subject of Secu= rity for CoAP at application layer.=20 Comments are welcome,=20 Best Regards. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jan 19 00:07:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4DE129488 for ; Thu, 19 Jan 2017 00:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eztbUTBU1TEv for ; Thu, 19 Jan 2017 00:07:00 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 11A0F12947B for ; Thu, 19 Jan 2017 00:06:59 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v0J86uRO059663; Thu, 19 Jan 2017 09:06:57 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 581B31D53C1; Thu, 19 Jan 2017 09:06:56 +0100 (CET) Received: from 147.83.113.31 by webmail.entel.upc.edu with HTTP; Thu, 19 Jan 2017 09:07:01 +0100 Message-ID: In-Reply-To: References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> Date: Thu, 19 Jan 2017 09:07:01 +0100 From: "Carles Gomez Montenegro" To: "Ana Minaburo" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 19 Jan 2017 09:06:57 +0100 (CET) Archived-At: Cc: Core Subject: Re: [core] =?iso-8859-1?Q?=F0=9F=94=94_Confirmation_call_for_WG_adoption_of_draft-va?=nderstok-core-comi-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 08:07:02 -0000 +1 Carles > Hello, > > I also supports this document. > > Ana > > On Wed, Jan 18, 2017 at 12:52 PM, Carsten Bormann wrote: > >> >> > On 18 Jan 2017, at 12:46, peter van der Stok >> wrote: >> > >> > Hi all, >> > >> > A new version of I-D, draft-vanderstok-core-comi-11.txt >> > has been successfully submitted by Peter van der Stok and posted to >> the >> > IETF repository. >> > >> > @chairs, this is the version to confirm the adoption over the mailing >> list. >> >> Indeed. >> >> In Seoul, we had in-room consensus to adopt this draft as a WG document, >> filling in the remaining gap of the COMI/COOL series of documents. We >> said >> we needed to confirm that consensus on the mailing list, but didn’t do >> that >> immediately, and then there was a new version impending. >> >> That new version is now available. So if you do not agree with the >> in-room consensus that we had in Seoul to adopt this as a WG document, >> please speak up until the end of 2017-01-25. (If you weren’t in the >> room >> but do agree with adopting this document, you can also tell us.) >> >> Grüße, Carsten >> >> > Name: draft-vanderstok-core-comi >> > Revision: 11 >> > Title: CoAP Management Interface >> > Document date: 2017-01-18 >> > Group: Individual Submission >> > Pages: 46 >> > URL: https://www.ietf.org/internet- >> drafts/draft-vanderstok-core-comi-11.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-vanderstok-core- >> comi/ >> > Htmlized: https://tools.ietf.org/html/ >> draft-vanderstok-core-comi-11 >> > Diff: >> https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core- >> comi-11 >> > >> > Abstract: >> > This document describes a network management interface for >> > constrained devices and networks, called CoAP Management Interface >> > (CoMI). The Constrained Application Protocol (CoAP) is used to >> > access data resources specified in YANG, or SMIv2 converted to YANG. >> > CoMI uses the YANG to CBOR mapping and converts YANG identifier >> > strings to numeric identifiers for payload size reduction. CoMI >> > extends the set of YANG based protocols, NETCONF and RESTCONF, with >> > the capability to manage constrained devices and networks. >> >> _______________________________________________ >> 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 Thu Jan 19 10:15:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE861294A2; Thu, 19 Jan 2017 10:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 pEKaJUqMzBSf; Thu, 19 Jan 2017 10:15:30 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE46129499; Thu, 19 Jan 2017 10:15:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 62D668003; Thu, 19 Jan 2017 19:15:29 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pGKLkCVtiIUA; Thu, 19 Jan 2017 19:15:29 +0100 (CET) Received: from [192.168.0.101] (unknown [84.236.168.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon23.um.es (Postfix) with ESMTPSA id DE7628000; Thu, 19 Jan 2017 19:15:26 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?iso-8859-1?Q?Dan_Garc=EDa_Carrillo?= In-Reply-To: Date: Thu, 19 Jan 2017 19:15:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DA0C70A-59FE-4AB3-948C-EE5D91B6A170@um.es> References: To: "Panos Kampanakis (pkampana)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "core@ietf.org" , "ace@ietf.org" Subject: Re: [core] [Ace] App-layer security for CoAP using (D)TLS record layer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:15:32 -0000 Hi Panos,=20 Thank you for your question. Yes, it can be considered as an alternative.=20 The starting point of our work was to leverage the existing source code = for DTLS in the nodes.=20 Thus, we would save additional resources (e.g. code wise) since we would = re-use a DTLS implementation to achieve (object) security at CoAP level = (application layer)=20 Best Regards,=20 Dan. > El 18 ene 2017, a las 22:04, Panos Kampanakis (pkampana) = escribi=F3: >=20 > Hi Dan, > So if I understand this correctly, the intention of this draft is to = describe how COAP header fields, options and data can be protected with = DTLS (hence DTLS record) regardless of the key exchange mechanism. Is it = intended as an alternative to OSCOAP/EDHOC? > Thanks, > Panos >=20 >=20 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Dan Garc=EDa = Carrillo > Sent: Monday, January 16, 2017 6:00 PM > To: core@ietf.org; ace@ietf.org > Cc: Dan Garc=EDa Carrillo > Subject: [Ace] App-layer security for CoAP using (D)TLS record layer >=20 > Hello all:=20 >=20 > We submitted some time ago an I-D proposing the use of an active = (D)TLS Record (e.g. running DTLS over CoAP or presenting a token with = crypto material that is used to create the required keys for the DTLS = record) to provide application level security for CoAP.=20 >=20 > = https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-reco= rd-00 >=20 >=20 > The idea is to use an active (D)TLS record to protect part of the CoAP = message following the rules established for OSCOAP: > - The content to protect of a CoAP message (code, version, options to = protect and payload if any) is fed to the (D)TLS record.=20 > - The output is the CoAP content to protect with a (D)TLS record = header prepended. > - That would be set into the payload of a modified version of the = original CoAP message (before it is protected) that only contains = options that do not need to be protected. >=20 > We think this could add to an interesting discussion to the subject of = Security for CoAP at application layer.=20 >=20 > Comments are welcome,=20 > Best Regards. > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jan 23 00:16:43 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA212949D for ; Mon, 23 Jan 2017 00:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, 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 fcHrfTD-x08Z for ; Mon, 23 Jan 2017 00:16:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CCC12949A for ; Mon, 23 Jan 2017 00:16:39 -0800 (PST) Received: from [192.168.91.170] ([195.149.223.63]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Me8ws-1ctGnL0UOM-00Pwoe for ; Mon, 23 Jan 2017 09:16:37 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 23 Jan 2017 09:16:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BAq2PPxuQoXaDtdHjiDgO8VblVJSphJPN" X-Provags-ID: V03:K0:H1+3RjgBuCpM3q26YeMCb/mwcQDyOH+jgrOVqha/Iz8YpK5ug7J WhqZPe1aZKK4Jzk3sY2+iYKlIP0dgroxpnlgeVLSwBnD+/edgfS9W6xtUK0RdwyuMQA7AO6 amOo9mlyrGSehGZP34huadc5VgpeZKJCoCnJx6KhWkfBU8X3o6na0211EnLWkfXWwhVWuHA eUYy5Zb2u3UWQwmHOVLfA== X-UI-Out-Filterresults: notjunk:1;V01:K0:oJc3lqTB6u0=:B9mqc87WxxbABGv6JndsYr deREE7de9q8eiFONA4MuJA1Bj7Lx27Cp86tcY3Aadsj1x+TVWuzIofzfLUrMMLmM8v+gCGD5k p5Z+boc0DJ6vMrxVmsOAmKxFQdo0MbBjwg4n5lRtbrsv16ELymBJL/CHoBYGkZdqt5R1qzqYs MiEXT8aHXRtI5krB9DGPDxDmgFM7YSIXIs+LfD6oi2JvKoytYgORfMm+kcanLx7dbr0vog4fF gjSkVMNdcN6FlO6PM4tqVM7xeZqMcj3uoEVFQXsI+j5SRNB9fUnINX9eWAnRwR0pezx6FR40e 0yqRi1XQ9gimx9SwPPkg6q+7TOVzlyZnHlFAJCQKu1+96jej3LibIRQrj1gmPKEqnPBO4R/rm 3u19cKbQp2FZ/0p63v9XApmShZp76nen/Gwc8h77JpCibYlYGkNpFUBILzndwrUY17mhlefPR jfrmGMhoU1jvm3qqFJjVUKlbwwNpJnXC3v8gOUhVCI8WNJYkr1AjH2TiYh9IIM1rhuht3AuuL 7zhWUK4rioIUwTYI77To1CFjmvherBKoK/GHLRgbClD9iLFDCwp1DlSbixJXzx9pxUmi3UcU3 4zehs2HWdku/5FtnbDDNQQbHUtFdb4MsjHaejv1UIyBl+mOaGjPF0JXSrXjKzOJZsn1ktuoiL WrC3kuMQI8ZY7Hmm+G4ANsLFLJm3KyhIMYmdQDbsAwHulO0Io8QCAvPA9JczO1DqmPMP1ztzg cCj2o7v7nZzyRl4g9g4tWdJMHQQAeJSMK5MXu8NCkunOJjQKyf54gzd6skY= Archived-At: Subject: [core] draft-becker-core-coap-sms-gprs-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:16:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BAq2PPxuQoXaDtdHjiDgO8VblVJSphJPN Content-Type: multipart/mixed; boundary="1xMIwQSATtuQT6HqqKJd7WqGJeuxpVJ8R"; protected-headers="v1" From: Hannes Tschofenig To: "core@ietf.org WG" Message-ID: Subject: draft-becker-core-coap-sms-gprs-05 --1xMIwQSATtuQT6HqqKJd7WqGJeuxpVJ8R Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, when I recently stumbled over this document I was unsure about the status and reached out to the authors. Having worked in the OMA DM group and witnessed some fuzziness around the description of how CoAP is carried over SMS I have been wondering whether there is interest to finalize this work (which has also been mentioned in https://tools.ietf.org/html/draft-silverajan-core-coap-alternative-transp= orts-09 at a later stage). As it can be seen from the alternative transport document, the WebSocket parts have now been covered in the CoAP over TCP/TLS document. A feature that has also been raised in the context of SMS is the ability to wake-up the device using an SMS so that it starts communication over I= P. Is there any interest to finalize this work? Ciao Hannes --1xMIwQSATtuQT6HqqKJd7WqGJeuxpVJ8R-- --BAq2PPxuQoXaDtdHjiDgO8VblVJSphJPN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYhbvkAAoJEGhJURNOOiAtY88H/i259qkA6E8oY16uN0L3NT18 6aedcZkK7UKLacfqHqxcfxR7AHTm8PMjU4ge4w0SVqCbRkN1uOCMDI9k4kMrWRU9 UaP1UQJeH2IpuecjArgVOe1Jf4aKKW/q1J+pelf8LTYgG6XfewwbYPmidfnAHsY6 fQQ5pfLOflclh+iHZ06GjL3O2wgBfak9CXitDUsDpXHUl8jIv4RO9bDyCUophMOj mqOWERfr0WsWfHYdAiZDJyi73RiANadPJLp1HdNxhjo6JXtVN1J4iARSC/tkt5Wd 8ST+ALb/Y9DdLL1n2Q4G4CLea47EpSwowoqHqm8PVWk/3QtcCiz2GtaHbVYmdkE= =dZpH -----END PGP SIGNATURE----- --BAq2PPxuQoXaDtdHjiDgO8VblVJSphJPN-- From nobody Mon Jan 23 05:31:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927CC1295EB; Mon, 23 Jan 2017 05:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6bbS87n2LbU; Mon, 23 Jan 2017 05:30:59 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813E31295F9; Mon, 23 Jan 2017 05:30:58 -0800 (PST) X-AuditID: c1b4fb25-4ccfd980000066fb-99-58860590f2a2 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 5F.A0.26363.09506885; Mon, 23 Jan 2017 14:30:56 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Mon, 23 Jan 2017 14:26:41 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" , Jim Schaad , Francesca Palombini Thread-Topic: OSCOAP's inner-blockwise Thread-Index: AQHScL8hm4bYm3XXc0WT0oYraDzgmqFGFyoA Date: Mon, 23 Jan 2017 13:26:40 +0000 Message-ID: References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> In-Reply-To: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <718AE0E5F47C2C4C9B57BCDA34CCF01F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7lu4E1rYIg2t9WhbLLzxnsdj3dj2z xbR/Z1gsVk//zubA4rFxznQ2j6377zJ5LFnykymAOYrLJiU1J7MstUjfLoEr4+k9o4JLyhVb Vh9lbGC8o9TFyMkhIWAisehSK3sXIxeHkMA6RokNLQfZIJwljBLb72xnA6liE3CReNDwiAkk ISKwlEni0r12dpCEsICqxLIfexhBbBEBNYnLXy8zQ9hGEqufzAOLswDVvO94BVbPK2AhsXDt ExYQWwho6IqTq4DqOTg4BVwlnizjBAkzCohJfD+1hgnEZhYQl7j1ZD4TxKUCEkv2nGeGsEUl Xj7+xwpiiwroSSx/vgYqriTxY8MlFpCRzAKaEut36UOMsZbYc/wFK4StKDGl+yHUNYISJ2c+ YZnAKDYLybZZCN2zkHTPQtI9C0n3AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBEXdw y2/VHYyX3zgeYhTgYFTi4TVgbI0QYk0sK67MPcQowcGsJMKrxNgWIcSbklhZlVqUH19UmpNa fIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVANjWtec8zmPcn5/zfXJzwqQWtnNGR/R Xf790Wwl7c0N+0/NEVTO5jf9Vl4ZvfB1d8qCl6fVHiVcsIlQt+40SJLLeGB0idP1x2Z2vqTt bJu7LrtPbZq7K/MIH9N6I96cR6X606avSpbJuvKG/ewhvv2K39uPhHlylcVH9jyyZ5OMDf+a Z7+yZ70SS3FGoqEWc1FxIgBvs2zttAIAAA== Archived-At: Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 13:31:00 -0000 aGkgQ2hyaXN0aWFuLA0KDQpUaGFua3MgZm9yIGJyaW5naW5nIHRoaXMgdG8gdGhlIGxpc3QuDQoN CldlIGhhdmUgYmVlbiByZS1pdGVyYXRpbmcgdGhlIGFyZ3VtZW50YXRpb24gZm9yIGhhdmluZyBh IGJpbmRpbmcgYmV0d2Vlbg0KdGhlIGJsb2Nrcy4gIEl0IHdhcyBpbnRyb2R1Y2VkIHRvIHByb3Rl Y3QgYWdhaW5zdCBpbnRlcmNoYW5nZSBvZiBibG9ja3MNCmZyb20gZGlmZmVyZW50IHJlcHJlc2Vu dGF0aW9ucyBvZiB0aGUgc2FtZSByZXNvdXJjZSBleGNoYW5nZWQgYmV0d2VlbiB0aGUNCnNhbWUg Y2xpZW50IGFuZCBzZXJ2ZXIuIE9uIHNlY29uZCB0aG91Z2h0IHN1Y2ggYSBwcm90ZWN0aW9uIGEp IHNob3VsZCBub3QNCmJlIG1hbmRhdG9yeSB0byBhcyB0aGlzIGlzIG5vdCBwcm9oaWJpdGVkIFJG Qzc5NTksIGFuZCBiKSBjYW4gaW5zdGVhZCBiZQ0KYWNoaWV2ZWQgdXNpbmcgRVRhZywgYXMgeW91 IHByb3Bvc2UsIHdoaWNoIGlzIHByb3RlY3RlZCBieSBPU0NPQVAgYW5kIHRodXMNCmNhbiBiZSB1 c2VkIHRvIHZlcmlmeSB0aGF0IGJsb2NrcyBiZWxvbmcgdG8gdGhlIHNhbWUgcmVwcmVzZW50YXRp b24uDQoNCldpdGggdGhpcyBpbiBtaW5kLCBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIGJpbmQg dGhlIGludGVncml0eSBvZiB0aGUNCmRpZmZlcmVudCBibG9ja3MgdG8gZWFjaCBvdGhlciBhbmQg d2Ugc2hvdWxkIHJlbW92ZSB0aGUgdGFnLXByZXZpb3VzLWJsb2NrDQpmcm9tIHRoZSBleHRlcm5h bF9hYWQuDQoNClVubGVzcyB0aGVyZSBpcyBhbiBvYmplY3Rpb24sIGl0IHdpbGwgYmUgcmVtb3Zl ZCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTctMDEtMTcgMTM6 NDIsICJDaHJpc3RpYW4gQW1zw7xzcyIgPGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0Pg0K d3JvdGU6DQoNCj5IZWxsbyBPU0NPQVAgYXV0aG9ycyBhbmQgaW1wbGVtZW50b3JzLA0KPg0KPkkn bSB0YWtpbmcgYSBkaXNjdXNzaW9uIGZyb20gW29zY29hcDojNDldIHRvIHRoZSBsaXN0IGJlY2F1 c2UgaXQgZXhjZWVkcw0KPnRoZSB0b3BpYyBvZiB0aGUgaXNzdWUsIGFuZCBtYXliZSBjb3VsZCB1 c2UgZmVlZGJhY2sgZnJvbSBwb2VwbGUgbm90DQo+ZGlyZWN0bHkgaW52b2x2ZWQgd2l0aCB0aGUg ZGV0YWlsIG9mIHRoZSBpc3N1ZS4NCj4NCj4NCj5JIHRoaW5rIHRoYXQgdGhlIHByb3RlY3Rpb24g Y3VycmVudGx5IGRyYWZ0ZWQgZm9yIHRoZSBpbm5lciBibG9ja3dpc2UNCj5vcHRpb24gKHRoYXQg aXMsIHVzaW5nIHRoZSBNQUMgb2YgdGhlIHByZXZpb3VzIGV4Y2hhbmdlZCBibG9jayBhcyBwYXJ0 DQo+b2YgdGhlIEFBRCBpbiBzZWN1cmluZyB0aGUgbmV4dCBibG9jaywgdGh1cyBjcmVhdGluZyBh IGNoYWluIG9mDQo+YXV0aGVudGljYXRlZCBtZXNzYWdlcyksIGlzIHJhdGhlciBpbnRydXNpdmU6 IEl0IHJlcXVpcmVzIHJldGFpbmluZw0KPmFkZGl0aW9uYWwgc3RhdGUsIGFuZCByZXF1aXJlcyB0 aGUgbWVzc2FnZSBwcm90ZWN0aW9uIHBhcnQgdG8gaW50ZXJhY3QNCj53aXRoIHRoZSBibG9ja3dp c2UgdHJhbnNmZXIgcGFydCkuIFdoYXQgSSBhbSBhZHZvY2F0aW5nIGlzIGEgc2xpbW1lcg0KPmNv dXJzZSBvZiBhY3Rpb24sIGxpa2UgZGV0ZXJtaW5pbmcgcmVzb3VyY2UgY29uc2lzdGVuY3kgdXNp bmcgYW4gRVRhZywNCj50byBhY2hpZXZlIHRoZSBzYW1lIHByb3RlY3Rpb24uIChJZiBhbiBFVGFn IGlzIGluc3VmZmljaWVudCwgbWF5YmUgYQ0KPlNlY3VyZS1FVGFnIHRoYXQncyByZXF1aXJlZCB0 byBjaGFuZ2UgdW5kZXIgdGhlc2Ugb3IgdGhvc2UgY29uZGl0aW9ucw0KPmlzLikNCj4NCj5JIHN1 Z2dlc3QgdGhpbmtpbmcgYWJvdXQgdGhlIGJsb2NrMiBjYXNlIGZpcnN0LCBhcyBpZiBpdCB0dXJu cyBvdXQgdGhhdA0KPnRhZyBjaGFpbmluZyBpcyBhYnNvbHV0ZWx5IHJlcXVpcmVkIHRoZXJlLCB0 aGluZ3Mgd29uJ3QgYmUgYW55IGVhc2llcg0KPmZvciB0aGUgYmxvY2sxIGNhc2UuDQo+DQo+DQo+ SmltIFNjaGFhZCB3cm90ZSBpbiBbb3Njb2FwOiM0OV06DQo+PiB0aGUgcmVhc29uIGZvciB1c2lu ZyB0aGUgY3J5cHRvIHRhZyBpcyB0byBoYXZlIHRoZSBhYmlsaXR5IHRvDQo+PiBlc3RhYmxpc2gg dGhhdCB0aGUgZW50aXJlIG1lc3NhZ2UgaGFzIGJlZW4gaW50ZWdyaXR5IHByb3RlY3RlZCByYXRo ZXINCj4+IHRoYW4ganVzdCB0aGUgaW5kZXBlbmRlbnQgcGllY2VzDQo+DQo+QnV0IGRvZXMgY2hh aW5pbmcgdGhlIHRhZ3MgYWN0dWFsbHkgYWNoaWV2ZSB0aGF0PyBBbGwgdGhleSBlc3RhYmxpc2gg aXMNCj50aGF0IGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgYWdyZWUgdGhhdCB0aGVyZSB3YXMgYSBj b250aW51b3VzIGV4Y2hhbmdlDQo+b2YgbWVzc2FnZXMgdGhhdCBsZWQgdG8gdGhlIGxhc3QgYmxv Y2sgdHJhbnNmZXJyZWQuIEEgY2xpZW50IGNvdWxkIGhhdmUNCj5za2lwcGVkIGEgYmxvY2sgZHVy aW5nIHRoZSB0cmFuc2ZlciAoZWcuIGJlY2F1c2UgaXQgYWxyZWFkeSBoYXMgdGhlDQo+YmxvY2sp LCBmaW5pc2ggYSBzZWN1cmVseSBjaGFpbmVkIHRyYW5zZmVyLCBhbmQgdGhlbiB3b3VsZCB0aGVu IHN0aWxsDQo+d29yayB3aXRoIGEgcGFydGlhbGx5IHNlY3VyZWQgcmVzb3VyY2UuWzFdDQo+DQo+ V2Ugd291bGQgbmVlZCB0byByZXF1aXJlIGJsb2NrIHRyYW5zZmVycyB0byBiZSBzdHJpY3RseSBp dGVyYXRpbmcgLyBub3QNCj51c2UgY2FjaGVkIEVUYWdzLCBidXQgSU1PIHRoYXQgd291bGQgbG9z ZSBzbyBtdWNoIG9mIGJsb2Nrd2lzZSB0aGF0IGl0DQo+ZmVlbHMgbW9yZSBsaWtlIGl0cyBvd24g ZnJhZ21lbnRhdGlvbiBzY2hlbWUuDQo+DQo+DQo+QmVzdCByZWdhcmRzDQo+Q2hyaXN0aWFuDQo+ DQo+DQo+W29zY29hcDojNDldOiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXAvaXNz dWVzLzQ5DQo+DQo+WzFdOiBGb2xsb3dpbmcgdGhlIGxldHRlciBvZiB0aGUgZHJhZnQsIHRoZSBy ZXNvdXJjZSBjb3VsZCBldmVuIGNoYW5nZQ0KPmR1cmluZyB0aGUgdHJhbnNmZXIgKHByb3ZpZGVk IG5vIEVUYWdzIGFyZSB1c2VkKSwgYW5kIHRoZSBzZXJ2ZXIgY291bGQNCj5zaWduIG9mZiB0aGUg c3RyZWFtLiBUaGF0IGNhbiBiZSBmaXhlZCBlYXNpbHkgaW4gdGhlIGRyYWZ0LCBidXQgcmVxdWly ZXMNCj5pbXBsZW1lbnRhdGlvbnMgdG8gdHJhbnNmZXIgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBi ZXR3ZWVuIGNvbXBvbmVudHMuDQo+DQo+LS0gDQo+VG8gdXNlIHJhdyBwb3dlciBpcyB0byBtYWtl IHlvdXJzZWxmIGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVhdGVyDQo+cG93ZXJzLg0KPiAg LS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0KDQo= From nobody Mon Jan 23 06:30:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD66F12960A for ; Mon, 23 Jan 2017 06:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEIW-9ut1066 for ; Mon, 23 Jan 2017 06:30:50 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA9129605 for ; Mon, 23 Jan 2017 06:30:50 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id v186so94393903lfa.1 for ; Mon, 23 Jan 2017 06:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=to:from:subject:message-id:date:user-agent:mime-version; bh=cc/QTG4SYId501TS2zhAZTXygNnufpRr7MoB7O+VoHU=; b=OZZfpYT7O3a+b4kzm76qJl1HAI7xAEkKXjdr8SeGhzSOKvHFM2f6FfbcAecDzTqDCE XwRNayl0fuCkFUJgGXr3mTx2gZmH8xeghZtRhF8hWPh6LX15FvjLf/Bfx+otdPm3fIIi 5D/uf+5zL29KN4bLkBIjjTJMJHUoTv1JiIbJXx+4gNPlbsykrhoaWSpx5y4tu5UgiACD gnZY9wfJrqMQ56mN0oRqbR4ZkIaEkXZZyzRER7KU49eBWrPVP2bN6lOF51FgeBIn/yEI xdDO7Eo/yc+Te9oF1x6C8hs8PdeWoS70v/pHs5z0KJmyKGlPDG5fjDd2TEAp/NNJufJb 6yhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=cc/QTG4SYId501TS2zhAZTXygNnufpRr7MoB7O+VoHU=; b=nJP37U3ApEnBDA+D5k8RevBx9R7TZ8nFaNZI5IscDnLW4IbarH2+weSbRcLmAcApiz gl1HGvectDNw+NH7vbzh33fc6BbBeQOzuh9GO+aB077I7+fip+2/FLVMdMebKJdLe41d uabb3hVQ24/wQqA7vTfNmkC7whDtgp6m8gfPxnmotlJ9SoLfyApahp1jG+nDHnZWkFaP kgyTrqnOzHSercD2SutGO3tLz+yvw9i5mXmiNKHNhK3RcTVchSUjF/HE+wMZjNyzthsm VV9s+qq94ce4pwUr0bKud95n14aXXUD5AE1+ekU0c8tyskZ/VLasWPkO+6o1i5+w83qR XNeQ== X-Gm-Message-State: AIkVDXIwzqaqOvq9m+gKIhZaJi/Vi71d7ytNdX1/8d0kQ6TCsiAhWaGWFwL0gg0beTRTBm9A X-Received: by 10.46.5.130 with SMTP id 124mr12483608ljf.17.1485181848256; Mon, 23 Jan 2017 06:30:48 -0800 (PST) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id c1sm2266044lfg.9.2017.01.23.06.30.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 06:30:46 -0800 (PST) To: core From: Ludwig Seitz Message-ID: <73ee4425-f14f-3348-d305-4c6b8344c45d@sics.se> Date: Mon, 23 Jan 2017 15:30:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000200020001040701060603" Archived-At: Subject: [core] Question about calculation of cache key in RFC 7252 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 14:30:52 -0000 This is a cryptographically signed message in MIME format. --------------ms000200020001040701060603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, in a recent discussion here: https://github.com/core-wg/oscoap/issues/51 we have come to the conclusion that RFC 7252 is not totally clear about = whether a request payload is supposed be part of a cache-key, and under=20 which conditions a proxy can cache responses to requests other than GET. Carsten even suggested that this might warrant an errata to RFC 7252. It would be helpful if CoRE could provide some clarifications on that top= ic. Regards, Ludwig --=20 Ludwig Seitz, PhD RISE ICT/SICS Ideon Science Park, Building Beta 2 Scheelev=C3=A4gen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 --------------ms000200020001040701060603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNzAxMjMxNDMwNDZaMC8GCSqGSIb3DQEJBDEiBCDQd73B5aO/ VoVvKwVymprtTTjot+UDMxFSoScyNIWHTjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQBLfRNt5936eHC00G0wS1Zq 9OWXsbSnSrzNhApwvNHix9NP2EGGtGDifbEBYorYrn4YJw4KNfOPzr+ttLgNCfQ3OchUAt7C Ug8N+OTfKcvGYPbYvDMemLD9LAv5VXEUO0Ya2WQ0cv841xxAuiWeSD+DO52Zy+TdwPMzrsaF zGP9jJKmAEW4coGatPINgr941ETwciC1grkUZIJu2SjJNPplZY7lD5AthkFTEEr30bJQJO+v +RAti1foPPeGFrevvFNBoAOZYZLfvfpZZIkjuezwczPYMY898yMF/suBqj7jp8z+7JvlMlDo bJ/qTp8Jdwn4YbK3apfqpOCFGXNvyNc6AAAAAAAA --------------ms000200020001040701060603-- From nobody Mon Jan 23 07:53:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0C3129637; Mon, 23 Jan 2017 07:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6AdghT7I5FF; Mon, 23 Jan 2017 07:53:35 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5590A129601; Mon, 23 Jan 2017 07:53:35 -0800 (PST) X-AuditID: c1b4fb3a-d001d98000007c71-0b-588626fdbc19 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id BA.7D.31857.DF626885; Mon, 23 Jan 2017 16:53:33 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Mon, 23 Jan 2017 16:48:47 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: chrysn Thread-Topic: [core] OSCOAP: [...], sequence numbers Thread-Index: AQHSaxCGFcqj/qEuz0qLdPYr3fiZf6E2s4KAgAXzpYCACaMUAA== Date: Mon, 23 Jan 2017 15:48:46 +0000 Message-ID: References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> <20170117133845.j5klu7t5z42tqhmt@hephaistos.amsuess.com> In-Reply-To: <20170117133845.j5klu7t5z42tqhmt@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <0E0C2D041A532B4B8BF1AC88F70D036C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvje5ftbYIg77TChabF9xms9j3dj2z xbR/Z1gcmD32Lr7G5LFkyU+mAKYoLpuU1JzMstQifbsErozt77qZCiaZV5xeZ9PAeMe0i5GT Q0LAROLD0tPMXYxcHEIC6xklWj5eZIVwljBKPG35xAhSxSbgIvGg4RETiC0iICNxctc5dhCb WaBG4sSR7WC2sICxxO2/z5khakwk1m1dxQ5hO0lMOrcZKM7BwSKgKvG7H6yEV8BC4vWbx2wQ u84xSXS96AObzyngKvH+7ys2EJtRQEzi+6k1TBC7xCVuPZnPBHG1gMSSPeeZIWxRiZeP/7GC 2KICehLLn6+BiitKXJ2+nAlkL7OApsT6XfoQY6wlrpy4BHW+osSU7ofsEPcISpyc+YRlAqP4 LCTbZiF0z0LSPQtJ9ywk3QsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbdwS2/rXYw HnzueIhRgINRiYe3QKotQog1say4MvcQowQHs5IIr6QSUIg3JbGyKrUoP76oNCe1+BCjNAeL kjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGWXvPvuANDPyoejTjoVLGwTXfzz6fIXj1oNO3 Bc6rlvSw/jzOmHtMzI+1L8X6KUvUJKn3CxZMF7iuvH+SptneJmPVDbPf6ihcdJDgU/cs7V8z d7PBFvX6N0cOqP7+yrtUyT/y+Cv1jfMUl3TWzbtg9Pn0mhnrnKJjQswns6YdqS5z3X26VHrP AiWW4oxEQy3mouJEANWrRPu2AgAA Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP: [...], sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:53:37 -0000 SGkgQ2hyaXN0aWFuLA0KDQpBbm90aGVyIHRha2Ugb24gdGhlIHNlcXVlbmNlIG51bWJlcnMsIGlu bGluZS4NCg0KT24gMjAxNy0wMS0xNyAxNDozOCwgImNocnlzbiIgPGNocnlzbkBmc2ZlLm9yZz4g d3JvdGU6DQoNCj5IZWxsbyBHw7ZyYW4sDQo+DQo+T24gRnJpLCBKYW4gMTMsIDIwMTcgYXQgMDU6 NDY6MjJQTSArMDAwMCwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4gPkluIGl0cyByZWNpcGll bnQgY29udGV4dCwgaWYgdGhlIGRldmljZSBvbmx5IHN0b3JlcyBzb21ldGhpbmcgbGlrZSB0aGUN Cj4+ID5lbmQgb2YgaXRzIHJlY2VpdmUgd2luZG93IG9uIGZsYXNoLCBpdCdsbCB0YWtlIHRoZSBj b21tdW5pY2F0aW9uDQo+PnBhcnRuZXINCj4+ID51cCB0byB3aW5kb3ctc2l6ZSBmYWlsZWQgYXR0 ZW1wdHMgKHdoaWNoIGl0IG1pZ2h0IG5vdCBldmVuIGJlIGFsbG93ZWQNCj4+dG8NCj4+ID5yZXBl YXQpIHRvIGdldCBpbiB0aGUgY2xlYXIuDQo+PiANCj4+IEJ1dCB0aGUgcmVwbGF5IHdpbmRvdyBt ZWNoYW5pc20gT1NDT0FQIGhhcyBpbmhlcml0ZWQgZnJvbSBEVExTIGFuZCBFU1ANCj4+aXMNCj4+ IHNsaWRpbmcsIHNvIG1haW50YWluaW5nIHRoaXMgc3RhdGUgaW4gdGhlIGV2ZW50IG9mIGEgc2h1 dGRvd24gd291bGQNCj4+IHJlcXVpcmUgd3JpdGluZyB0aGUg4oCccmlnaHQiIGVkZ2Ugb2YgdGhl IHdpbmRvdyB0byBmbGFzaCBlYWNoIHRpbWUgYSBuZXcNCj4+IGhpZ2hlc3Qgc2VxdWVuY2UgbnVt YmVyIGhhcyBiZWVuIHJlY2VpdmVkLiBJIGd1ZXNzIHRoaXMgaXMgbm90DQo+PmRlc2lyYWJsZT8N Cj4NCj5NeSBpbXByZXNzaW9uIHdhcyB0aGF0IHRoZSByZXF1aXJlbWVudHMgb2YgT1NDT0FQIGFy ZSBvbmx5IHRoYXQNCj5kdXBsaWNhdGUgc2VxdWVuY2UgbnVtYmVycyBtdXN0IG5vdCBiZSBhY2Nl cHRlZCwgYW5kIHRoYXQgYWxsIG51bWJlcnMNCj5tdWNoIHNtYWxsZXIgdGhhbiB0aGUgaGlnaGVz dCBzZWVuIG9uZSBtYXkgYmUgY29uc2lkZXJlZCBzZWVuLiAoIm11Y2gNCj5zbWFsbGVyIiBoZXJl IG1lYW5zIHRoZSB3aW5kb3cgc2l6ZSwgbm90aGluZyBzaG91bGQgYnJlYWsgaWYgaXQncyBub3QN Cj5pbXBsZW1lbnRlZCBhcyBhIGJpdGZpZWxkIGJ1dCBmb3IgZXhhbXBsZSBhcyBhIHN1ZmZpY2ll bnRseSBsb25nIGxpc3Qgb2YNCj5udW1iZXJzKS4gQW55d2F5LCAuLi4NCj4NCj4+IEhvd2V2ZXIs IGluIHRoaXMgY2FzZSByZXBsYXkgcHJvdGVjdGlvbiBjYW4gYmUgYWRkcmVzc2VkIHdpdGggdGhl IFJlcGVhdA0KPj4gb3B0aW9uIGRlZmluZWQgaW4NCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3JzLTAyDQo+PiBPbiByZWJvb3Qs IGEgc2VydmVyIG11c3Qgbm90IGFjY2VwdCB0aGUgZmlyc3QgbWVzc2FnZSByZWNlaXZlZCBpbiBh DQo+PnN0b3JlZA0KPj4gc2VjdXJpdHkgY29udGV4dCwgYnV0IHJlc3BvbmQgd2l0aCBhIFJlcGVh dCBvcHRpb24gYXNraW5nIHRoZSBjbGllbnQgaWYNCj4+aXQNCj4+IHJlY2VudGx5IG1hZGUgdGhl IHJlcXVlc3QsIGFuZCBpZiBzbywgdG8gcmVwZWF0IHRoZSByZXF1ZXN0IHVzaW5nIGl0cw0KPj4g Y3VycmVudCBzZXF1ZW5jZSBudW1iZXIsIGFuZCBpbmNsdWRlIHRoZSBzYW1lIFJlcGVhdCBwYXJh bWV0ZXIgZm9yDQo+PnNlcnZlcg0KPj4gdG8gdmVyaWZ5IGZyZXNobmVzcy4NCj4+IA0KPj4gKFRo ZSBjbGllbnQgcmVjZXB0aW9uIGJlaGF2aW91ciBhZnRlciByZWJvb3QgaXMgc3RyYWlnaHRmb3J3 YXJkIHNpbmNlDQo+PnRoZQ0KPj4gY2xpZW50IHNob3VsZCBvbmx5IGFjY2VwdCByZXNwb25zZXMg Zm9yIHJlcXVlc3RzIG1hZGUgYWZ0ZXIgcmVib290LikNCj4NCj4uLi4sIEkgZG9uJ3Qgc2VlIGhv dyBlaXRoZXIgb2YgdGhpcyB3b3VsZCBoZWxwIGluIHRoZSBzaXR1YXRpb24gSQ0KPmVudmlzaW9u ZWQsIHdoaWNoIEkgbWlnaHQgbm90IGhhdmUgb3V0bGluZWQgdG8gbWF0Y2ggbXkgc3RhdGUgb2Yg bWluZCwNCj5zbyBJJ2QgdHJ5IGFnYWluOg0KPg0KPiogV2UgaGF2ZSBhIHNlcnZlciBhbmQgYSBj bGllbnQuDQo+KiBCb3RoIGNhbiBmYWNlIHVuYW5ub3VuY2VkIHNodXRkb3ducyB3aXRoIG5vIHJl c2VydmUgdG8gZG8gYQ0KPiAgbGFzdC1tb21lbnQgcGVyc2lzdGVudCB3cml0ZS4NCj4qIE5laXRo ZXIgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBkbyBwZXJzaXN0ZW50IHdyaXRlcyBhZnRlciBldmVy eQ0KPiAgbmV0d29yayB0cmFuc2FjdGlvbi4gV0xPRyBJJ2xsIGFzc3VtZSB0aGF0IHRoZXknbGwg b25seSB3cml0ZSB0byBmbGFzaA0KPiAgZXZlcnkgMTAwMCBuZXR3b3JrIHRyYW5zYWN0aW9ucy4N Cj4NCj4oSSdsbCBmb2N1cyBvbiB0aGUgc2VydmVyIHNpZGUgb2YgdGhvc2UgY29uc3RyYWludHMp Lg0KPg0KPiogVGhlIGNsaWVudCBzdGFydHMgdXNpbmcgaXRzIHNlcW5vIDEuDQoNClRoaXMgaXMg dGhlIGNsaWVudCBzZW5kZXIgc2Vxbm8uDQoNCj4gVGhlIHNlcnZlciBhY2NlcHRzIGl0LA0KDQpU aGlzIGlzIHRoZSBzZXJ2ZXIgcmVjaXBpZW50IHNlcW5vLg0KDQo+YW5kIG1hcmtzDQo+ICBhbGwg c2VxdWVuY2UgbnVtYmVycyB1cCB0byAxMDAwIGFzIHNlZW4gaW4gcGVyc2lzdGVudCBtZW1vcnks DQoNClRoZSBjbGllbnQgc2hvdWxkIG1hcmsgc2VuZGVyIHNlcW5vIHVwIHRvIDEwMDAgYXMgc2Vl biBpbiBwZXJzaXN0ZW50DQpzdG9yYWdlLiBUaGUgc2VydmVyIHJlY2lwaWVudCBzZXFubyBpcyBu b3Qgc3RvcmVkIGluIHBlcnNpc3RlbnQgbWVtb3J5Lg0KDQoNCj4gaW4gb3JkZXINCj4gIHRvIGZ1 bmN0aW9uIGZvciA5OTkgbW9yZSB0cmFuc2FjdGlvbnMgd2l0aG91dCBmbGFzaCB3cml0aW5nLiAo SXQgZG9lcw0KPiAga2VlcCBhIG1vcmUgZGV0YWlsZWQgc3RhdGUgaW4gUkFNKS4NCj4qIFRoZSBz ZXJ2ZXIgcmVzcG9uZHMgd2l0aCBpdHMgc2Vxbm8gMSwgbWFya2luZyBhbGwgc2Vxbm9zIHVwIHRv IDEwMDAgYXMNCj4gIHVzZWQuDQoNClRoaXMgaXMgdGhlIHNlcnZlciBzZW5kZXIgc2Vxbm8sIGFs bCBzZXF1ZW5jZSBudW1iZXJzIHVwIHRvIDEwMDAgaXMgbWFya2VkDQphcyBzZWVuIGluIHBlcnNp c3RlbnQgc3RvcmFnZS4gVGhlIGNsaWVudCByZWNpcGllbnQgc2Vxbm8gaXMgbm90IHN0b3JlZCBp bg0KcGVyc2lzdGVudCBtZW1vcnkuDQoNCj4NCj5UaGUgc2VydmVyIG5vdyBmYWNlcyBhIHBvd2Vy IG91dGFnZSBhcyBhYm92ZSwgYW5kIHRoZSBjbGllbnQgKG5vbmUgdGhlDQo+d2lzZXIpIGFza3Mg YWdhaW46DQo+DQo+KiBUaGUgY2xpZW50IHNlbmRzIGEgcmVxdWVzdCB3aXRoIHNlcW5vIDIuIFRo ZSBzZXJ2ZXIgZGlzY2FyZHMgaXQsDQo+ICBiZWNhdXNlIGl0IHdhcyBtYXJrZWQgYXMgInBvc3Np Ymx5IGFscmVhZHkgdXNlZCIuDQoNClNpbmNlIHRoZSBzZXJ2ZXIgaGFzIHJlYm9vdGVkLCBpdCBp cyBhd2FyZSBvZiBpdHMgaWdub3JhbmNlIG9mIHNlcXVlbmNlDQpudW1iZXJzLCBlLmcuIHVzaW5n IHRoZSBpZ25vcmFuY2Ugc3RhdGUgcGFyYW1ldGVyIHByZXZpb3VzbHkgZGVzY3JpYmVkIGluDQpz ZWN1cml0eSBjb250ZXh0cyBleGlzdGluZyBiZWZvcmUgcmVib290LiBGb3IgcmVxdWVzdHMgdG8g c2VjdXJpdHkgY29udGV4dA0Kd2hlcmUgaXQgaXMgaWdub3JhbnQsIGl0ICBpbmNsdWRlcyBpbiB0 aGUgT1NDT0FQIHJlc3BvbnNlIHRoZSBSZXBlYXQNCm9wdGlvbiB3aXRoIHJhbmRvbSB2YWx1ZS4N Cg0KDQo+KiBUaGUgc2VydmVyIHJlc3BvbmRzIHdpdGggdW5wcm90ZXRlZCA0LjAxWzFdLCBiZWNh dXNlIGl0IHN0b3BwZWQNCj4gIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QgYXMgcGVyIDYuMyBwYXIu IDEuDQo+DQo+RXZlbiBpZiB0aGUgc2VydmVyIHVzZWQgdGhlIGFjdHVhdG9ycy0wMiBSZXBlYXQg b3B0aW9uIGVhcmx5IGVub3VnaCAoaWUuDQo+YmVmb3JlIE9TQ09BUCB2YWxpZGF0aW9uIGtpY2tz IGluIGFuZCBkaXNjYXJkcyB0aGUgbWVzc2FnZSksIGl0IHdvdWxkDQo+c3RpbGwgbm90IHRlbGwg dGhlIGNsaWVudCB0aGF0IGl0IG5lZWRzIHRvIGFkdmFuY2UgaXQgc2VxdWVuY2UgbnVtYmVyLg0K PihBbmQgaWYgaXQgd2VyZSB0byB0ZWxsIHRoYXQsIGl0J2QgbmVlZCB0byBiZSB0aWdodGx5IGlu dGVybGVhdmVkIHdpdGgNCj50aGUgT1NDT0FQIHZlcmlmaWNhdGlvbiwgYmVjYXVzZSB0aGUgImFk dmFuY2UgeW91ciBzZXFubyIgaW5mb3JtYXRpb24NCj5jb3VsZCBvbmx5IGJlIGdpdmVuIHRvIGEg Y2xpZW50IHdob3NlIHJlcXVlc3QgcGFzc2VzIGFsbCBjaGVja3MgKmV4Y2VwdCoNCj50aGUgZWFy bHkgUGFydGlhbCBJViBjaGVjay4pDQoNCg0KSWYgdGhlIGNsaWVudCBjYW4gdmVyaWZ5IHRoZSBy ZXNwb25zZSwgaXQgc2VuZHMgYSBuZXcgcmVxdWVzdCB3aXRoIHRoZQ0KcmVjZWl2ZWQgdmFsdWUg b2YgdGhlIFJlcGVhdCBvcHRpb24gKGFuZCBzdGVwcGVkIHNlcXVlbmNlIG51bWJlcikuIFRoZQ0K Y2xpZW50IGRvZXMgbm90IG5lZWQgdG8gYWR2YW5jZSBpdHMgc2VxdWVuY2UgbnVtYmVyLCBzaW5j ZSB0aGVyZSB3YXMgbm8NCnNlcXVlbmNlIG51bWJlciBhZHZhbmNlZCBvbiB0aGUgc2VydmVyIHNp ZGUuDQoNCkluc3RlYWQgdGhlIHNlcnZlciBvbmx5IGFjY2VwdHMgdGhlIHJlcGVhdGVkIE9TQ09B UCByZXF1ZXN0IGlmIGl0IGNhbiBiZQ0KdmVyaWZpZWQgYW5kIHRoZSBSZXBlYXQgb3B0aW9uIGhh cyBzYW1lIHZhbHVlIGFzIHRoYXQgcHJldmlvdXNseSBzZW50IGluDQpyZXNwb25zZSB0byB0aGUg cHJldmlvdXMgcmVxdWVzdC4gSW4gdGhpcyBjYXNlIHRoZSBzZXJ2ZXIgdXBkYXRlcyB0aGUNCnNl cXVlbmNlIG51bWJlciBpbiB0aGUgcmVjaXBpZW50IGNvbnRleHQgdG8gdGhhdCBvZiB0aGUgdmVy aWZpZWQgcmVxdWVzdC4NCg0KDQpTbywgaW4gc3VtbWFyeSwgdGhlIHByb2NlZHVyZSBvZiBwZXJz aXN0ZW50bHkgc3RvcmluZyBhIG5ldyBzdGFydGluZyBwb2ludA0KZm9yIHNlcXVlbmNlIG51bWJl cnMgaW4gY2FzZSBvZiByZXN0YXJ0IGlzIG9ubHkgYXBwbGllZCB0byBzZW5kZXIgc2VxdWVuY2UN Cm51bWJlcnMsIGFuZCByZWNpcGllbnQgc2VxdWVuY2UgbnVtYmVycyBhcmUgcmUtc3luY2hyb25p c2VkIHdpdGggYQ0KY2hhbGxlbmdlLXJlc3BvbnNlIHByb3RvY29sLg0KDQpEb2VzIHRoaXMgbWFr ZSBtb3JlIHNlbnNlPw0KDQpHw7ZyYW4NCg0K From nobody Mon Jan 23 15:25:00 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0F112947F; Mon, 23 Jan 2017 15:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 Aj_7WS7VUSOC; Mon, 23 Jan 2017 15:24:57 -0800 (PST) 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 A17AF12941A; Mon, 23 Jan 2017 15:24:56 -0800 (PST) Received: from hebrews (50.45.239.150) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 15:47:52 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , =?utf-8?Q?'Christian_Ams=C3=BCss'?= , , , 'Francesca Palombini' References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> In-Reply-To: Date: Mon, 23 Jan 2017 15:24:44 -0800 Message-ID: <002501d275cf$e2e145a0$a8a3d0e0$@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: AQKtQcEG0jyjNh7M+HUa8yeT6gtoTwL0dI4Ln3l4MRA= Content-Language: en-gb X-Originating-IP: [50.45.239.150] Archived-At: Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 23:24:59 -0000 I do not believe that this would make me happy. I do not believe that = it would be possible to get an integrity check over the entire content = in this manner. It is possible that the creating of some type of Secure = ETag - either at the OSCOAP or CoAP layer might do what I would be = looking for. Jim > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: 23 January 2017 05:27 > To: Christian Ams=C3=BCss ; = draft-ietf-core- > object-security@ietf.org; core@ietf.org; Jim Schaad > ; Francesca Palombini > > Subject: Re: OSCOAP's inner-blockwise >=20 > hi Christian, >=20 > Thanks for bringing this to the list. >=20 > We have been re-iterating the argumentation for having a binding = between > the blocks. It was introduced to protect against interchange of = blocks from > different representations of the same resource exchanged between the > same client and server. On second thought such a protection a) should = not > be mandatory to as this is not prohibited RFC7959, and b) can instead = be > achieved using ETag, as you propose, which is protected by OSCOAP and = thus > can be used to verify that blocks belong to the same representation. >=20 > With this in mind, I don=E2=80=99t see a reason to bind the integrity = of the different > blocks to each other and we should remove the tag-previous-block from = the > external_aad. >=20 > Unless there is an objection, it will be removed in the next version. >=20 > G=C3=B6ran >=20 >=20 >=20 > On 2017-01-17 13:42, "Christian Ams=C3=BCss" = > wrote: >=20 > >Hello OSCOAP authors and implementors, > > > >I'm taking a discussion from [oscoap:#49] to the list because it > >exceeds the topic of the issue, and maybe could use feedback from > >poeple not directly involved with the detail of the issue. > > > > > >I think that the protection currently drafted for the inner blockwise > >option (that is, using the MAC of the previous exchanged block as = part > >of the AAD in securing the next block, thus creating a chain of > >authenticated messages), is rather intrusive: It requires retaining > >additional state, and requires the message protection part to = interact > >with the blockwise transfer part). What I am advocating is a slimmer > >course of action, like determining resource consistency using an = ETag, > >to achieve the same protection. (If an ETag is insufficient, maybe a > >Secure-ETag that's required to change under these or those conditions > >is.) > > > >I suggest thinking about the block2 case first, as if it turns out = that > >tag chaining is absolutely required there, things won't be any easier > >for the block1 case. > > > > > >Jim Schaad wrote in [oscoap:#49]: > >> the reason for using the crypto tag is to have the ability to > >> establish that the entire message has been integrity protected = rather > >> than just the independent pieces > > > >But does chaining the tags actually achieve that? All they establish = is > >that both client and server agree that there was a continuous = exchange > >of messages that led to the last block transferred. A client could = have > >skipped a block during the transfer (eg. because it already has the > >block), finish a securely chained transfer, and then would then still > >work with a partially secured resource.[1] > > > >We would need to require block transfers to be strictly iterating / = not > >use cached ETags, but IMO that would lose so much of blockwise that = it > >feels more like its own fragmentation scheme. > > > > > >Best regards > >Christian > > > > > >[oscoap:#49]: https://github.com/core-wg/oscoap/issues/49 > > > >[1]: Following the letter of the draft, the resource could even = change > >during the transfer (provided no ETags are used), and the server = could > >sign off the stream. That can be fixed easily in the draft, but > >requires implementations to transfer additional information between > components. > > > >-- > >To use raw power is to make yourself infinitely vulnerable to greater > >powers. > > -- Bene Gesserit axiom From nobody Tue Jan 24 00:42:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396551294BE for ; Tue, 24 Jan 2017 00:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2z2lYbMKAhP for ; Tue, 24 Jan 2017 00:42:29 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71DB129458 for ; Tue, 24 Jan 2017 00:42:29 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id m124so95189090oif.1 for ; Tue, 24 Jan 2017 00:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=5G+65X7uc9yxQWvn8QVfFiTTlYM+vLCyc7zhktZK/cc=; b=JCqbLLHIsDXwFpLKlsHPgbMLQxp3GGXhhk8V8z/QXtWB9kCx3QIsCiyEr1TTXQfZdg BMS/Pzrm7nL21tegheJnlRfwh0ghEDV2NuZL3L5RSy7KvUTVXVSO69glbqy3/qjUMGSt FpZHEPBP2ngTwfVHX9TMpdMQ+iBRpYp/e973EUr11pB68tXzB11i8yy/LhoTdNZZ6VKY u51+/rgzPihKjv5tD2CXwjj0WknNPuoQhqn11WKPqtG7uMPrAIhPHsWDz9fhB2+o+qx8 JjwIfve+jWO8Yw67IvZp1YhWP+I+w2ivWg/utF7c0wvp7tzMKuygR+y3aORGIJ1vpbBB TYlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=5G+65X7uc9yxQWvn8QVfFiTTlYM+vLCyc7zhktZK/cc=; b=fUubTXo/txOpa9gK+Sayr/8GJKrzFn6ooDbExtf72rAxRUujXiNVRNb38om+cWjvrS E54GDjhqOxhOhDSdqVkzFir93K05zd0tNknQ+6icV8/PfaRjZqgnCi3Ia9EfmVEbOLbx X6cl4O7qWa6XFJVqcKNqPYr2IOaY3fPBkIVLH8v9yCMTGATe7Nw5+hB55reQdG/fqD3p d/m9fp6wVo7uikh8xc+WXfUwnMZS8JPOid7mMtpUUVGoE1NP/e9BsLX1iZ7yRuIcJtOV m7uUCKuoqJxnyS8nxr+jgRxL2sBtzob4lVlyLuna9F7vN8JyAPaGnc2cZahwE9l2ri7v mstg== X-Gm-Message-State: AIkVDXKiP+8hhLEQSGhWp9c/cVkjgGDReF58LUV1CWrkZorKyzwU4DYdKKkmNdeD6ZFFCi/4wHqL3ypKUC1HSg== X-Received: by 10.202.217.67 with SMTP id q64mr14333871oig.3.1485247349053; Tue, 24 Jan 2017 00:42:29 -0800 (PST) MIME-Version: 1.0 Sender: anaminaburo@gmail.com Received: by 10.202.68.131 with HTTP; Tue, 24 Jan 2017 00:42:08 -0800 (PST) From: Ana Minaburo Date: Tue, 24 Jan 2017 09:42:08 +0100 X-Google-Sender-Auth: bNJGrsaEhION6eZmD-TbB-7f4mA Message-ID: To: Core , peter van der Stok Content-Type: multipart/alternative; boundary=001a113cf48ca4df070546d31813 Archived-At: Subject: [core] Confirmable message X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 08:42:31 -0000 --001a113cf48ca4df070546d31813 Content-Type: text/plain; charset=UTF-8 Hi Peter In the draft, draft-vanderstok-core-comi-11.txt, you mention that a confirmable message is mandatory for carry CoMi requests. We understand that for setting a value it is necessary to be sure that the information has been correctly received. In LPWAN WG we are studying the way to compress header and reduce traffic on very constraint links. Do you think, it could be possible to suppress this constraint and allow the use of NON confirmable messages ? Thanks Ana --001a113cf48ca4df070546d31813 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Peter

In the draft,=C2=A0draft-vanderstok-core-comi-11.txt,=C2=A0=C2=A0you mention that a confirmable message = is mandatory for carry CoMi requests. We understand that for setting a valu= e it is necessary to be sure that the information has been correctly receiv= ed. In LPWAN WG we are studying the way to compress header and reduce traff= ic on very constraint links. Do you think, it could be possible to suppress= this constraint and allow the use of NON confirmable messages ?

Thanks

Ana
--001a113cf48ca4df070546d31813-- From nobody Tue Jan 24 01:08:57 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8131294AC for ; Tue, 24 Jan 2017 01:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ps9ofXasSL for ; Tue, 24 Jan 2017 01:08:54 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE6F12949D for ; Tue, 24 Jan 2017 01:08:53 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.211]) by smtp-cloud6.xs4all.net with ESMTP id c98r1u00X4ZF39u0198rxs; Tue, 24 Jan 2017 10:08:52 +0100 Received: from AMontpellier-654-1-133-202.w90-0.abo.wanadoo.fr ([90.0.92.202]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 Jan 2017 10:08:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 Jan 2017 10:08:51 +0100 From: peter van der Stok To: Ana Minaburo Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <177d3ea5b2b029e1df8aed315e56ff04@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Confirmable message X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:08:57 -0000 Hi Ana, thanks for the motivated suggestion. We can change the text such that every implementation MUST support the confirmable requests, and MAY support non-confirmable requests. would that do the trick? It is then possible that a client that accesses unknowingly a LPWAN server uses confirmable requests and cannot use non-confirmable requests. Other variations are possible. But I like to restrict the number of request possibilities. Peter Ana Minaburo schreef op 2017-01-24 09:42: > Hi Peter > > In the draft, draft-vanderstok-core-comi-11.txt, you mention that a > confirmable message is mandatory for carry CoMi requests. We > understand that for setting a value it is necessary to be sure that > the information has been correctly received. In LPWAN WG we are > studying the way to compress header and reduce traffic on very > constraint links. Do you think, it could be possible to suppress this > constraint and allow the use of NON confirmable messages ? > > Thanks > > Ana > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jan 24 01:59:22 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB5129582; Tue, 24 Jan 2017 01:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naTRsd4edfVz; Tue, 24 Jan 2017 01:59:19 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E687C12949A; Tue, 24 Jan 2017 01:59:18 -0800 (PST) X-AuditID: c1b4fb2d-a9bff70000007e3d-ea-588725741d46 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id D6.64.32317.47527885; Tue, 24 Jan 2017 10:59:17 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 11:00:13 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" , Francesca Palombini Thread-Topic: OSCOAP's inner-blockwise Thread-Index: AQHScL8hm4bYm3XXc0WT0oYraDzgmqFGFyoAgACWVgCAAMIIAA== Date: Tue, 24 Jan 2017 09:59:15 +0000 Message-ID: References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> <002501d275cf$e2e145a0$a8a3d0e0$@augustcellars.com> In-Reply-To: <002501d275cf$e2e145a0$a8a3d0e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7t26panuEwfmbQhbLLzxnsdj3dj2z xbR/Z1gsVk//zubA4rFxznQ2j6377zJ5LFnykymAOYrLJiU1J7MstUjfLoErY9a1FewFa6wr Gvf9ZW9gfGHZxcjJISFgIrHh0BImEFtIYB2jxLWL5l2MXED2EkaJH9s2soEk2ARcJB40PGIC SYgIrGSSODq3CaxDWEBVYtmPPYwgtoiAmsTlr5eZIWwnifc3TrOC2CxANQf61rGD2LwCFhKH t31lgtiwklHixv/tYEWcAg4SKx5+A9vGKCAm8f3UGrAFzALiEreezGeCOFVAYsme88wQtqjE y8f/wHpFBfQklj9fAxVXlLg6fTlQPQdQr6bE+l36EGOsJXr2T2aGsBUlpnQ/hLpHUOLkzCcs ExjFZiHZNguhexaS7llIumch6V7AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzDqDm75 rbuDcfVrx0OMAhyMSjy8BVJtEUKsiWXFlbmHGCU4mJVEeB+ptEcI8aYkVlalFuXHF5XmpBYf YpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwOhbW8CrcEJR9Td/rrvino/r2PXzz2vc WWabaNWzZ4f/xFyzHbzNLz4JHM5l/lhqbRzq1vX32okpIpuNfvU8rkstWmS2bIP+DbnaQnmB uJKDB29scec/9Wr5y4bLHT/2d12Z9+hm9Jkb8+U1Mvu1f37ING+Vk1ijy6C4cUrLxqc2Xbdv mi1h/67EUpyRaKjFXFScCABEcWvxtgIAAA== Archived-At: Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:59:20 -0000 SGkgSmltLA0KDQpJ4oCZbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGlzc3VlLiBJZiB5b3Ug dmVyaWZ5IGFsbCBibG9ja3Mgb2YgYQ0KcGFydGljdWxhciByZXByZXNlbnRhdGlvbiAodXNpbmcg RVRBRyBvciBvdGhlcndpc2Uga25vd2luZyB0aGF0IHRoZQ0KcmVwcmVzZW50YXRpb27CtGlzIHRo ZSBzYW1lIGZvciBkaWZmZXJlbnQgYmxvY2tzKSB0aGVuIHlvdSBoYXZlIGFsc28NCnZlcmlmaWVk IHRoZSBlbnRpcmUgcmVwcmVzZW50YXRpb24sIHNpbmNlIHRoZSBibG9jayBvcHRpb25zIGFyZSBp bnRlZ3JpdHkNCnByb3RlY3RlZCBhbmQgY29udGFpbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbnVt YmVyIG9mIHRoZSBpbmRpdmlkdWFsIGJsb2NrDQphbmQgaWYgaXQgaXMgdGhlIGxhc3QgYmxvY2su DQoNCg0KSWYgeW91IHdhbnQgYSBzZXBhcmF0ZSBpbnRlZ3JpdHkgdmVyaWZpY2F0aW9uIG9mIHRo ZSBlbnRpcmUgcmVwcmVzZW50YXRpb24NCml0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIG5ldyBy ZXNvdXJjZSBjb250YWluaW5nIHRoZSBoYXNoIG9mIGENCnJlcHJlc2VudGF0aW9uOg0KDQovaGFz aG9mL3IxIGZvciByZXNvdXJjZSAvcjENCg0KUmVxdWVzdGluZyB0aGlzIHJlc291cmNlIHdpdGgg R0VUDQoNCkdFVCAvaGFzaG9mL3IxDQoNCnJldHVybnMgdGhlIHRoZSBTSEEtMjU2IG9mIHRoZSBy ZXByZXNlbnRhdGlvbiBvZiAvcjEuIFNwZWNpZmljDQpyZXByZXNlbnRhdGlvbnMgY2FuIGJlIHJl cXVlc3RlZCwgZS5nLiB3aXRoIEVUQUcgaW4gdGhlIFVyaS1RdWVyeToNCg0KR0VUIC9oYXNob2Yv cjE/cjEtRVRBRw0Kd2hlcmUgcjEtRVRBRyBpcyB0aGUgRVRBRyBvZiB0aGUgcmVwcmVzZW50YXRp b24gb2YgcjEgZm9yIHdoaWNoIHRoZSBoYXNoDQppcyByZXF1ZXN0ZWQuDQoNCihPZiBjb3Vyc2Us IHNpbmNlIHRoaXMgdGhpcyByZXNvdXJjZSBjb250YWlucyB0aGUgcGxhaW4gaGFzaCwgYSBzZWN1 cml0eQ0KcHJvdG9jb2wgc3VjaCBhcyBEVExTIG9yIE9TQ09BUCBtdXN0IGJlIHVzZWQgd2hlbiBh Y2Nlc3NpbmcgdGhlIGhhc2ggaW4NCm9yZGVyIHRvIHZlcmlmeSB0aGUgaW50ZWdyaXR5IG9mIHRo ZSByZXByZXNlbnRhdGlvbi4pDQoNCldvdWxkIGFueXRoaW5nIGxpa2UgdGhpcyBhZGRyZXNzIHlv dXIgY29uY2Vybj8NCg0KR8O2cmFuDQoNCg0KDQoNCk9uIDIwMTctMDEtMjQgMDA6MjQsICJKaW0g U2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQoNCj5JIGRvIG5vdCBiZWxp ZXZlIHRoYXQgdGhpcyB3b3VsZCBtYWtlIG1lIGhhcHB5LiAgSSBkbyBub3QgYmVsaWV2ZSB0aGF0 IGl0DQo+d291bGQgYmUgcG9zc2libGUgdG8gZ2V0IGFuIGludGVncml0eSBjaGVjayBvdmVyIHRo ZSBlbnRpcmUgY29udGVudCBpbg0KPnRoaXMgbWFubmVyLiAgSXQgaXMgcG9zc2libGUgdGhhdCB0 aGUgY3JlYXRpbmcgb2Ygc29tZSB0eXBlIG9mIFNlY3VyZQ0KPkVUYWcgLSBlaXRoZXIgYXQgdGhl IE9TQ09BUCBvciBDb0FQIGxheWVyIG1pZ2h0IGRvIHdoYXQgSSB3b3VsZCBiZQ0KPmxvb2tpbmcg Zm9yLg0KPg0KPkppbQ0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IEfDtnJhbiBTZWxhbmRlciBbbWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbV0N Cj4+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNyAwNToyNw0KPj4gVG86IENocmlzdGlhbiBBbXPDvHNz IDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD47IGRyYWZ0LWlldGYtY29yZS0NCj4+IG9i amVjdC1zZWN1cml0eUBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZzsgSmltIFNjaGFhZA0KPj4gPGll dGZAYXVndXN0Y2VsbGFycy5jb20+OyBGcmFuY2VzY2EgUGFsb21iaW5pDQo+PiA8ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbi5jb20+DQo+PiBTdWJqZWN0OiBSZTogT1NDT0FQJ3MgaW5uZXIt YmxvY2t3aXNlDQo+PiANCj4+IGhpIENocmlzdGlhbiwNCj4+IA0KPj4gVGhhbmtzIGZvciBicmlu Z2luZyB0aGlzIHRvIHRoZSBsaXN0Lg0KPj4gDQo+PiBXZSBoYXZlIGJlZW4gcmUtaXRlcmF0aW5n IHRoZSBhcmd1bWVudGF0aW9uIGZvciBoYXZpbmcgYSBiaW5kaW5nIGJldHdlZW4NCj4+IHRoZSBi bG9ja3MuICBJdCB3YXMgaW50cm9kdWNlZCB0byBwcm90ZWN0IGFnYWluc3QgaW50ZXJjaGFuZ2Ug b2YgYmxvY2tzDQo+PmZyb20NCj4+IGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgb2YgdGhlIHNh bWUgcmVzb3VyY2UgZXhjaGFuZ2VkIGJldHdlZW4gdGhlDQo+PiBzYW1lIGNsaWVudCBhbmQgc2Vy dmVyLiBPbiBzZWNvbmQgdGhvdWdodCBzdWNoIGEgcHJvdGVjdGlvbiBhKSBzaG91bGQNCj4+bm90 DQo+PiBiZSBtYW5kYXRvcnkgdG8gYXMgdGhpcyBpcyBub3QgcHJvaGliaXRlZCBSRkM3OTU5LCBh bmQgYikgY2FuIGluc3RlYWQgYmUNCj4+IGFjaGlldmVkIHVzaW5nIEVUYWcsIGFzIHlvdSBwcm9w b3NlLCB3aGljaCBpcyBwcm90ZWN0ZWQgYnkgT1NDT0FQIGFuZA0KPj50aHVzDQo+PiBjYW4gYmUg dXNlZCB0byB2ZXJpZnkgdGhhdCBibG9ja3MgYmVsb25nIHRvIHRoZSBzYW1lIHJlcHJlc2VudGF0 aW9uLg0KPj4gDQo+PiBXaXRoIHRoaXMgaW4gbWluZCwgSSBkb27igJl0IHNlZSBhIHJlYXNvbiB0 byBiaW5kIHRoZSBpbnRlZ3JpdHkgb2YgdGhlDQo+PmRpZmZlcmVudA0KPj4gYmxvY2tzIHRvIGVh Y2ggb3RoZXIgYW5kIHdlIHNob3VsZCByZW1vdmUgdGhlIHRhZy1wcmV2aW91cy1ibG9jayBmcm9t DQo+PnRoZQ0KPj4gZXh0ZXJuYWxfYWFkLg0KPj4gDQo+PiBVbmxlc3MgdGhlcmUgaXMgYW4gb2Jq ZWN0aW9uLCBpdCB3aWxsIGJlIHJlbW92ZWQgaW4gdGhlIG5leHQgdmVyc2lvbi4NCj4+IA0KPj4g R8O2cmFuDQo+PiANCj4+IA0KPj4gDQo+PiBPbiAyMDE3LTAxLTE3IDEzOjQyLCAiQ2hyaXN0aWFu IEFtc8O8c3MiIDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4NCj4+IHdyb3RlOg0KPj4g DQo+PiA+SGVsbG8gT1NDT0FQIGF1dGhvcnMgYW5kIGltcGxlbWVudG9ycywNCj4+ID4NCj4+ID5J J20gdGFraW5nIGEgZGlzY3Vzc2lvbiBmcm9tIFtvc2NvYXA6IzQ5XSB0byB0aGUgbGlzdCBiZWNh dXNlIGl0DQo+PiA+ZXhjZWVkcyB0aGUgdG9waWMgb2YgdGhlIGlzc3VlLCBhbmQgbWF5YmUgY291 bGQgdXNlIGZlZWRiYWNrIGZyb20NCj4+ID5wb2VwbGUgbm90IGRpcmVjdGx5IGludm9sdmVkIHdp dGggdGhlIGRldGFpbCBvZiB0aGUgaXNzdWUuDQo+PiA+DQo+PiA+DQo+PiA+SSB0aGluayB0aGF0 IHRoZSBwcm90ZWN0aW9uIGN1cnJlbnRseSBkcmFmdGVkIGZvciB0aGUgaW5uZXIgYmxvY2t3aXNl DQo+PiA+b3B0aW9uICh0aGF0IGlzLCB1c2luZyB0aGUgTUFDIG9mIHRoZSBwcmV2aW91cyBleGNo YW5nZWQgYmxvY2sgYXMgcGFydA0KPj4gPm9mIHRoZSBBQUQgaW4gc2VjdXJpbmcgdGhlIG5leHQg YmxvY2ssIHRodXMgY3JlYXRpbmcgYSBjaGFpbiBvZg0KPj4gPmF1dGhlbnRpY2F0ZWQgbWVzc2Fn ZXMpLCBpcyByYXRoZXIgaW50cnVzaXZlOiBJdCByZXF1aXJlcyByZXRhaW5pbmcNCj4+ID5hZGRp dGlvbmFsIHN0YXRlLCBhbmQgcmVxdWlyZXMgdGhlIG1lc3NhZ2UgcHJvdGVjdGlvbiBwYXJ0IHRv IGludGVyYWN0DQo+PiA+d2l0aCB0aGUgYmxvY2t3aXNlIHRyYW5zZmVyIHBhcnQpLiBXaGF0IEkg YW0gYWR2b2NhdGluZyBpcyBhIHNsaW1tZXINCj4+ID5jb3Vyc2Ugb2YgYWN0aW9uLCBsaWtlIGRl dGVybWluaW5nIHJlc291cmNlIGNvbnNpc3RlbmN5IHVzaW5nIGFuIEVUYWcsDQo+PiA+dG8gYWNo aWV2ZSB0aGUgc2FtZSBwcm90ZWN0aW9uLiAoSWYgYW4gRVRhZyBpcyBpbnN1ZmZpY2llbnQsIG1h eWJlIGENCj4+ID5TZWN1cmUtRVRhZyB0aGF0J3MgcmVxdWlyZWQgdG8gY2hhbmdlIHVuZGVyIHRo ZXNlIG9yIHRob3NlIGNvbmRpdGlvbnMNCj4+ID5pcy4pDQo+PiA+DQo+PiA+SSBzdWdnZXN0IHRo aW5raW5nIGFib3V0IHRoZSBibG9jazIgY2FzZSBmaXJzdCwgYXMgaWYgaXQgdHVybnMgb3V0IHRo YXQNCj4+ID50YWcgY2hhaW5pbmcgaXMgYWJzb2x1dGVseSByZXF1aXJlZCB0aGVyZSwgdGhpbmdz IHdvbid0IGJlIGFueSBlYXNpZXINCj4+ID5mb3IgdGhlIGJsb2NrMSBjYXNlLg0KPj4gPg0KPj4g Pg0KPj4gPkppbSBTY2hhYWQgd3JvdGUgaW4gW29zY29hcDojNDldOg0KPj4gPj4gdGhlIHJlYXNv biBmb3IgdXNpbmcgdGhlIGNyeXB0byB0YWcgaXMgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0bw0KPj4g Pj4gZXN0YWJsaXNoIHRoYXQgdGhlIGVudGlyZSBtZXNzYWdlIGhhcyBiZWVuIGludGVncml0eSBw cm90ZWN0ZWQgcmF0aGVyDQo+PiA+PiB0aGFuIGp1c3QgdGhlIGluZGVwZW5kZW50IHBpZWNlcw0K Pj4gPg0KPj4gPkJ1dCBkb2VzIGNoYWluaW5nIHRoZSB0YWdzIGFjdHVhbGx5IGFjaGlldmUgdGhh dD8gQWxsIHRoZXkgZXN0YWJsaXNoIGlzDQo+PiA+dGhhdCBib3RoIGNsaWVudCBhbmQgc2VydmVy IGFncmVlIHRoYXQgdGhlcmUgd2FzIGEgY29udGludW91cyBleGNoYW5nZQ0KPj4gPm9mIG1lc3Nh Z2VzIHRoYXQgbGVkIHRvIHRoZSBsYXN0IGJsb2NrIHRyYW5zZmVycmVkLiBBIGNsaWVudCBjb3Vs ZCBoYXZlDQo+PiA+c2tpcHBlZCBhIGJsb2NrIGR1cmluZyB0aGUgdHJhbnNmZXIgKGVnLiBiZWNh dXNlIGl0IGFscmVhZHkgaGFzIHRoZQ0KPj4gPmJsb2NrKSwgZmluaXNoIGEgc2VjdXJlbHkgY2hh aW5lZCB0cmFuc2ZlciwgYW5kIHRoZW4gd291bGQgdGhlbiBzdGlsbA0KPj4gPndvcmsgd2l0aCBh IHBhcnRpYWxseSBzZWN1cmVkIHJlc291cmNlLlsxXQ0KPj4gPg0KPj4gPldlIHdvdWxkIG5lZWQg dG8gcmVxdWlyZSBibG9jayB0cmFuc2ZlcnMgdG8gYmUgc3RyaWN0bHkgaXRlcmF0aW5nIC8gbm90 DQo+PiA+dXNlIGNhY2hlZCBFVGFncywgYnV0IElNTyB0aGF0IHdvdWxkIGxvc2Ugc28gbXVjaCBv ZiBibG9ja3dpc2UgdGhhdCBpdA0KPj4gPmZlZWxzIG1vcmUgbGlrZSBpdHMgb3duIGZyYWdtZW50 YXRpb24gc2NoZW1lLg0KPj4gPg0KPj4gPg0KPj4gPkJlc3QgcmVnYXJkcw0KPj4gPkNocmlzdGlh bg0KPj4gPg0KPj4gPg0KPj4gPltvc2NvYXA6IzQ5XTogaHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cvb3Njb2FwL2lzc3Vlcy80OQ0KPj4gPg0KPj4gPlsxXTogRm9sbG93aW5nIHRoZSBsZXR0ZXIg b2YgdGhlIGRyYWZ0LCB0aGUgcmVzb3VyY2UgY291bGQgZXZlbiBjaGFuZ2UNCj4+ID5kdXJpbmcg dGhlIHRyYW5zZmVyIChwcm92aWRlZCBubyBFVGFncyBhcmUgdXNlZCksIGFuZCB0aGUgc2VydmVy IGNvdWxkDQo+PiA+c2lnbiBvZmYgdGhlIHN0cmVhbS4gVGhhdCBjYW4gYmUgZml4ZWQgZWFzaWx5 IGluIHRoZSBkcmFmdCwgYnV0DQo+PiA+cmVxdWlyZXMgaW1wbGVtZW50YXRpb25zIHRvIHRyYW5z ZmVyIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYmV0d2Vlbg0KPj4gY29tcG9uZW50cy4NCj4+ID4N Cj4+ID4tLQ0KPj4gPlRvIHVzZSByYXcgcG93ZXIgaXMgdG8gbWFrZSB5b3Vyc2VsZiBpbmZpbml0 ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlcg0KPj4gPnBvd2Vycy4NCj4+ID4gIC0tIEJlbmUgR2Vz c2VyaXQgYXhpb20NCj4NCj4NCg0K From nobody Tue Jan 24 02:10:13 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE2D129586; Tue, 24 Jan 2017 02:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDaRfP4IYLsa; Tue, 24 Jan 2017 02:10:09 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B924012949A; Tue, 24 Jan 2017 02:10:09 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D745245FF5; Tue, 24 Jan 2017 11:10:07 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0E1E34D; Tue, 24 Jan 2017 11:10:07 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D2FF5388; Tue, 24 Jan 2017 11:10:06 +0100 (CET) Received: (nullmailer pid 32468 invoked by uid 1000); Tue, 24 Jan 2017 10:10:05 -0000 Date: Tue, 24 Jan 2017 11:10:05 +0100 From: chrysn To: Jim Schaad Message-ID: <20170124101005.qbx2koqti7r2vzxs@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5eueo2rthy57khjk" Content-Disposition: inline In-Reply-To: <002501d275cf$e2e145a0$a8a3d0e0$@augustcellars.com> <017f01d27160$e7ffb620$b7ff2260$@augustcellars.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: draft-ietf-core-object-security@ietf.org, core@ietf.org Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 10:10:11 -0000 --5eueo2rthy57khjk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, On Mon, Jan 23, 2017 at 03:24:44PM -0800, Jim Schaad wrote: > I do not believe that this would make me happy. I do not believe that > it would be possible to get an integrity check over the entire content > in this manner. It is possible that the creating of some type of > Secure ETag - either at the OSCOAP or CoAP layer might do what I would > be looking for. well, let's work that out; I'm confident we can come up with something that gives both the flexibility of inner blockwise and a way to trust the assembled message. (Again, I'll focus on the block2 use here, because that's the one where constrained servers need to deal with the biggest increase of complexity due to current OSCOAP. Later we can see how to apply those findings to block1. If you want to bring up block1 now for whatever reasons, feel free to -- this is just so nobody expect everything below to hold for block1 too without adaptions). On Wed, Jan 18, 2017 at 12:00:14AM -0800, Jim Schaad wrote: > [... Outer-blockwise is safe but inflexible/impractical, and ...] > The introduction of inner blocking allowed for a simple way to address > this issue, but with the loss of the end-to-end integrity on the > entirety of the message. What I think makes this topic difficult is that none of the documents involved really describe the composite message. RFC7959 ("blockwise") does describe the relationship between the payload (the individual message's contents) and the body (the concatenation of the payloads). The aiocoap and txThings implementations (and possibly others) do have a concept of "the whole message", because it is convenient for a user to call something like `request(code=3DGET, path=3D"/firmware", accept=3D42)` = and get back a `Message(code=3D2.05, etag=3D..., payload=3Dsome-64k-blob)` obje= ct -- but in my understanding of CoAP, this whole message deliberately does not exist, not only due to resource constraints, but also for architectural reasons (state transfer vs. message passing). We still want to be be sure of the integrity of the composite message, though. As we won't get protection of such a composite message, we'll need to verify the that it was composed of matching parts. The -01 draft provides a way to describe a sequence of matching parts (the tag-previous-block), but does not describe criteria by which to decide what matches. (For example, may a server sign off a 4th-block response as the successor of a 2nd-block response?). To avoid writing tons of irrelevant details: The case you're worried about, is it about mismatching payloads, mismatching options, or both? > I am not sure at the moment that I have any understanding of the expected > scenarios where random access would be used. The ones that I can think of > are: >=20 > 1. I receive a message that provides a set of instructions with what has > changed and I can get incremental updates.=20 > 2. It is something that is large, but I might only care about pieces of = the > data rather than the whole thing - such as a log file. I can't relate to 1, but 2 is something I do regularly, and occasionally even writing. There is one other I think of as relevant: 3. A large resource changes mid-blockwise: GET /radar block=3D1 -- CONTENT, ETag=3D0xbeef GET /radar block=3D2 -- CONTENT, ETag=3D0xbeef GET /radar block=3D3 -- CONTENT, ETag=3D0xcafe (oups, we'll need to rewind) GET /radar block=3D1 -- CONTENT, ETag=3D0xcafe GET /radar block=3D2 -- CONTENT, ETag=3D0xcafe (skipping 3, because 0xcafe is cached) GET /radar block=3D4 -- CONTENT, ETag=3D0xcafe, last block Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --5eueo2rthy57khjk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAliHJ/cACgkQOY0REtOk veGuWhAAlCTLl4wxue9zKz/D/JT/xpQ9MBQvMUbyBnBxX5i0eF4lxQ99QILMbn40 mAhV2r8IUE2HIhcBfSOJFXmO+4ZQT9G/IRaCL2sEDH+P/tMJ+d0Ehm2UPJoN/Vze uXpOxUnRFL6I6mePI4Y3EhgVxrxETsA3+vF+E2b1PFAWsItFhd5aQk0IVYM/em2H Q0VNSWpxFKvvyWc8IetIVx4O/gQHeM1isvVZaL1Fh0Axmk5o8cjDYh+IudNAdbm/ NlY7u/T/fXzaWq9bdbhmIlnx5ZaMlBHeJX3MybMOaaIqmEDiapcyDXYhoLjo213j 70EtJDJpTktON9Gn35LnaloYVgbCOqHmmccLHYCC2LLJoxHGsaxfIFKnTP2ZvPa9 eEMqiCUEcndAFdlcJBFOn/k4zOpeGetN8nYNUkTzj06Hd9t6uLeCIvBMMsS56g1C Chl6OGA0P3j23aXte1ugSEf1nCsS2s57svXauRyDN7lTZAPdmAqkft6BxS3h+QBk DVqt7yhkI8mUScPgZ+DNC57XsCYeXoQfJ3kMs2F9rxEgqRLHbfLEWD5G3Cjb79Xn qCPubW1EwbNHkOsreQl/duYvdJA0OrmofhZScN9zLoLdVQy4nt2XKCep9qNCKRWi 3WsQtkrIsY4HD93uiVYdVSvg6WKIoeAJ/5kgSKNhI0b4+9iRiF8= =vB4n -----END PGP SIGNATURE----- --5eueo2rthy57khjk-- From nobody Tue Jan 24 02:10:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE44129591 for ; Tue, 24 Jan 2017 02:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx2u85H6iPP7 for ; Tue, 24 Jan 2017 02:10:47 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C51C129586 for ; Tue, 24 Jan 2017 02:10:47 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id v186so108068373lfa.1 for ; Tue, 24 Jan 2017 02:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=to:from:subject:message-id:date:user-agent:mime-version; bh=pD7f6qXA6l82TcMsRRTzF3s6iNexgOPckqvT8Ss3gWI=; b=ZNIA80HWox7AkW3NFGQs1SD1iKGUW2PA5pp5a7bSzYcd/vD5LwcFrUzn1Q6Q2msA/k 1EdjTY5R45HzvUqKtnH1jOvDgaMGuTnVmFEgoPLHOzPMfhOAY6ptC2JWb4DjnwHp98cN oFeXwF5urskwoZeTL3eL3n4lTUouH3nL28zrmIEysigDCZ8qXBgH444ZPHjjtwjelkVd W8kYekYWtx4uM/m4n/QSgSOrmlnEo8SEdG4scmWftVN2Xw3uI1LDuM0z5AHZDLBoJJu2 NmQ3bTmw+VWVy4lnp8WheisphCNI+V3PvcPDZOa86pswtVjSOuBAvU7LVY7eT4d1dJwO cLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=pD7f6qXA6l82TcMsRRTzF3s6iNexgOPckqvT8Ss3gWI=; b=nU+A6/VtMq2VUV8QSsAe8KZvuOrfFbhmE6mSs1WCjXjyol+5BwSTRu9XEB6qUnX8rW tuFQVm6kRRD+16y8bkLlbJiZ+6eJ1aj6J2S5NAawbhp6UAemE5XCp8N+SZ6zpVW7MIr+ xKfBIWERYQIZm59P7MJTNktXmrUYInGPVG5Ktx8dowXwByqKFdJtTanH8/nm7ovd5fYK RWckDKsNFLhRHzY/Ne5DPm6aAP+x0IfdSxv/UO8wgWSipSGS4ikfsYF1Xj0MyOH5flWR o2EGAHv7pB71y7V+efgFUd1bxO0oJ4jN8hk7lRic7Ue0L5Xws6UhWCWMUbmZqNYge/Gt e3bQ== X-Gm-Message-State: AIkVDXKyXbj62cGxpvAUycf0SVtTWl0lKwEuFasTcnCBT/+klASpPk+6REUGYUnC1E09Gjwf X-Received: by 10.25.228.91 with SMTP id b88mr11050556lfh.177.1485252645088; Tue, 24 Jan 2017 02:10:45 -0800 (PST) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id x78sm7156079lfb.44.2017.01.24.02.10.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 02:10:44 -0800 (PST) To: core From: Ludwig Seitz Message-ID: Date: Tue, 24 Jan 2017 11:10:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090900050902030309050305" Archived-At: Subject: [core] Correct behavior of observe, blockwise etc. if access rights expire X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 10:10:49 -0000 This is a cryptographically signed message in MIME format. --------------ms090900050902030309050305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, I'm currently considering a question that has arisen in the context of=20 ACE, for which I'd like some input from CoRE: If a client has a long-running request such as an observe, a blockwise=20 transmission, or a subscription in a pubSub scenario ongoing and the=20 access rights for that request expire or are revoked. What would be the=20 desirable behavior of the RS: a.) Send a final 4.01 Unauthorized and then drop the long-running request= b.) Silently drop the long-running request Regards, Ludwig --=20 Ludwig Seitz, PhD RISE ICT/SICS Ideon Science Park, Building Beta 2 Scheelev=C3=A4gen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 --------------ms090900050902030309050305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNzAxMjQxMDEwNDNaMC8GCSqGSIb3DQEJBDEiBCD/i6LlTQTL 5XTC+tSVNQ9po8beLSZudgW3QEdZNiF6FTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQBh9fxIQaSU9q7iwVLErDkh dKkNdVIct/7QmXkmc8UP2a3AykQbIdkOx+BYhHzAauKMS10zRJjcsEawnUq3kni2c01ZpVxM SVaxn85rYbKqa/9p06BLXnsX0CE+6w9oUgqZ5ERulrqPZ9+9NTOMzYB06yik/LgbjIDy1wBX 8maf6oA+h06jt8hTV0SRDasyl8AInmujDfV3JphvsbaNZbOHlxZt8gWMUQ/PMauqMlLz7Zf0 5g6cAzki18ZogdwWqL+XPuUHxGLq2R/G98HueN7CpvTcpJhnaLT8UT7Z5oTx6EwajiOWXqNj CcY2YXWuFw/JLNvOGrHoijekan12HgawAAAAAAAA --------------ms090900050902030309050305-- From nobody Tue Jan 24 03:19:00 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568C712957F; Tue, 24 Jan 2017 03:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY_OlGmC9FGY; Tue, 24 Jan 2017 03:18:56 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7244E12949D; Tue, 24 Jan 2017 03:18:56 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A475145FF5; Tue, 24 Jan 2017 12:18:53 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5138F4D; Tue, 24 Jan 2017 12:18:52 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 180693BE; Tue, 24 Jan 2017 12:18:52 +0100 (CET) Received: (nullmailer pid 4744 invoked by uid 1000); Tue, 24 Jan 2017 11:18:50 -0000 Date: Tue, 24 Jan 2017 12:18:50 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20170124111850.5ra2cnoqbw6ywgu5@hephaistos.amsuess.com> References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2bzbred2dxp7kw3f" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 11:18:58 -0000 --2bzbred2dxp7kw3f Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello G=C3=B6ran, On Mon, Jan 23, 2017 at 01:26:40PM +0000, G=C3=B6ran Selander wrote: > With this in mind, I don=E2=80=99t see a reason to bind the integrity of = the > different blocks to each other and we should remove the tag-previous-block > from the external_aad. Pending Jim's objections, I'd tentatively move forward to the Block1 case; dropping tag-previous-block from external_aad_req would again make us open to Client Foe Server POST "incarcerate"(1/2) ---> ---> <--- <--- 2.31 CONTINUE POST "valjean"(2/2) --->@ <---RST (Client: Odd, but let's go on and promote Javert) POST "promote"(1/2) ---> ---> <--- <--- 2.31 CONTINUE @ ---> <--- 2.04 Valjean Promoted! (The @ indicates a maliciously delayed / wormholed package as used in draft-mattsson-core-coap-actuators-02). To mitigate that without linking messages again, I propose the following addition: --------- (in section 4.3 "CoAP options", figure 4) Option Request-Tag (details as below) is E:* as are the block options. (in section 4.3.1.3 "The Block Options") The Block options (Block1, Block2, Size1 and Size2 *as well as Request-Tag*) MAY be either... (new section 6.6) Integrity protection for `Block1` requests When a client uses inner block options to split up the payload of a request (that is, whenever the Block1 option is used as a class E option), the client MUST add a Request-Tag option with the same value to all the blocks of a single request, and the server MUST verify that the Request-Tag values match before acting atomically on several requests. [Author's note: I'm only limiting the server w/rt atomic requests, as the different messages from a non-atomic operation don't "meet" in the server before taking effect on the resource. To mitigate what those would do in a delayed-message scenario like draft-mattsson-core-coap-actuators-02 figure 4, that could be covered by If-Match and fluctuating ETags, but not on blockwise layer.] The Request-Tag value must be unique per participant within the security context. The client may, for example, use the partial IV of the first block it sends as the request's tag. The role of the Request-Tag is similar to the ETag of responses. Like the ETag, it allows the recipient of blocks to verify that those blocks belong to the same state of a resource. Unlike the ETag, they can not be used for caching, because there is no single authority to assign them to a body. (Two clients would not arrive at the same Request-Tag for the same body, while the origin server is the authority on ETags for a given resource). The Request-Tag option can be used outside of OSCOAP protected messages to separate Block1 requests from a single endpoint to the same resource. As using it would caus mixups of blocks on a server that does not understand it, it is marked as Critical, safe-to-forward, and part of the cache key. Proxies that understand the Block1 and Request-Tag options MAY give it special treatment and use the full body of the request as the cache key instead, as they already may with Block options. +-----+---+---+---+---+-------------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+-------------+--------+--------+---------+ | TBD | x | | | | Request-Tag | opaque | 0-8 | (none) | +-----+---+---+---+---+-------------+--------+--------+---------+ [Author's note on length: Allowing length 0 so people can use the partial IV unmodified as option value. That's still a one-time-per-context situation.] (for 7 "Security Considerations", add) Applications that accept Block1 transfers in a non-atomic fashion need to be aware that OSCOAP does not provide sequence guarantees for the individual blocks, and that updates may arrive maliciously delayed within the window size. When this is a concern, the application might want to switch to atomic mode, where the integrity of the whole request body is provided. (for 9.1 "CoAP Option Numbers Registry") Number: TDB, Name: Request-Tag, Reference: this-document --------- If you want to accept this into the draft, I'd be happy to phrase it as a pull request. Does this sound viable to you? Best regards Christian PS. sorry for any confusion caused by my last message on the same thread, my mail client mixed up the hats, and it was sent from my Free Software developer hat address instead of my work address. --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --2bzbred2dxp7kw3f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAliHOBQACgkQOY0REtOk veH2sQ/+ITeRikVS9Kxecjq1Vc5u5P4nXb4zBsadSRUgyrdWarOjo5NofgBrQQFh lQ22m3Eo63jfzC2KJ1Xn3KbCMGzRw/Fa2yQkB3Ba2nuMckL3phHwX2X4DV4G9CmG Vi7pVKvw7/ZOv/qGKqgTxmmsyQksQcVF2hgP1BqpP5E72o/Xt/xnfLapym+1DRvp YLPEzcse6xzKEQoiGUvbkDlTZW2Avpp/yNgPTWvfSoOnfoigVEsk2IIKmk65SNa8 HDClOMLgD5L0YZ/3zyS0fG5Huuv+UJMgTXHyB2r3Dhjb4anyrxYJg2As6+Yw6/BB sGWP+gPl6I7ho6ZnWcZuOgOlFx7DC8/gfpFmyLYb+2DOexS6pFqt6P1jsoEv3CDh s31oD1+ufgj3xdieVceeOsh8UylpJiTxtl1xAyeaJxZV5SfnRripETjfjlvlVd0r A+VbiGHxyNR9Ww5w/Cg7rTNzTnLKq71ZJMhTWeFOF+esyF5sE0V+KDpGlahNGaP+ D6/xnPXDFeDT8E5re1r9owLfe0dj75oRFe2aKc0c6sY2WDFjhjc96gM/4OZUkZhy aP1se7Qb1X7I+Ibrsp05Mwls7f6t6MJn4WmlATazBcd48v5BL3PSHLWnrwECBC2T Ah6tO+7QjgV4a14jzDs54hy1mG0NMkDaF7REaD+EDqKYUsyn0G8= =0Iyn -----END PGP SIGNATURE----- --2bzbred2dxp7kw3f-- From nobody Tue Jan 24 03:23:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4912956B for ; Tue, 24 Jan 2017 03:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WmO3fBkNPCI for ; Tue, 24 Jan 2017 03:23:11 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1731294AC for ; Tue, 24 Jan 2017 03:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0OBN7r1023012; Tue, 24 Jan 2017 12:23:07 +0100 (CET) Received: from [192.168.217.124] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3v75QM083Xz3ZFD; Tue, 24 Jan 2017 12:23:06 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Tue, 24 Jan 2017 12:23:05 +0100 X-Mao-Original-Outgoing-Id: 506949785.742728-21d36ac81578601943a6586935411055 Content-Transfer-Encoding: quoted-printable Message-Id: <99FC6E6C-21DB-4BDC-8909-268CCD360E7E@tzi.org> References: To: Ludwig Seitz X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core Subject: Re: [core] Correct behavior of observe, blockwise etc. if access rights expire X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 11:23:12 -0000 On 24 Jan 2017, at 11:10, Ludwig Seitz wrote: >=20 > What would be the desirable behavior of the RS: >=20 > a.) Send a final 4.01 Unauthorized and then drop the long-running = request This. > b.) Silently drop the long-running request The client always has to be prepared that this may happen (server = rebooting and forgetting its state), but it may take longer until the = client finally goes re-establishing the observation then. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 25 00:33:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70E129864; Wed, 25 Jan 2017 00:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSLa4u2dzh9U; Wed, 25 Jan 2017 00:33:09 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891F012986E; Wed, 25 Jan 2017 00:33:08 -0800 (PST) X-AuditID: c1b4fb2d-a9bff70000007e3d-91-588862c028ad Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 03.AA.32317.0C268885; Wed, 25 Jan 2017 09:33:06 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 09:33:04 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "Jim Schaad" Thread-Topic: [core] OSCOAP's inner-blockwise Thread-Index: AQHScL8hm4bYm3XXc0WT0oYraDzgmqFGFyoAgAFd2gCAAXTFAA== Date: Wed, 25 Jan 2017 08:33:03 +0000 Message-ID: References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> <20170124111850.5ra2cnoqbw6ywgu5@hephaistos.amsuess.com> In-Reply-To: <20170124111850.5ra2cnoqbw6ywgu5@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <45FE19B344A9EA4AA70344AE3305FCC3@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7tO6hpI4Igw8bZC2WX3jOYrHv7Xpm i2n/zrBYrJ7+nc2BxWPjnOlsHlv332XyWLLkJ1MAcxSXTUpqTmZZapG+XQJXxqNbnAU73CuW XWpkb2A849rFyMkhIWAisfrLY+YuRi4OIYF1jBJverewgiSEBJYwSkx9WQRiswm4SDxoeMQE YosIFEqsvj+XHaSBWWAbUM2vt8wgCWEBHYmLN4+zdTFyABXpSlzvC4eod5KY9WUrC4jNIqAq sbhpM1gJr4CFxKXzfHB7W14fAxvDKeAqsbLhIRuIzSggJvH91BqwvcwC4hK3nsxngjhaQGLJ nvPMELaoxMvH/8BuFhXQk1j+fA1UXEmicckTVpBdzAKaEut36UOMsZZY8XsOI4StKDGl+yE7 iM0rIChxcuYTlgmM4rOQbJuF0D0LSfcsJN2zkHQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eX l1qyiREYhwe3/Nbdwbj6teMhRgEORiUe3g/Z7RFCrIllxZW5hxglOJiVRHjfx3VECPGmJFZW pRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cAodbfgVOl3tZNLZq6o 3XcxysCB6VvO9j07/lg8/Fgxty9b8viMwD2ePvdrfx68U3DqqOK+zNOfWNYJdSRyV87799V6 gg7j21/8L6vX7ZMJunVqTkV48Z7lKW3ONu3zHNRLBKrCm865X0qddjTquuLWn/MvtF03ft52 VY3jynqbluDz8SsZlrw9qMRSnJFoqMVcVJwIAMiQsaK/AgAA Archived-At: Cc: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 08:33:10 -0000 SGkgQ2hyaXN0aWFuLCBKaW0gYW5kIGFsbCwNCg0KSSBtYWtlIGFuIGF0dGVtcHQgdG8gc3VtbWFy aXNlIChhbmQgc2ltcGxpZnkpIHRoZSBkaXNjdXNzaW9uIG9mDQppbm5lci1ibG9ja3dpc2UuIFBs ZWFzZSBjb3JyZWN0IG1lIGlmIEnigJltIHdyb25nIG9yIG1pc3Npbmcgc29tZXRoaW5nLg0KDQpJ biBhZGRpdGlvbiB0byB0aGUgaW50ZWdyaXR5IG9mIGVhY2ggYmxvY2sgKHdoaWNoIGlzIGFscmVh ZHkgY292ZXJlZCBpbg0KLTAxKSB0aGVyZSBhcmUgdHdvIChyZWxhdGVkKSB0aGluZ3MgdGhhdCBt dXN0IGJlIHBvc3NpYmxlIHRvIHZlcmlmeToNCg0KMS4gdGhlIGludGVncml0eSBvZiBhIHJlcHJl c2VudGF0aW9uIHBhcnRpdGlvbmVkIGludG8gYmxvY2tzDQoyLiB0aGF0IGRpZmZlcmVudCBibG9j a3MgYmVsb25nIHRvIHRoZSBzYW1lIHJlcHJlc2VudGF0aW9uDQoNCg0KQm90aCB0aGVzZSByZXF1 aXJlbWVudHMgY2FuIGJlIGFkZHJlc3NlZCBieSB1c2luZyBhbiBpZGVudGlmaWVyIG9mIHRoZQ0K cmVwcmVzZW50YXRpb24sIHVuaXF1ZSBmb3IgdGhpcyBjb25zdGVsbGF0aW9uIG9mIGludm9sdmVk IG5vZGVzIChlLmcuDQp1bmlxdWUgd2l0aGluIHRoZSBzZXQgb2YgbWVzc2FnZXMgcHJvdGVjdGVk IHdpdGggZ2l2ZW4ga2V5cykuDQoNClRoaXMgaWRlbnRpZmllciBtdXN0IGJlIHByZXNlbnQgYW5k IGludGVncml0eSBwcm90ZWN0ZWQgaW4gdGhlIGJsb2Nrcw0KdHJhbnNmZXJyZWQsIGFuZCBtYXkg YmUgdXNlZCBhcyByZWZlcmVuY2UgZm9yIHZlcmlmeWluZyBpbnRlZ3JpdHkgb2YgdGhlDQp3aG9s ZSByZXByZXNlbnRhdGlvbiAod2hpY2ggYWxzbyBjYW4gYmUgdmVyaWZpZWQgYnkgdmVyaWZ5aW5n IGFsbCBibG9ja3MpLg0KV2l0aCB0aGlzIGlkZW50aWZpZXIsIHRoZSBjaGFpbmluZyBvZiBibG9j ayBpbnRlZ3JpdHkgY2FuIGJlIHJlbW92ZWQgdGh1cw0KcmVkdWNpbmcgc3RhdGUgYW5kIHNpbXBs aWZ5aW5nIHRoZSBwcm9jZWR1cmUgYXMgZGVzY3JpYmVkIGluIC0wMS4NCg0KRm9yIEdFVCBldGMu IEVUYWcgKOKAnEVUYWcyIikgZG9lcyB0aGUgam9iLCBidXQgZm9yIFBVVCBldGMuIHRoZXJlIGlz IGEgbmVlZA0KZm9yIGEgUmVxdWVzdC1UYWcgKOKAnEVUYWcxIikgb3B0aW9uIGFzIHByb3Bvc2Vk IGJ5IENocmlzdGlhbiBiZWxvdy4NCg0KIA0KUXVlc3Rpb25zOiANCg0KLSBJcyBzdWNoIGFuIG9w dGlvbiBzb21ldGhpbmcgdGhhdCBpcyBvZiBhbnkgb3RoZXIgdXNlIGJlc2lkZXMgcHJvdGVjdGlu Zw0KYmxvY2stdHJhbnNmZXI/DQoNCi0gSXMgdGhpcyBhIHNlcGFyYXRlIGRyYWZ0IG9yIHNvbWV0 aGluZyB0aGF0IHNob3VsZCB0byBiZSBpbnRlZ3JhdGVkIGludG8NCk9TQ09BUD8NCg0KT3RoZXIg Y29tbWVudHM/DQoNCkfDtnJhbg0KDQoNCg0KDQpPbiAyMDE3LTAxLTI0IDEyOjE4LCAiQ2hyaXN0 aWFuIEFtc8O8c3MiIDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4NCndyb3RlOg0KDQo+ SGVsbG8gR8O2cmFuLA0KPg0KPk9uIE1vbiwgSmFuIDIzLCAyMDE3IGF0IDAxOjI2OjQwUE0gKzAw MDAsIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+IFdpdGggdGhpcyBpbiBtaW5kLCBJIGRvbuKA mXQgc2VlIGEgcmVhc29uIHRvIGJpbmQgdGhlIGludGVncml0eSBvZiB0aGUNCj4+IGRpZmZlcmVu dCBibG9ja3MgdG8gZWFjaCBvdGhlciBhbmQgd2Ugc2hvdWxkIHJlbW92ZSB0aGUNCj4+dGFnLXBy ZXZpb3VzLWJsb2NrDQo+PiBmcm9tIHRoZSBleHRlcm5hbF9hYWQuDQo+DQo+UGVuZGluZyBKaW0n cyBvYmplY3Rpb25zLCBJJ2QgdGVudGF0aXZlbHkgbW92ZSBmb3J3YXJkIHRvIHRoZSBCbG9jazEN Cj5jYXNlOyBkcm9wcGluZyB0YWctcHJldmlvdXMtYmxvY2sgZnJvbSBleHRlcm5hbF9hYWRfcmVx IHdvdWxkIGFnYWluIG1ha2UNCj51cyBvcGVuIHRvDQo+DQo+ICAgICAgICBDbGllbnQgICAgICAg ICAgICAgIEZvZSAgICAgICAgIFNlcnZlcg0KPg0KPlBPU1QgImluY2FyY2VyYXRlIigxLzIpIC0t LT4gIC0tLT4NCj4gICAgICAgICAgICAgICAgICAgICAgIDwtLS0gIDwtLS0gICAyLjMxIENPTlRJ TlVFDQo+UE9TVCAidmFsamVhbiIoMi8yKSAgICAgLS0tPkANCj4gICAgICAgICAgICAgICAgICAg ICAgIDwtLS1SU1QNCj4NCj4oQ2xpZW50OiBPZGQsIGJ1dCBsZXQncyBnbyBvbiBhbmQgcHJvbW90 ZSBKYXZlcnQpDQo+DQo+UE9TVCAicHJvbW90ZSIoMS8yKSAgICAtLS0+ICAtLS0+DQo+ICAgICAg ICAgICAgICAgICAgICAgIDwtLS0gIDwtLS0gICAgMi4zMSBDT05USU5VRQ0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIEAgLS0tPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0t ICAgIDIuMDQgVmFsamVhbiBQcm9tb3RlZCENCj4NCj4oVGhlIEAgaW5kaWNhdGVzIGEgbWFsaWNp b3VzbHkgZGVsYXllZCAvIHdvcm1ob2xlZCBwYWNrYWdlIGFzIHVzZWQgaW4NCj5kcmFmdC1tYXR0 c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3JzLTAyKS4NCj4NCj5UbyBtaXRpZ2F0ZSB0aGF0IHdpdGhv dXQgbGlua2luZyBtZXNzYWdlcyBhZ2FpbiwgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcNCj5hZGRp dGlvbjoNCj4NCj4tLS0tLS0tLS0NCj4NCj4oaW4gc2VjdGlvbiA0LjMgIkNvQVAgb3B0aW9ucyIs IGZpZ3VyZSA0KQ0KPg0KPk9wdGlvbiBSZXF1ZXN0LVRhZyAoZGV0YWlscyBhcyBiZWxvdykgaXMg RToqIGFzIGFyZSB0aGUgYmxvY2sgb3B0aW9ucy4NCj4NCj4NCj4oaW4gc2VjdGlvbiA0LjMuMS4z ICJUaGUgQmxvY2sgT3B0aW9ucyIpDQo+DQo+VGhlIEJsb2NrIG9wdGlvbnMgKEJsb2NrMSwgQmxv Y2syLCBTaXplMSBhbmQgU2l6ZTIgKmFzIHdlbGwgYXMNCj5SZXF1ZXN0LVRhZyopIE1BWSBiZSBl aXRoZXIuLi4NCj4NCj4NCj4obmV3IHNlY3Rpb24gNi42KSBJbnRlZ3JpdHkgcHJvdGVjdGlvbiBm b3IgYEJsb2NrMWAgcmVxdWVzdHMNCj4NCj5XaGVuIGEgY2xpZW50IHVzZXMgaW5uZXIgYmxvY2sg b3B0aW9ucyB0byBzcGxpdCB1cCB0aGUgcGF5bG9hZCBvZiBhDQo+cmVxdWVzdCAodGhhdCBpcywg d2hlbmV2ZXIgdGhlIEJsb2NrMSBvcHRpb24gaXMgdXNlZCBhcyBhIGNsYXNzIEUNCj5vcHRpb24p LCB0aGUgY2xpZW50IE1VU1QgYWRkIGEgUmVxdWVzdC1UYWcgb3B0aW9uIHdpdGggdGhlIHNhbWUg dmFsdWUgdG8NCj5hbGwgdGhlIGJsb2NrcyBvZiBhIHNpbmdsZSByZXF1ZXN0LCBhbmQgdGhlIHNl cnZlciBNVVNUIHZlcmlmeSB0aGF0IHRoZQ0KPlJlcXVlc3QtVGFnIHZhbHVlcyBtYXRjaCBiZWZv cmUgYWN0aW5nIGF0b21pY2FsbHkgb24gc2V2ZXJhbCByZXF1ZXN0cy4NCj4NCj5bQXV0aG9yJ3Mg bm90ZTogSSdtIG9ubHkgbGltaXRpbmcgdGhlIHNlcnZlciB3L3J0IGF0b21pYyByZXF1ZXN0cywg YXMNCj50aGUgZGlmZmVyZW50IG1lc3NhZ2VzIGZyb20gYSBub24tYXRvbWljIG9wZXJhdGlvbiBk b24ndCAibWVldCIgaW4gdGhlDQo+c2VydmVyIGJlZm9yZSB0YWtpbmcgZWZmZWN0IG9uIHRoZSBy ZXNvdXJjZS4gVG8gbWl0aWdhdGUgd2hhdCB0aG9zZQ0KPndvdWxkIGRvIGluIGEgZGVsYXllZC1t ZXNzYWdlIHNjZW5hcmlvIGxpa2UNCj5kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3Jz LTAyIGZpZ3VyZSA0LCB0aGF0IGNvdWxkIGJlIGNvdmVyZWQNCj5ieSBJZi1NYXRjaCBhbmQgZmx1 Y3R1YXRpbmcgRVRhZ3MsIGJ1dCBub3Qgb24gYmxvY2t3aXNlIGxheWVyLl0NCj4NCj5UaGUgUmVx dWVzdC1UYWcgdmFsdWUgbXVzdCBiZSB1bmlxdWUgcGVyIHBhcnRpY2lwYW50IHdpdGhpbiB0aGUg c2VjdXJpdHkNCj5jb250ZXh0LiBUaGUgY2xpZW50IG1heSwgZm9yIGV4YW1wbGUsIHVzZSB0aGUg cGFydGlhbCBJViBvZiB0aGUgZmlyc3QNCj5ibG9jayBpdCBzZW5kcyBhcyB0aGUgcmVxdWVzdCdz IHRhZy4NCj4NCj5UaGUgcm9sZSBvZiB0aGUgUmVxdWVzdC1UYWcgaXMgc2ltaWxhciB0byB0aGUg RVRhZyBvZiByZXNwb25zZXMuIExpa2UNCj50aGUgRVRhZywgaXQgYWxsb3dzIHRoZSByZWNpcGll bnQgb2YgYmxvY2tzIHRvIHZlcmlmeSB0aGF0IHRob3NlIGJsb2Nrcw0KPmJlbG9uZyB0byB0aGUg c2FtZSBzdGF0ZSBvZiBhIHJlc291cmNlLiBVbmxpa2UgdGhlIEVUYWcsIHRoZXkgY2FuIG5vdCBi ZQ0KPnVzZWQgZm9yIGNhY2hpbmcsIGJlY2F1c2UgdGhlcmUgaXMgbm8gc2luZ2xlIGF1dGhvcml0 eSB0byBhc3NpZ24gdGhlbSB0bw0KPmEgYm9keS4gKFR3byBjbGllbnRzIHdvdWxkIG5vdCBhcnJp dmUgYXQgdGhlIHNhbWUgUmVxdWVzdC1UYWcgZm9yIHRoZQ0KPnNhbWUgYm9keSwgd2hpbGUgdGhl IG9yaWdpbiBzZXJ2ZXIgaXMgdGhlIGF1dGhvcml0eSBvbiBFVGFncyBmb3IgYSBnaXZlbg0KPnJl c291cmNlKS4NCj4NCj5UaGUgUmVxdWVzdC1UYWcgb3B0aW9uIGNhbiBiZSB1c2VkIG91dHNpZGUg b2YgT1NDT0FQIHByb3RlY3RlZCBtZXNzYWdlcw0KPnRvIHNlcGFyYXRlIEJsb2NrMSByZXF1ZXN0 cyBmcm9tIGEgc2luZ2xlIGVuZHBvaW50IHRvIHRoZSBzYW1lIHJlc291cmNlLg0KPkFzIHVzaW5n IGl0IHdvdWxkIGNhdXMgbWl4dXBzIG9mIGJsb2NrcyBvbiBhIHNlcnZlciB0aGF0IGRvZXMgbm90 DQo+dW5kZXJzdGFuZCBpdCwgaXQgaXMgbWFya2VkIGFzIENyaXRpY2FsLCBzYWZlLXRvLWZvcndh cmQsIGFuZCBwYXJ0IG9mDQo+dGhlIGNhY2hlIGtleS4gUHJveGllcyB0aGF0IHVuZGVyc3RhbmQg dGhlIEJsb2NrMSBhbmQgUmVxdWVzdC1UYWcNCj5vcHRpb25zIE1BWSBnaXZlIGl0IHNwZWNpYWwg dHJlYXRtZW50IGFuZCB1c2UgdGhlIGZ1bGwgYm9keSBvZiB0aGUNCj5yZXF1ZXN0IGFzIHRoZSBj YWNoZSBrZXkgaW5zdGVhZCwgYXMgdGhleSBhbHJlYWR5IG1heSB3aXRoIEJsb2NrDQo+b3B0aW9u cy4NCj4NCj4gICAgICAgKy0tLS0tKy0tLSstLS0rLS0tKy0tLSstLS0tLS0tLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0tKy0tLS0tLS0tLSsNCj4gICAgICAgfCBOby4gfCBDIHwgVSB8IE4gfCBSIHwg TmFtZSAgICAgICAgfCBGb3JtYXQgfCBMZW5ndGggfCBEZWZhdWx0IHwNCj4gICAgICAgKy0tLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0t LSsNCj4gICAgICAgfCBUQkQgfCB4IHwgICB8ICAgfCAgIHwgUmVxdWVzdC1UYWcgfCBvcGFxdWUg fCAgICAwLTggfCAobm9uZSkgIHwNCj4gICAgICAgKy0tLS0tKy0tLSstLS0rLS0tKy0tLSstLS0t LS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLSsNCj4NCj5bQXV0aG9yJ3Mgbm90 ZSBvbiBsZW5ndGg6IEFsbG93aW5nIGxlbmd0aCAwIHNvIHBlb3BsZSBjYW4gdXNlIHRoZQ0KPnBh cnRpYWwgSVYgdW5tb2RpZmllZCBhcyBvcHRpb24gdmFsdWUuIFRoYXQncyBzdGlsbCBhDQo+b25l LXRpbWUtcGVyLWNvbnRleHQgc2l0dWF0aW9uLl0NCj4NCj4NCj4oZm9yIDcgIlNlY3VyaXR5IENv bnNpZGVyYXRpb25zIiwgYWRkKQ0KPg0KPkFwcGxpY2F0aW9ucyB0aGF0IGFjY2VwdCBCbG9jazEg dHJhbnNmZXJzIGluIGEgbm9uLWF0b21pYyBmYXNoaW9uIG5lZWQNCj50byBiZSBhd2FyZSB0aGF0 IE9TQ09BUCBkb2VzIG5vdCBwcm92aWRlIHNlcXVlbmNlIGd1YXJhbnRlZXMgZm9yIHRoZQ0KPmlu ZGl2aWR1YWwgYmxvY2tzLCBhbmQgdGhhdCB1cGRhdGVzIG1heSBhcnJpdmUgbWFsaWNpb3VzbHkg ZGVsYXllZA0KPndpdGhpbiB0aGUgd2luZG93IHNpemUuIFdoZW4gdGhpcyBpcyBhIGNvbmNlcm4s IHRoZSBhcHBsaWNhdGlvbiBtaWdodA0KPndhbnQgdG8gc3dpdGNoIHRvIGF0b21pYyBtb2RlLCB3 aGVyZSB0aGUgaW50ZWdyaXR5IG9mIHRoZSB3aG9sZSByZXF1ZXN0DQo+Ym9keSBpcyBwcm92aWRl ZC4NCj4NCj4NCj4oZm9yIDkuMSAiQ29BUCBPcHRpb24gTnVtYmVycyBSZWdpc3RyeSIpDQo+DQo+ TnVtYmVyOiBUREIsIE5hbWU6IFJlcXVlc3QtVGFnLCBSZWZlcmVuY2U6IHRoaXMtZG9jdW1lbnQN Cj4NCj4tLS0tLS0tLS0NCj4NCj5JZiB5b3Ugd2FudCB0byBhY2NlcHQgdGhpcyBpbnRvIHRoZSBk cmFmdCwgSSdkIGJlIGhhcHB5IHRvIHBocmFzZSBpdCBhcw0KPmEgcHVsbCByZXF1ZXN0Lg0KPg0K Pg0KPkRvZXMgdGhpcyBzb3VuZCB2aWFibGUgdG8geW91Pw0KPg0KPkJlc3QgcmVnYXJkcw0KPkNo cmlzdGlhbg0KPg0KPg0KPlBTLiBzb3JyeSBmb3IgYW55IGNvbmZ1c2lvbiBjYXVzZWQgYnkgbXkg bGFzdCBtZXNzYWdlIG9uIHRoZSBzYW1lDQo+dGhyZWFkLCBteSBtYWlsIGNsaWVudCBtaXhlZCB1 cCB0aGUgaGF0cywgYW5kIGl0IHdhcyBzZW50IGZyb20gbXkgRnJlZQ0KPlNvZnR3YXJlIGRldmVs b3BlciBoYXQgYWRkcmVzcyA8Y2hyeXNuQGZzZmUub3JnPiBpbnN0ZWFkIG9mIG15IHdvcmsNCj5h ZGRyZXNzLg0KPg0KPi0tIA0KPkNocmlzdGlhbiBBbXPDvHNzICAgICAgICAgICAgICAgICAgICAg IHwgRW5lcmd5IEhhcnZlc3RpbmcgU29sdXRpb25zIEdtYkgNCj5mb3VuZGVyLCBzeXN0ZW0gYXJj aGl0ZWN0ICAgICAgICAgICAgIHwgaGVhZHF1YXJ0ZXI6DQo+bWFpbHRvOmMuYW1zdWVzc0BlbmVy Z3loYXJ2ZXN0aW5nLmF0ICB8IEFyYmVpdGVyZ2Fzc2UgMTUsIEEtNDQwMCBTdGV5cg0KPnRlbDor NDMtNjY0LTk3LTkwLTYtMzkgICAgICAgICAgICAgICAgfCBodHRwOi8vd3d3LmVuZXJneWhhcnZl c3RpbmcuYXQvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFUVTY4 NDc2NjE0DQoNCg== From nobody Wed Jan 25 11:12:23 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1CF129AF8; Wed, 25 Jan 2017 11:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 itgGc0NLzE0P; Wed, 25 Jan 2017 11:12:18 -0800 (PST) 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 948F6129B10; Wed, 25 Jan 2017 11:12:15 -0800 (PST) Received: from hebrews (64.134.140.0) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 11:35:15 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , =?utf-8?Q?'Christian_Ams=C3=BCss'?= References: <20170117124203.oh3hob567doz4p5l@hephaistos.amsuess.com> <20170124111850.5ra2cnoqbw6ywgu5@hephaistos.amsuess.com> In-Reply-To: Date: Wed, 25 Jan 2017 11:12:08 -0800 Message-ID: <039701d2773e$ee32a5a0$ca97f0e0$@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: AQKtQcEG0jyjNh7M+HUa8yeT6gtoTwL0dI4LAfJYplsB+6q91Z9c5nQw Content-Language: en-gb X-Originating-IP: [64.134.140.0] Archived-At: Cc: draft-ietf-core-object-security@ietf.org, core@ietf.org Subject: Re: [core] OSCOAP's inner-blockwise X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 19:12:20 -0000 Is this something to be done at the COSE or at the CoAP layer? > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: 25 January 2017 00:33 > To: Christian Ams=C3=BCss ; Jim Schaad > > Cc: draft-ietf-core-object-security@ietf.org; core@ietf.org; Francesca > Palombini > Subject: Re: [core] OSCOAP's inner-blockwise >=20 > Hi Christian, Jim and all, >=20 > I make an attempt to summarise (and simplify) the discussion of inner- > blockwise. Please correct me if I=E2=80=99m wrong or missing = something. >=20 > In addition to the integrity of each block (which is already covered = in > -01) there are two (related) things that must be possible to verify: >=20 > 1. the integrity of a representation partitioned into blocks 2. that = different > blocks belong to the same representation >=20 >=20 > Both these requirements can be addressed by using an identifier of the > representation, unique for this constellation of involved nodes (e.g. > unique within the set of messages protected with given keys). >=20 > This identifier must be present and integrity protected in the blocks > transferred, and may be used as reference for verifying integrity of = the > whole representation (which also can be verified by verifying all = blocks). > With this identifier, the chaining of block integrity can be removed = thus > reducing state and simplifying the procedure as described in -01. >=20 > For GET etc. ETag (=E2=80=9CETag2") does the job, but for PUT etc. = there is a need for > a Request-Tag (=E2=80=9CETag1") option as proposed by Christian below. >=20 >=20 > Questions: >=20 > - Is such an option something that is of any other use besides = protecting > block-transfer? >=20 > - Is this a separate draft or something that should to be integrated = into > OSCOAP? >=20 > Other comments? >=20 > G=C3=B6ran >=20 >=20 >=20 >=20 > On 2017-01-24 12:18, "Christian Ams=C3=BCss" = > wrote: >=20 > >Hello G=C3=B6ran, > > > >On Mon, Jan 23, 2017 at 01:26:40PM +0000, G=C3=B6ran Selander wrote: > >> With this in mind, I don=E2=80=99t see a reason to bind the = integrity of the > >>different blocks to each other and we should remove the > >>tag-previous-block from the external_aad. > > > >Pending Jim's objections, I'd tentatively move forward to the Block1 > >case; dropping tag-previous-block from external_aad_req would again > >make us open to > > > > Client Foe Server > > > >POST "incarcerate"(1/2) ---> ---> > > <--- <--- 2.31 CONTINUE > >POST "valjean"(2/2) --->@ > > <---RST > > > >(Client: Odd, but let's go on and promote Javert) > > > >POST "promote"(1/2) ---> ---> > > <--- <--- 2.31 CONTINUE > > @ ---> > > <--- 2.04 Valjean Promoted! > > > >(The @ indicates a maliciously delayed / wormholed package as used in > >draft-mattsson-core-coap-actuators-02). > > > >To mitigate that without linking messages again, I propose the > >following > >addition: > > > >--------- > > > >(in section 4.3 "CoAP options", figure 4) > > > >Option Request-Tag (details as below) is E:* as are the block = options. > > > > > >(in section 4.3.1.3 "The Block Options") > > > >The Block options (Block1, Block2, Size1 and Size2 *as well as > >Request-Tag*) MAY be either... > > > > > >(new section 6.6) Integrity protection for `Block1` requests > > > >When a client uses inner block options to split up the payload of a > >request (that is, whenever the Block1 option is used as a class E > >option), the client MUST add a Request-Tag option with the same value > >to all the blocks of a single request, and the server MUST verify = that > >the Request-Tag values match before acting atomically on several = requests. > > > >[Author's note: I'm only limiting the server w/rt atomic requests, as > >the different messages from a non-atomic operation don't "meet" in = the > >server before taking effect on the resource. To mitigate what those > >would do in a delayed-message scenario like > >draft-mattsson-core-coap-actuators-02 figure 4, that could be covered > >by If-Match and fluctuating ETags, but not on blockwise layer.] > > > >The Request-Tag value must be unique per participant within the > >security context. The client may, for example, use the partial IV of > >the first block it sends as the request's tag. > > > >The role of the Request-Tag is similar to the ETag of responses. Like > >the ETag, it allows the recipient of blocks to verify that those = blocks > >belong to the same state of a resource. Unlike the ETag, they can not > >be used for caching, because there is no single authority to assign > >them to a body. (Two clients would not arrive at the same Request-Tag > >for the same body, while the origin server is the authority on ETags > >for a given resource). > > > >The Request-Tag option can be used outside of OSCOAP protected > messages > >to separate Block1 requests from a single endpoint to the same = resource. > >As using it would caus mixups of blocks on a server that does not > >understand it, it is marked as Critical, safe-to-forward, and part of > >the cache key. Proxies that understand the Block1 and Request-Tag > >options MAY give it special treatment and use the full body of the > >request as the cache key instead, as they already may with Block > >options. > > > > = +-----+---+---+---+---+-------------+--------+--------+---------+ > > | No. | C | U | N | R | Name | Format | Length | = Default | > > = +-----+---+---+---+---+-------------+--------+--------+---------+ > > | TBD | x | | | | Request-Tag | opaque | 0-8 | (none) = | > > > > +-----+---+---+---+---+-------------+--------+--------+---------+ > > > >[Author's note on length: Allowing length 0 so people can use the > >partial IV unmodified as option value. That's still a > >one-time-per-context situation.] > > > > > >(for 7 "Security Considerations", add) > > > >Applications that accept Block1 transfers in a non-atomic fashion = need > >to be aware that OSCOAP does not provide sequence guarantees for the > >individual blocks, and that updates may arrive maliciously delayed > >within the window size. When this is a concern, the application might > >want to switch to atomic mode, where the integrity of the whole = request > >body is provided. > > > > > >(for 9.1 "CoAP Option Numbers Registry") > > > >Number: TDB, Name: Request-Tag, Reference: this-document > > > >--------- > > > >If you want to accept this into the draft, I'd be happy to phrase it = as > >a pull request. > > > > > >Does this sound viable to you? > > > >Best regards > >Christian > > > > > >PS. sorry for any confusion caused by my last message on the same > >thread, my mail client mixed up the hats, and it was sent from my = Free > >Software developer hat address instead of my work > >address. > > > >-- > >Christian Ams=C3=BCss | Energy Harvesting = Solutions GmbH > >founder, system architect | headquarter: > >mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 = Steyr > >tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > > | ATU68476614 From nobody Wed Jan 25 13:18:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D28129BFA; Wed, 25 Jan 2017 13:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 je_BjD6o-VIW; Wed, 25 Jan 2017 13:18:38 -0800 (PST) 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 628C6129C0C; Wed, 25 Jan 2017 13:18:37 -0800 (PST) Received: from hebrews (73.109.61.166) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 13:41:38 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , 'chrysn' References: <20170104091229.gx5zrcx7ahwt2mik@hephaistos.amsuess.com> <004301d267c8$84443b70$8cccb250$@augustcellars.com> <20170110070858.5fwye24j3mretgqm@hephaistos.amsuess.com> <20170117133845.j5klu7t5z42tqhmt@hephaistos.amsuess.com> In-Reply-To: Date: Wed, 25 Jan 2017 13:18:25 -0800 Message-ID: <03ac01d27750$95794f10$c06bed30$@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: AQJG/i1ruZbl3sV3WEzkHYqMMmSQqAJYNGPBAghQwnICYfdUagIfLpYkAoi0+b0BVSKizZ/6pY7Q Content-Language: en-gb X-Originating-IP: [73.109.61.166] Archived-At: Cc: draft-ietf-core-object-security@ietf.org, core@ietf.org Subject: Re: [core] OSCOAP: [...], sequence numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 21:18:50 -0000 I want to say that for the problem given, the only potential issue that = needs to be address is the question of replay of messages. That is if = the server crashes, loads up the advanced sequence number and continues = in a normal fashion, the only possible downside is that it will process = the same request a second time because it failed to notice that it had = already been processed. Given the jump forward in sequence numbers, the = server will never generate two messages with the same key, sequence = number pair. =20 This is not a problem for any idempotent message (i.e. a get). A new = response would be generated with a new sender sequence number and things = would continue as normal. The client would presumably ignore the = duplicate response as it would not have any outstanding requests with = that message id. Replay would only be an issue for those requests which = may cause a state change. In these cases, the client may have issued a = request to get a change accomplished and the change was done but the = notification was lost due to the crash. The state change could also = have been lost due to the crash. This means that the repeat option solution given below for replay = prevention need only to be use for those resources and requests that are = potentially a problem with replay and only for long enough to flush any = current messges that are active in the system. Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of G=C3=B6ran = Selander > Sent: 23 January 2017 07:49 > To: chrysn > Cc: draft-ietf-core-object-security@ietf.org; core@ietf.org > Subject: Re: [core] OSCOAP: [...], sequence numbers >=20 > Hi Christian, >=20 > Another take on the sequence numbers, inline. >=20 > On 2017-01-17 14:38, "chrysn" wrote: >=20 > >Hello G=C3=B6ran, > > > >On Fri, Jan 13, 2017 at 05:46:22PM +0000, G=C3=B6ran Selander wrote: > >> >In its recipient context, if the device only stores something like > >> >the end of its receive window on flash, it'll take the = communication > >>partner > >> >up to window-size failed attempts (which it might not even be > >> >allowed > >>to > >> >repeat) to get in the clear. > >> > >> But the replay window mechanism OSCOAP has inherited from DTLS and > >>ESP is sliding, so maintaining this state in the event of a = shutdown > >>would require writing the =E2=80=9Cright" edge of the window to = flash each > >>time a new highest sequence number has been received. I guess this = is > >>not desirable? > > > >My impression was that the requirements of OSCOAP are only that > >duplicate sequence numbers must not be accepted, and that all numbers > >much smaller than the highest seen one may be considered seen. ("much > >smaller" here means the window size, nothing should break if it's not > >implemented as a bitfield but for example as a sufficiently long list > >of numbers). Anyway, ... > > > >> However, in this case replay protection can be addressed with the > >>Repeat option defined in > >> https://tools.ietf.org/html/draft-mattsson-core-coap-actuators-02 > >> On reboot, a server must not accept the first message received in a > >>stored security context, but respond with a Repeat option asking = the > >>client if it recently made the request, and if so, to repeat the > >>request using its current sequence number, and include the same > >>Repeat parameter for server to verify freshness. > >> > >> (The client reception behaviour after reboot is straightforward = since > >>the client should only accept responses for requests made after > >>reboot.) > > > >..., I don't see how either of this would help in the situation I > >envisioned, which I might not have outlined to match my state of = mind, > >so I'd try again: > > > >* We have a server and a client. > >* Both can face unannounced shutdowns with no reserve to do a > > last-moment persistent write. > >* Neither have the capability to do persistent writes after every > > network transaction. WLOG I'll assume that they'll only write to > >flash > > every 1000 network transactions. > > > >(I'll focus on the server side of those constraints). > > > >* The client starts using its seqno 1. >=20 > This is the client sender seqno. >=20 > > The server accepts it, >=20 > This is the server recipient seqno. >=20 > >and marks > > all sequence numbers up to 1000 as seen in persistent memory, >=20 > The client should mark sender seqno up to 1000 as seen in persistent > storage. The server recipient seqno is not stored in persistent = memory. >=20 >=20 > > in order > > to function for 999 more transactions without flash writing. (It = does > > keep a more detailed state in RAM). > >* The server responds with its seqno 1, marking all seqnos up to 1000 > >as > > used. >=20 > This is the server sender seqno, all sequence numbers up to 1000 is = marked > as seen in persistent storage. The client recipient seqno is not = stored in > persistent memory. >=20 > > > >The server now faces a power outage as above, and the client (none = the > >wiser) asks again: > > > >* The client sends a request with seqno 2. The server discards it, > > because it was marked as "possibly already used". >=20 > Since the server has rebooted, it is aware of its ignorance of = sequence > numbers, e.g. using the ignorance state parameter previously described = in > security contexts existing before reboot. For requests to security = context > where it is ignorant, it includes in the OSCOAP response the Repeat = option > with random value. >=20 >=20 > >* The server responds with unproteted 4.01[1], because it stopped > > processing the request as per 6.3 par. 1. > > > >Even if the server used the actuators-02 Repeat option early enough = (ie. > >before OSCOAP validation kicks in and discards the message), it would > >still not tell the client that it needs to advance it sequence = number. > >(And if it were to tell that, it'd need to be tightly interleaved = with > >the OSCOAP verification, because the "advance your seqno" information > >could only be given to a client whose request passes all checks > >*except* the early Partial IV check.) >=20 >=20 > If the client can verify the response, it sends a new request with the = received > value of the Repeat option (and stepped sequence number). The client = does > not need to advance its sequence number, since there was no sequence > number advanced on the server side. >=20 > Instead the server only accepts the repeated OSCOAP request if it can = be > verified and the Repeat option has same value as that previously sent = in > response to the previous request. In this case the server updates the > sequence number in the recipient context to that of the verified = request. >=20 >=20 > So, in summary, the procedure of persistently storing a new starting = point for > sequence numbers in case of restart is only applied to sender sequence > numbers, and recipient sequence numbers are re-synchronised with a > challenge-response protocol. >=20 > Does this make more sense? >=20 > G=C3=B6ran >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jan 26 04:40:18 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B88612956B; Thu, 26 Jan 2017 04:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 993m1n--Vkbg; Thu, 26 Jan 2017 04:40:14 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78541129570; Thu, 26 Jan 2017 04:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0QCeAp6011085; Thu, 26 Jan 2017 13:40:10 +0100 (CET) Received: from [192.168.217.113] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3v8M2L4hVNz3Yss; Thu, 26 Jan 2017 13:40:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Thu, 26 Jan 2017 13:40:08 +0100 X-Mao-Original-Outgoing-Id: 507127204.634368-87f04a738a7ff40cfed8578166d0af5c Content-Transfer-Encoding: quoted-printable Message-Id: <25792A27-DA97-4310-8711-F069F90A7498@tzi.org> References: <148473976477.21258.889580327045922721.idtracker@ietfa.amsl.com> <5915a08817ca0c8c1f1a4b3415d3226d@xs4all.nl> To: draft-vanderstok-core-comi@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Core Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_WG_adoption_o?= =?utf-8?q?f_draft-vanderstok-core-comi-11=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 12:40:16 -0000 2017-01-25 has ended even on Baker Island, and we have mailing list = confirmation of this WG adoption. Authors: please resubmit as draft-ietf-core-comi-00. Gr=C3=BC=C3=9Fe, Carsten > On 18 Jan 2017, at 12:52, Carsten Bormann wrote: >=20 >> A new version of I-D, draft-vanderstok-core-comi-11.txt >> has been successfully submitted by Peter van der Stok and posted to = the >> IETF repository. >>=20 >> @chairs, this is the version to confirm the adoption over the mailing = list. >=20 > Indeed. >=20 > In Seoul, we had in-room consensus to adopt this draft as a WG = document, filling in the remaining gap of the COMI/COOL series of = documents. We said we needed to confirm that consensus on the mailing = list, but didn=E2=80=99t do that immediately, and then there was a new = version impending. >=20 > That new version is now available. So if you do not agree with the = in-room consensus that we had in Seoul to adopt this as a WG document, = please speak up until the end of 2017-01-25. (If you weren=E2=80=99t in = the room but do agree with adopting this document, you can also tell = us.) From nobody Thu Jan 26 07:49:35 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 914CA1296F2; Thu, 26 Jan 2017 07:49:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148544577456.26947.10271383240902039379.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 07:49:34 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-comi-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:49:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoAP Management Interface Authors : Peter van der Stok Andy Bierman Michel Veillette Alexander Pelov Filename : draft-ietf-core-comi-00.txt Pages : 42 Date : 2017-01-26 Abstract: This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access data resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CoMI extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-comi/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-comi-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 30 06:13:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9E51294A0; Mon, 30 Jan 2017 06:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3K0NdY4-RFH; Mon, 30 Jan 2017 06:12:58 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919DC128874; Mon, 30 Jan 2017 06:12:57 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-f0-588f49e77c8d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 59.6B.16488.7E94F885; Mon, 30 Jan 2017 15:12:55 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 30 Jan 2017 15:12:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fHDSNa3NtZfuuGRfSStgsmjWFoqm48txwhLMPhWAXr4=; b=QED1PuCi07zGUcMZEAeNaT7QdWIigz2Qu38ksWoabCE3jxk6K8SbX4HZlyQjVssZp/R+k47WivaW2WkuviNtA8APiEhN3cV5RHgcQTNfty0ZcfkAucu05QGS/4tF+LkTFIdSCdrQWIDfor/BUNSWFdU9q0Z6cf8x09GFrnDzxUg= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2538.eurprd07.prod.outlook.com (10.168.129.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 30 Jan 2017 14:12:52 +0000 Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([10.168.129.17]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([10.168.129.17]) with mapi id 15.01.0888.015; Mon, 30 Jan 2017 14:12:52 +0000 From: Francesca Palombini To: "core@ietf.org" , "core-chairs@ietf.org" Thread-Topic: OSCOAP interop Thread-Index: AdJ7AjwWfpUhEI5pR2KZP1Baw5GM3Q== Date: Mon, 30 Jan 2017 14:12:52 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.36.157.200] x-ms-office365-filtering-correlation-id: 5ec066a2-c09d-46a0-c8dc-08d4491a146f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2538; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2538; 7:1Q6fl0B9kH6NtaOa4NTs4ClJhzEIJNKbotcOIp//McR2Z/RKm/5nE0bv7/l2eZMOIFKzkX51N6DdHfdiyGa8ad0/oYYQWf7BlAUj+PX+9hxpAlnuuCKQbZZFLb6FbzZ63v+cOtqtqVhyC5D2/XJiXKg4LE5tpfFkXfq1SRX47KQrxIDW+RLYEo22RAFB9xvuH9wzAlmOXk2Wv06+rQsX1ehlKfydOGmxpJLnn6bkt4/vFM4pY1JcmPt9picu+rNa84y5rvwtRw9kpJuN4izrsRJ/dEQ8QdNrF4qXyVnJEwEeHZe3mehzPY1sC/TPlrEmhQTCsKOYGXpWxwNr2OJvIUyC2fsB0zuZHn/BaeMiko21/GGL06C8DlVeZMXm581K00mJ2IFdOXIGvS5UFOCvi8u9fxjLcnvOJK29whQMZn26+RM52Oc032TInPQgxmOV0DxmSW8nQ3Y3kkXi6j6J4A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:HE1PR0701MB2538; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2538; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(189002)(101416001)(107886002)(19609705001)(81166006)(8676002)(8936002)(106356001)(92566002)(68736007)(3480700004)(189998001)(2900100001)(105586002)(450100001)(97736004)(33656002)(81156014)(122556002)(5001770100001)(2906002)(54356999)(221733001)(2501003)(5660300001)(6306002)(54896002)(66066001)(53936002)(99286003)(9686003)(7116003)(55016002)(50986999)(25786008)(38730400001)(3660700001)(77096006)(3280700002)(6506006)(6436002)(6116002)(86362001)(7906003)(7696004)(7736002)(790700001)(102836003)(3846002)(236005)(74316002)(606005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2538; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25396351F307018EACD79A48984B0HE1PR0701MB2539_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 14:12:52.5859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2538 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2J7uO5zz/4Ig4VfVCy2bbzAZrHv7Xpm ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlbHnyk7XggWxFy+7kBsb5Ul2MnBwSAiYSG44dY+9i 5OIQEljHKPFn+QpWCOcEo8TU31fYQBwWgV5miafv+xlBWoQEZjJJ3LoQDmGfYpRoeMQBYrMJ 2EhcePieFcQWEQiR2P+kkQXEFhYQl1g7oYkZIi4jce34dXYIW09i5s+LYDUsAqoSP76eA5vP K5Ag0XZsPhuIzSggK/GlcTVYLzPQnFtP5jNBnC0gsWTPeWYIW1Ti5eN/rBD1yRJXbvexQ8SV JHY0zYaq8ZVomvAaKu4vMWXiMxaQxyQE+lgk3s74yQaRyJe48LUTqshb4mVnPytUEZNE08v3 UEUyEtPedTBBJN6zSpw8dJIZEhSpEsvXtjJCvCwlcfdKJ5QtI/Hizl5WiBfyJbYv38wG8aag xMmZT1gmMKrNQvLdLCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMosWpxcW5 6UZGeqlFmcnFxfl5enmpJZsYgUnn4JbfVjsYDz53PMQowMGoxMO7wbovQog1say4MvcQowQH s5II7ySL/ggh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUa GCUbDz3TW3c7d80ynbszdFhdd4n7lDK+UYqzV5c0kCl0UD/K+H1R0H/WA1OvzWG64DHXb0MX xxTFrZpprMbcwtrNPSZ3u23WS3i6CWo7XD7r8eRMx5d6k7nPf/7bsMpm80LGiQvVo2p/1Jtc W6XlanDqkek2xdvye0KLZtUtTLp3NOi7Xnl6uhJLcUaioRZzUXEiAERYSjo2AwAA Archived-At: Subject: [core] OSCOAP interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 14:13:00 -0000 --_000_HE1PR0701MB25396351F307018EACD79A48984B0HE1PR0701MB2539_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello CoRE members, The first remote interop for OSCOAP (https://github.com/core-wg/oscoap) wil= l take place Monday 27th February at 8:00 (CET). We are aiming for 3 hours, but we will be flexible based on participants av= ailability. A first draft for the tests specification is available here: https://ericss= onresearch.github.io/OSCOAP/ Don't hesitate to send comments, feedback, ideas. If you are interested in participating, as implementers or as observers, pl= ease get in contact with me, and I'll keep you updated. Thanks, Francesca --_000_HE1PR0701MB25396351F307018EACD79A48984B0HE1PR0701MB2539_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello CoRE members,

 

The first remote interop for OSCOAP (https://github.com/core-wg/oscoap) will take place Monday 27th February at 8:00 (CET).

We are aiming for 3 hours, but we will be flexible b= ased on participants availability.

 

A first draft for the tests specification is availab= le here: https://ericssonrese= arch.github.io/OSCOAP/

Don’t hesitate to send comments, feedback, ide= as.

 

If you are interested in participating, as implement= ers or as observers, please get in contact with me, and I’ll keep you= updated.

 

Thanks,

Francesca

--_000_HE1PR0701MB25396351F307018EACD79A48984B0HE1PR0701MB2539_-- From nobody Mon Jan 30 06:41:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC81294D8 for ; Mon, 30 Jan 2017 06:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YICGub-AgdPb for ; Mon, 30 Jan 2017 06:41:25 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D47129494 for ; Mon, 30 Jan 2017 06:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U2NA3awUfCvfQPDCoCf4dDGwAiTGSoBqSrvEAZJZAfg=; b=sIvfaC54VgbkMy+x+YAHHnI49PV3TvILwfpM0vbnw7ZdEWUdHFymzqdzB7Nm7xq35z2nn7G60SnGKvA5WezonKIU5tlUQ2UvAWXXJ+rZ+4IMojmcazM6eikxN+xLWr3xIBVAdpxBJrEm5r/KnQqw6b3ga0e2xnSPL/Fy/yu3qOU= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Mon, 30 Jan 2017 14:41:22 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0874.019; Mon, 30 Jan 2017 14:41:22 +0000 From: Michel Veillette To: Ana Minaburo , Core , peter van der Stok Thread-Topic: [core] Confirmable message Thread-Index: AQHSdh3SsxRAinkUHkmQU77SwTunNqFRH3Bw Date: Mon, 30 Jan 2017 14:41:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 8e270730-744b-40c9-83c4-08d4491e0f5a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2305; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 7:g5u3h/4ufWyfRa5UJRgd80fiZTyoEitMpAl7sEVOtaDXXfPW9HgAwm99uwvSdmI5/GUpnRcklZrfIVJ2EH59ScEhmcqZNDKH5U0Cd86ch9nIuy0pKYDf4MxRDPI3T0I8yNJ7KQXbiUK12qjqOUdLBQKgYJzq7pctvjnrwxab1fGF3E6aGyl5ypDpYMsyrWJAe2JoR1FwcTHrUsKx73A/q23noSJe/7CGt/uOtp46jCWM27vU8ibd0L6zkl7k4/3MXK+Czpo/SPNQIR9wMCQs+QEv2HKXAlyQ/QfsBNsKn+skdJsHN8axJaqBWggKK85Oyo6vazfM6LsroxQO7FuU98TZXoHVjWbmUem0VdYLsPok+nZcW/9GetlZYuuotn5R7lkyh1Wzxi0p6y1CS24JcwC4TzmHsxLXNcXJF1oBOde9adMAIju17mLAgT8fFmYJ/hfZxG8Z89+nW9KiTiEx2Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558021)(6072148); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39840400002)(39450400003)(189002)(199003)(377454003)(74316002)(3280700002)(66066001)(107886002)(102836003)(3846002)(9686003)(236005)(6306002)(54896002)(53936002)(92566002)(2906002)(10710500007)(7736002)(97736004)(7110500001)(189998001)(6116002)(790700001)(86362001)(7906003)(68736007)(5001770100001)(3660700001)(2950100002)(8936002)(7696004)(2420400007)(76176999)(15650500001)(33656002)(6436002)(606005)(101416001)(105586002)(106356001)(106116001)(38730400001)(229853002)(2900100001)(55016002)(99286003)(81156014)(25786008)(77096006)(5660300001)(122556002)(8676002)(81166006)(54356999)(6506006)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308C3D1CB60B90FDAFFB0E5FE4B0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 14:41:22.0378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Subject: Re: [core] Confirmable message X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 14:41:27 -0000 --_000_BN6PR06MB2308C3D1CB60B90FDAFFB0E5FE4B0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5hDQoNCkluIENvTUksICJOT04gY29uZmlybWFibGUgbWVzc2FnZXMiIGFyZSBzdXBwb3J0 ZWQgdGhvdWdoIG5vdGlmaWNhdGlvbnMuDQpJbiBzZWN0aW9uIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29taS0wMCNzZWN0aW9uLTUuNS4xLCB0aGUgc2VudGVu Y2UNCiJUbyBjaGVjayB0aGF0IHRoZSBjbGllbnQgaXMgc3RpbGwgYWxpdmUsIHRoZSBzZXJ2ZXIg TVVTVCBzZW5kIGNvbmZpcm1hYmxlIG5vdGlmaWNhdGlvbnMgb25jZSBpbiBhIHdoaWxlLiINCmlt cGxpY2l0bHkgY29uZmlybSB0aGlzIG9wdGlvbi4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQpGcm9t OiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5hIE1p bmFidXJvDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDE3IDM6NDIgQU0NClRvOiBDb3Jl IDxjb3JlQGlldGYub3JnPjsgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw+ DQpTdWJqZWN0OiBbY29yZV0gQ29uZmlybWFibGUgbWVzc2FnZQ0KDQpIaSBQZXRlcg0KSW4gdGhl IGRyYWZ0LCBkcmFmdC12YW5kZXJzdG9rLWNvcmUtY29taS0xMS50eHQsICB5b3UgbWVudGlvbiB0 aGF0IGEgY29uZmlybWFibGUgbWVzc2FnZSBpcyBtYW5kYXRvcnkgZm9yIGNhcnJ5IENvTWkgcmVx dWVzdHMuIFdlIHVuZGVyc3RhbmQgdGhhdCBmb3Igc2V0dGluZyBhIHZhbHVlIGl0IGlzIG5lY2Vz c2FyeSB0byBiZSBzdXJlIHRoYXQgdGhlIGluZm9ybWF0aW9uIGhhcyBiZWVuIGNvcnJlY3RseSBy ZWNlaXZlZC4gSW4gTFBXQU4gV0cgd2UgYXJlIHN0dWR5aW5nIHRoZSB3YXkgdG8gY29tcHJlc3Mg aGVhZGVyIGFuZCByZWR1Y2UgdHJhZmZpYyBvbiB2ZXJ5IGNvbnN0cmFpbnQgbGlua3MuIERvIHlv dSB0aGluaywgaXQgY291bGQgYmUgcG9zc2libGUgdG8gc3VwcHJlc3MgdGhpcyBjb25zdHJhaW50 IGFuZCBhbGxvdyB0aGUgdXNlIG9mIE5PTiBjb25maXJtYWJsZSBtZXNzYWdlcyA/DQoNClRoYW5r cw0KDQpBbmENCg== --_000_BN6PR06MB2308C3D1CB60B90FDAFFB0E5FE4B0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmdtYWlsLWls DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLWlsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5IaSBBbmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SW4gQ29NSSwgJnF1b3Q7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPk5PTiBjb25maXJtYWJsZSBtZXNzYWdlcyZxdW90OyBhcmUg c3VwcG9ydGVkIHRob3VnaA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+bm90aWZpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SW4gc2VjdGlvbiA8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvbWkt MDAjc2VjdGlvbi01LjUuMSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLWNvbWktMDAjc2VjdGlvbi01LjUuMTwvYT4sIHRoZSBzZW50ZW5jZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7VG8gY2hlY2sgdGhhdCB0aGUgY2xpZW50IGlzIHN0 aWxsIGFsaXZlLCB0aGUgc2VydmVyIE1VU1Qgc2VuZCBjb25maXJtYWJsZSBub3RpZmljYXRpb25z IG9uY2UgaW4gYSB3aGlsZS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmlt cGxpY2l0bHkgY29uZmlybSB0aGlzIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk1pY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGNvcmUgW21haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuYSBNaW5hYnVybzxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDE3IDM6NDIgQU08YnI+DQo8Yj5U bzo8L2I+IENvcmUgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7OyBwZXRlciB2YW4gZGVyIFN0b2sgJmx0 O3N0b2tjb25zQHhzNGFsbC5ubCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIENvbmZp cm1hYmxlIG1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+SGkgUGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkluIHRoZSBkcmFm dCwmbmJzcDtkcmFmdC08c3BhbiBjbGFzcz0iZ21haWwtaWwiPnZhbmRlcnN0b2s8L3NwYW4+LTxz cGFuIGNsYXNzPSJnbWFpbC1pbCI+Y29yZTwvc3Bhbj4tY29taS0xMS50eHQsJm5ic3A7Jm5ic3A7 eW91IG1lbnRpb24gdGhhdCBhIGNvbmZpcm1hYmxlIG1lc3NhZ2UgaXMgbWFuZGF0b3J5IGZvciBj YXJyeSBDb01pIHJlcXVlc3RzLiBXZSB1bmRlcnN0YW5kIHRoYXQNCiBmb3Igc2V0dGluZyBhIHZh bHVlIGl0IGlzIG5lY2Vzc2FyeSB0byBiZSBzdXJlIHRoYXQgdGhlIGluZm9ybWF0aW9uIGhhcyBi ZWVuIGNvcnJlY3RseSByZWNlaXZlZC4gSW4gTFBXQU4gV0cgd2UgYXJlIHN0dWR5aW5nIHRoZSB3 YXkgdG8gY29tcHJlc3MgaGVhZGVyIGFuZCByZWR1Y2UgdHJhZmZpYyBvbiB2ZXJ5IGNvbnN0cmFp bnQgbGlua3MuIERvIHlvdSB0aGluaywgaXQgY291bGQgYmUgcG9zc2libGUgdG8gc3VwcHJlc3Mg dGhpcyBjb25zdHJhaW50DQogYW5kIGFsbG93IHRoZSB1c2Ugb2YgTk9OIGNvbmZpcm1hYmxlIG1l c3NhZ2VzID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkFuYTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR06MB2308C3D1CB60B90FDAFFB0E5FE4B0BN6PR06MB2308namp_-- From nobody Mon Jan 30 23:55:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D821293FF for ; Mon, 30 Jan 2017 23:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 mg-jSMr8rSXz for ; Mon, 30 Jan 2017 23:54:58 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A491120726 for ; Mon, 30 Jan 2017 23:54:58 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id evuv1u00A4K0fSy01vuvGZ; Tue, 31 Jan 2017 08:54:56 +0100 Received: from AMontpellier-654-1-247-29.w92-133.abo.wanadoo.fr ([92.133.18.29]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 31 Jan 2017 08:54:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 31 Jan 2017 08:54:55 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: Ana Minaburo , Core Subject: Re: [core] Confirmable message X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 07:55:00 -0000 Hi Ana, Why not solve this in the gateway and elide the Con flag? Removes the problem of not LPWAN aware clients contacting LPWAN servers. Peter Michel Veillette schreef op 2017-01-30 15:41: > Hi Ana > > In CoMI, "NON confirmable messages" are supported though > notifications. > > In section > https://tools.ietf.org/html/draft-ietf-core-comi-00#section-5.5.1 [1], > the sentence > > "To check that the client is still alive, the server MUST send > confirmable notifications once in a while." > > implicitly confirm this option. > > Regards, > > Michel > > FROM: core [mailto:core-bounces@ietf.org] ON BEHALF OF Ana Minaburo > SENT: Tuesday, January 24, 2017 3:42 AM > TO: Core ; peter van der Stok > SUBJECT: [core] Confirmable message > > Hi Peter > > In the draft, draft-vanderstok-core-comi-11.txt, you mention that a > confirmable message is mandatory for carry CoMi requests. We > understand that for setting a value it is necessary to be sure that > the information has been correctly received. In LPWAN WG we are > studying the way to compress header and reduce traffic on very > constraint links. Do you think, it could be possible to suppress this > constraint and allow the use of NON confirmable messages ? > > Thanks > > Ana > > Links: > ------ > [1] https://tools.ietf.org/html/draft-ietf-core-comi-00#section-5.5.1 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jan 31 07:29:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9371B12987F for ; Tue, 31 Jan 2017 07:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRAJYxRrVOeQ for ; Tue, 31 Jan 2017 07:29:13 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB521298C1 for ; Tue, 31 Jan 2017 07:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iqQRWiM0I8nWhUJl520GQsr9cpMTkw1Ijgq+6dnBpRI=; b=BHKYUP1M/UdQ+WLiI83J/rV9l9V8I3SF8qokoRVs3RXXlW2rt0nuFF6HEMcHEioPx2spNTRQQ0AZ6zS9EFo63DgBStLxayQp6r+iTO8C1xyb4JdEjRGFJwCun8sfPsRgazuQWcXAiqaAdgqUDbJyCPnhH76isqazRlOSLL4S+6M= Received: from VI1P122CA0005.EURP122.PROD.OUTLOOK.COM (129.75.142.79) by HE1P122MB0042.EURP122.PROD.OUTLOOK.COM (129.75.140.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.14; Tue, 31 Jan 2017 15:29:10 +0000 Received: from DB3FFO11FD045.protection.gbl (2a01:111:f400:7e04::187) by VI1P122CA0005.outlook.office365.com (2603:10a6:820:1c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12 via Frontend Transport; Tue, 31 Jan 2017 15:29:10 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.247.132 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD045.mail.protection.outlook.com (10.47.217.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Tue, 31 Jan 2017 15:29:09 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 15:29:08 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0860.026; Tue, 31 Jan 2017 15:29:08 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AdJ71Z2t7xvTLii1QoWlumXEa75yfQ== Date: Tue, 31 Jan 2017 15:29:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.102] X-MS-Office365-Filtering-Correlation-Id: 7a17da26-e7e1-48ca-834b-08d449ede6d9 Content-Type: multipart/alternative; boundary="_000_c017f36ba69c4379b9368c32c26fb10cHE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0172.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(2980300002)(85714005)(199003)(374574003)(55904004)(189002)(54896002)(606005)(81156014)(81166006)(84326002)(450100001)(53936002)(6916009)(189998001)(66066001)(107886002)(69596002)(8676002)(110136003)(626004)(68736007)(5660300001)(55016002)(24736003)(38730400001)(15395725005)(6306002)(97736004)(966004)(512954002)(7696004)(8936002)(790700001)(86362001)(108616004)(16297215004)(54356999)(7736002)(7906003)(236005)(260700001)(102836003)(2906002)(1720100001)(356003)(105586002)(6116002)(33646002)(3846002)(2900100001)(106466001)(92566002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P122MB0042; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD045; 1:d3NxGMxcygBMH7WDbvMCclTn31dgwCue8+s1aowDHsTIDW6vbLvilKaPSrweKB+eBREOEMt5Tbit7OSaJhKwwOBtCdE1Qo/fiHr6tgo4um/l2GQQHmvMrhwAN7Gnx0LVqRr/N1aM5JIot6beWpMieprxew33VYUIxog+IAQ48WyZ99EUX43WI7O27FeRACmtBKCCf27JFKGYVQX3Txi6ndIOPya9LFEfy8JU8rywxEqtX2LZoNJa/vThmqrZpiTJuJiEufZ/1BZtVpnXpoyyMkw3x3GGZCS7FDwK3+j7fQc6qlLkC8VvNagvxgbsl3TO8PSThE9F+SeflV/oHKUmFeQmrwItuLT7/DEnyDBcGxZSDuzeMEa2SHCZPava+f2r6JW3+siVPNwhVuclXCActVUF0yf4Is/ITDcHJin2fQUyZaw/H3XNURz5q7+Wp88nr+ekjSDsOU9TzrCD9m34ek2gCjRc5Ry3X5e/48IulPmeAKwqf1u4BfOE5+n+luNK3C03DLZ8gx39Oht1MANBLA== X-CrossPremisesHeadersPromoted: DB3FFO11FD045.protection.gbl X-CrossPremisesHeadersFiltered: DB3FFO11FD045.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1P122MB0042; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0042; 3:e0IbcS0a0g9kDQB3oxRSQNgfcxb7VN6FSqS9zSSPSHcFxQIq4mOikO7xNEbxVQe6eL+l08ZFORXSClZ0o6jSeQxprBKUNN36DIrhjhVHx8bwSiKiGOVWWrVZFSoi0Zbe62d0Firufn+fXvu0KMLMQTAeBzo9JJ53QU1xK0ZD28yG/oEke+gHdRxQ6qsuZ0rkSDNNPlDgc9ZKm0JF+QQ3xDPJIQYVSE57iT9ClGrdbf2Uoug57J37ZS0a6OnbVhRUKG3jCjf1i5uSmmgLZ5dCkWX21D9CZ8KiRZaXori9vKKvVxY5IIG84nYGBhgCDZoXmOuSu2E5UeUtZLnxHAMewRbpb0c/gvmfR584VJnVLkZP0sppDGn4jVofBA8K6G3D; 25:v+RPjVIlky2Qy+7TDe23RJyjqg9B6vT5TauCOFmjfCJu1HBqJ8LcZ0s692QqwQSgV07t3kfrrBHrVhUvyF9JzlyyGRBrzLrQVRtPasGOaykCROyOu/5hekTVsCvUEE6nONA02kqeYX9YP+n64+ynbzG63phY6qG21du0p5RQTVOONUPVZlOk9CU7oqKGuJHZiVHu4tjXSbC9uy0G3r1pJkISSTA69DeenmZkGfu4iMAgME6csoOcL3OfkeRRHNveJdvytforl/ToZ+4uOvup292UTFULTqoB5rQBZsJE0lA12ywYBUHzlTX+YgEUDQekWOMz69w4EbbK4e7weSXVpWUaCpSRrX+1wmhjE45Oh4aegBctyS7hSE7QLhn5FxwqnY1cag+bIGoR74eEEgR5w5g+sMabP6X6PcL5zjWZwNA2I26Km2Yk0Gsd/ow+3FKCNlsOOVOXzO0e4Cio34O4ug== X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0042; 31:co4C4KC9evKpDfbw+mfzYj4yFsOD03z9TJiNSDP8by/o4XOkUAhfMRj0C96/rJEDAI10XeiupazSmzWBRnD00NPnY5at70BtPPeR5fUielJfAwO9knUZUTefeMb0Cu362uLoMrVvHvHRKJLPoGjAZ3LmdSAbYdfgX2THW53FXPaLhFb2LOXg+labrLuTHqlgRbokDAldc8Okca3nR+sz2uQcAxxhXUiNgnqQrJynqNolwKJZ6Z5w5r3MfTTCFaab7jxnYaLExss2cVvl+mPfmZTR+36SSp6DdygPAY9O7hc=; 20:hVh0vFp/nt0MnojCeUiBhC+B++OzU+wsugEollLcdDwYavQZ6xWRNewWIFVW/FjKqlghZ5bKyHC5lLT2Iz+hNXPwSXQ7JQWFabN+G4mWU1v+ysx+9Vmf932gaIv9qlumyJfxQMoy+x1uNNFEV8HrusS7KUSZ1j4N4NCisyqP2/nDexqMIRDyUykDi2gOcvQ29IqAsoB6KZLnvEemY4pyd3BzAvDPwBzx/hRBjpfuluFd6eUkxqjMfpnmIgaDPWE3vh8iyyOATLJxmsWwCjz8CWXwoQoiB55MZl8/2zDtNqlwCrg7MqpKmsdYbuq5ZDnKy2bwN12e9IktPdq/2GxZpzBlPqA4mI4yKUOHrauz0N6Tq88mQhWRVbLRkMvo46fhYG0N/O1vpVjEkqKjj1ZrjIWq6E9WYWXxyvJ/oEyBrFEg7gIl6xMrKoq/X8d6svkJvTrHob0N+kiIkBClIl4VK2CpiblrDguZ/Ergd8kL8NGxKSeGoUFCKmZHUyy5J3Ni X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(185212123834332)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(13018025)(13016025)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:HE1P122MB0042; BCL:0; PCL:0; RULEID:; SRVR:HE1P122MB0042; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0042; 4:OkKm+V5otXKTjkQg4XDZf9+PZOptMgsQKljDpyMP3SUPGZINwehdYzzUN0P4ZZxzAtphLlRAdYsYi5djyLMuA1XVYgUHThDmaavYcmTXzU/tpMUi5kuoMlPK1lDEqiLZ1RaeQnqMi4pKNJacx2qUVvLqIORTqKDzO+w/GbZX1HwsABDzn9zh+l3ARu8Ks4vVjD5hA8F/OKJ5Ia/o6fAza1fJZ0CvlcjA1VR6GW/KdRpD6q1jcaZ/bax6Hve3jcezaabC/pbEyzYjdWLZNtwDNpslil6LxktaRSDH8V3Qm0miKtgQPjQ90fFbBjZPWNwTw7Er22EDDcvZbHUpuFYAI9CChb5um96RYHYL5rUhqbQCzAk0jscT9K6+C6/FZ9Qi9+sY+fOZA3qojfL0WCi/QxqqBbb7NKAP3weeqaSUu8Ar5FAdgkWPVtG3GOVNEQoMLVUufBfpeuf45Gz5mbinukomJiLMpD97LjWRm2bpPxRYHfHvi6hr/FlScNddaQyzZ/skcDEEpu/WkhCfvyAywsgViY2aqyoNODuzZ/zReXg034tY5d1wuslkQPXDJDmUcBb4fI4/yfkJwbSxhTxZeZ/I6KozbhbHOlBWecya4psiGH4pU4m6OTWGcAvjtUPPrZ8jjFWrW1t8CQA/eUbmgOpRTuL7MVviIGLzydOeGwRSD5yPtxFHgzUowqf4Ts33/RDKO5DEUPgbQwojQyvA69igOtWd+77RS4zaM8TMSiI= X-Forefront-PRVS: 0204F0BDE2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P122MB0042; 23:X0xYuaRDURybpA5CVUnS8MdATmzdadSUFRbzc4RzA?= =?us-ascii?Q?Ra3NCzIjGxrJGJ3x/l644kIg294AFnF89SnDO2Aq/aSHb1GlBX5ML9vjkKBa?= =?us-ascii?Q?cXBMRIhOQ1tuoTEAa8boz2x9YV5V8fbMxVf1thQhg+T4sNRHPnqWvxRWZ7rm?= =?us-ascii?Q?rLbic3pI9J3KD1FkbaYV6v8n6utJ+cWyVWHixDOBD2xF3opTM/+qpYfQyji9?= =?us-ascii?Q?heV/6kyTS/iuxnfovjTJdXJXlM9YnYLDZVgQk6YsKp8ws8yqXLQRjIieYRQP?= =?us-ascii?Q?7ostAB26vkO1kiJWU4osN/2tz/JjvkYFxSu1a+1BiDf+bxBEhqx/RTPBvEFj?= =?us-ascii?Q?HzPmHbLgMM3LBlkz0ETsza1UQucsS1WupvElGrwVBDzyGKw+MCjMN51bjkhY?= =?us-ascii?Q?YEDzT7sv3SlxcoYBW+NFRlm7NK0RMkqtrDShj4vWEwTH6+Lpt2MP7vRN1oBt?= =?us-ascii?Q?G+92daSWlKBp7BZ9bCyM9e/jAdZH6f8CSrWMCIkenmDpjrnJ6a5O7NW4WcAQ?= =?us-ascii?Q?Gp/ubg7liw3qHJKJMAyet6BMJT9t1kbGyVZyp0bFC9cDYVBq4V7l7AxHGaTv?= =?us-ascii?Q?cwnMdCOmmrtwU1ap+HklqWm/fyaUsuUNhgV3i0algIT4pK74KT4GDylYwQ+d?= =?us-ascii?Q?YKKMSHtMya7XqPVBXSw1mlCoN/09pDnvcHtC/KTxXw9/7EPxYZWz/IA628Jm?= =?us-ascii?Q?c9Dst2Y75Iv42ryZ9H1Gvd1S31OjSsQXKeq6euE+kUOUnQPoDNUWcuoSRkIm?= =?us-ascii?Q?eeJMQo1KVyhPgBi5w/Cb8TSudjl1miPn6Xs9Y3nbzIGxXv8WwEoSXJpb/pEe?= =?us-ascii?Q?K0J3DWomjpHyJ7ddB+vTNYbjw4ptym8TLMv1xawbe07BN7jCKLKt9hUwRkdT?= =?us-ascii?Q?OzivyvJL2ljJh5dJmtKBU35XQPwAalrMEsofMgpgRjL1F0sKiaYazOGTQNfO?= =?us-ascii?Q?yJDvcTCGSKwDfDEoc6b2D6Hor2tE1FG/qV1jFF0QakZeQWYHGwYxxVpBLGeS?= =?us-ascii?Q?adIh5PXJ7nBT5imttm1ic8f8z/lpdY7BtTO8NFGuWN9ON6s0S5Hod0UEypOx?= =?us-ascii?Q?uSF0O8mZvXGY/nneGunsOrM/i2LDtVzBjDcyg+gaXO11b9b5sOjMtM+NLWOQ?= =?us-ascii?Q?AV8DHnhDwIevOcGz+Tu/iZu3PLQCS+TL2eXTbaepWSYHD092OunWnk+xAxwT?= =?us-ascii?Q?0nQcc77jYGaXEKq87DHv7pxVhKOGqS/EnrD/RkK3o24LVQFbOUJ00BEeE3Ov?= =?us-ascii?Q?BvJSNaTUE49tYZDvsp3w95OJosCjJUI07a/p3JLGIcHsKVKpvzNY5LngdeMJ?= =?us-ascii?Q?AgS/W/ypEOpIrfjcjMJ3XUu9s1PD6ruxMhVuUKdAGxUeAL1KHJFlHRVEDaBS?= =?us-ascii?Q?NI7bu1t+MeCkKLSFZsE1IxQIBGY8Fh54xxexbJVzlKlgTotCZiia/ZWd5yJB?= =?us-ascii?Q?+/alG2akg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0042; 6:UOAr5RjgViMxHLV8Hjn9mcN6yXV6lNdZjYWv2qV4k08d1mUpftU2etmR0E0JclKqPtUbR98K39YrB3aiZLt5mCuP/yuU5wL0y7SLA4XqlXWgPX5t2cUwmMhPc6aZFsGHzWcJuHaESeWlP3Gc1Bp1Dm5w+4Md7VaW1Zv97VEiL+lxWuQecD10n6X4JDyItTTO2Lr6NvPohmZxdjT/YgoqN2lZSiB+Hmsb2ZnfAFLoH1e5p3QJc8Fh1K7PfuHOHgwuyiBRC6dNWtZaL8Y7TTP/1l3AMXmFiTctphTAzpv4NDHlM24yYeFwd4FEAnS1JW8fXEuTA0oSia/WIUd/Wuj/pan6HWmOJmcak/VEEExaSlynGIuYFr9Kgcxz4mQNqPCaTTan//joQ+P6ug+ftEb+RyRMw4HU9I3vPi46mLaMWxMVpQv2U0xBYElRDjVzSv9J; 5:XR7hcRen/5pDcJ9w6G+/NkYKFWWtWD2gOl0lpZF6lsT1/up7FbkBZwhliY3B1YtP/5Rtw2U2V5YQooXsyMH3kvw9QpHN1iMPU1JkXpCbllmlB658eDYs6b1bC9e17o0zLmyjXScf255R8xo7rYRw+Q==; 24:swwiASU1CQsjw0MsLgBcCPi/m1XbIT8a7PJpOomQXKvuds2VnZKjthH+5qEjYUF8SlicjQVNUO22YVgO0BLOo66NvZFN059/uFVxGlYkcSc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0042; 7:k/Pi3Zr4VSCrtpkEuYFXTW+l0fXCy1OuSqF55mRV9Lqe5Bj1eBtZdcigI6wn0q3m1x1JDztcT2SCZGSXhZP3GxWlQ16JBpTqelstandCoUyGKOFyyjgaW0n8oTmzTGb9CmCoXLBMu3kqaqP05Fl+M7ixAdbAWC6Fd+r7LMazpHACpYJ86EtA4DvqzE19s1FDzbNuSZduC48v1A61o1m1zp4tziNzaX9zcXnNRG4OvNCa2GkzWXMH5VzqG0P05FojL9G7C1mHMm4NJOfemfZp72C1WM9LHKme4PNWd2Aucb/hewC4cLTb/rbsXT7wKkUJlDM/vA/F2v9+94Gr6tkqhrQmWERybwzOmgUaR/rvdtRMKz5Pqm0C7d4KUkGF+dIkKFuSPcovvEDFZltK6vpk6z+3wksbZ8HmKPm6v010RfMs27HLlgyGeiLtCQWucvEv2fF3g3GreA1DddIEcB7f7/iZNU8vgLdMfYYw/pz4Nk2A3ZSOmxb0ce6jZQcDwoMkTHyncWQ4xVNWr0lhrhZ4kozE4iOQrv4KjHGpsQO1RUMBKiYH9Jp/tO93oEdfOOkf X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2017 15:29:09.3925 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P122MB0042 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR9001MB0170.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.102 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: HE1P122MB0042.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:29:17 -0000 --_000_c017f36ba69c4379b9368c32c26fb10cHE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, the following question came up in a system design that uses CoAP. What if a= client asks for a resource (e.g. using query arguments) that would get pro= hibitively large, such that the server can't serve it? Looking at CoAP code= 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too La= rge" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to = only pertain to the request payload size - not the response payload size. I= n both the HTTP and CoAP cases. So it seems unsuitable for the situation I = describe above. 4.00 Bad Request seems unsuitable because the syntax / formatting of the Co= AP request is fine. 5.00 seems possible if we take the perspective that it= is the server's fault that it cannot produce the requested (large) respons= e payload. Some background discussion is also on http://stackoverflow.com/questions/15= 192477/http-status-code-when-single-request-asks-for-too-large-resource-or-= too-many-of which suggests to use 403 / 4.03 for this case. Which seems not= ideal as well because it tells the client that its authorization is insuff= icient which is not the case here. Does anyone have a view on this? best regards Esko Dijk ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_c017f36ba69c4379b9368c32c26fb10cHE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

the following question came up in a system design th= at uses CoAP. What if a client asks for a resource (e.g. using query argume= nts) that would get prohibitively large, such that the server can't serve i= t? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large"= per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only = pertain to the request payload size – not the response payload size. = In both the HTTP and CoAP cases. So it seems unsuitable for the situation I= describe above.

 

4.00 Bad Request seems unsuitable because the syntax= / formatting of the CoAP request is fine.  5.00 seems possible if we = take the perspective that it is the server's fault that it cannot produce t= he requested (large) response payload.

 

Some background discussion is also on http://stackoverflow.com/questions/15192477/http-status-code-when-single-re= quest-asks-for-too-large-resource-or-too-many-of which suggests to use = 403 / 4.03 for this case. Which seems not ideal as well because it tells th= e client that its authorization is insufficient which is not the case here.

 

Does anyone have a view on this?

 

best regards

 

Esko Dijk

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_c017f36ba69c4379b9368c32c26fb10cHE1PR9001MB0170MGDPHGem_-- From nobody Tue Jan 31 07:52:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC412999D for ; Tue, 31 Jan 2017 07:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBpZVeqy3GOQ for ; Tue, 31 Jan 2017 07:52:46 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462681294AA for ; Tue, 31 Jan 2017 07:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12034; q=dns/txt; s=iport; t=1485877966; x=1487087566; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=OcU2QHikUzuTFOyoX2SvXKRXOrW11uaEs1gzu8g8vuU=; b=ZwYjZ6H9GkzZOGa/4Y3h88u2cHxv1aSfClzsc9tdF0sDyOUnB87u2UmC VvzTh5uPpEkrgz7DBO5aaNI529T0NN1wepOJKx4fKSxdJpzVxvykcliwq /cxUFMJCYi0o8xUf1SNxrLVgljiyT4jpwKvM73Vx5Ys++MTVrBW4xiPUW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgCLsZBY/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9kYYEJB4NPigmSBoJjjSWFK4INLoV0AhqCGD8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBAQQjClwCAQgRAwECKwICAjAdCAIEARKJbg6rdoIlK4sHAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZLggWCaoQ2NoJmLoIxBZtXAYZmixeBeVOEQolqkn4?= =?us-ascii?q?BHziBSxVLAYYodQEBhxyBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208,217";a="379517172" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2017 15:52:45 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0VFqjR7014951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 15:52:45 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 10:52:44 -0500 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 10:52:44 -0500 From: "Padmanabhan Ramanujam (pramanuj)" To: "Dijk, Esko" , "core (core@ietf.org)" Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AQHSe9oP9vZoMPKG9kKefNTz8GF65w== Date: Tue, 31 Jan 2017 15:52:43 +0000 Message-ID: <8220E33E-87F5-47F7-98E6-C7A3534601A2@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.33.167] Content-Type: multipart/alternative; boundary="_000_8220E33E87F547F798E6C7A3534601A2ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:52:48 -0000 --_000_8220E33E87F547F798E6C7A3534601A2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgcmlnaHQgZXJyb3Igc2hvdWxkIHN0aWxsIGJlIDQuMDMgRm9yYmlkZGVuLCBh cyBpdCBpcyB0aGUgY2xpZW50IHdoaWNoIHNob3VsZCBtb2RpZnkgaXRzIHJlcXVlc3QsIHdpdGgg c29tZXRoaW5nIGluIHRoZSBwYXlsb2FkIHRvIHByb3ZpZGUgc3VmZmljaWVudCBpbmRpY2F0aW9u IHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgcmVzcG9uc2Ugd2lsbCBub3QgZml0LiBJbiB0aGUgcGFy dGljdWxhciBjYXNlIHdvdWxkIHVzYWdlIG9mIGJsb2Nrd2lzZSBvcHRpb24gc29sdmUgdGhlIHBy b2JsZW0uDQoNClJlZ2FyZHMsDQpwYWRkeQ0KDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiAiRGlqaywgRXNrbyIgPGVza28uZGlqa0BwaGlsaXBzLmNvbT4N CkRhdGU6IFR1ZXNkYXksIDMxIEphbnVhcnkgMjAxNyBhdCAyMDo1OQ0KVG86ICJjb3JlIChjb3Jl QGlldGYub3JnKSIgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbY29yZV0gQ29BUCByZXNwb25z ZSBjb2RlIGluIGNhc2Ugb2YgInJlc3BvbnNlIHBheWxvYWQgdG9vIGxhcmdlIiA/IDQuMTM/DQoN CkRlYXIgYWxsLA0KDQp0aGUgZm9sbG93aW5nIHF1ZXN0aW9uIGNhbWUgdXAgaW4gYSBzeXN0ZW0g ZGVzaWduIHRoYXQgdXNlcyBDb0FQLiBXaGF0IGlmIGEgY2xpZW50IGFza3MgZm9yIGEgcmVzb3Vy Y2UgKGUuZy4gdXNpbmcgcXVlcnkgYXJndW1lbnRzKSB0aGF0IHdvdWxkIGdldCBwcm9oaWJpdGl2 ZWx5IGxhcmdlLCBzdWNoIHRoYXQgdGhlIHNlcnZlciBjYW4ndCBzZXJ2ZSBpdD8gTG9va2luZyBh dCBDb0FQIGNvZGUgNC4xMyAoUmVxdWVzdCBFbnRpdHkgVG9vIExhcmdlIDsgb3IgaW4gdXBkYXRl ZCBIVFRQIGphcmdvbiAiUGF5bG9hZCBUb28gTGFyZ2UiIHBlciBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTYuNS4xMSApOyBpdCBzZWVtcyB0byBvbmx5IHBlcnRh aW4gdG8gdGhlIHJlcXVlc3QgcGF5bG9hZCBzaXplIOKAkyBub3QgdGhlIHJlc3BvbnNlIHBheWxv YWQgc2l6ZS4gSW4gYm90aCB0aGUgSFRUUCBhbmQgQ29BUCBjYXNlcy4gU28gaXQgc2VlbXMgdW5z dWl0YWJsZSBmb3IgdGhlIHNpdHVhdGlvbiBJIGRlc2NyaWJlIGFib3ZlLg0KDQo0LjAwIEJhZCBS ZXF1ZXN0IHNlZW1zIHVuc3VpdGFibGUgYmVjYXVzZSB0aGUgc3ludGF4IC8gZm9ybWF0dGluZyBv ZiB0aGUgQ29BUCByZXF1ZXN0IGlzIGZpbmUuICA1LjAwIHNlZW1zIHBvc3NpYmxlIGlmIHdlIHRh a2UgdGhlIHBlcnNwZWN0aXZlIHRoYXQgaXQgaXMgdGhlIHNlcnZlcidzIGZhdWx0IHRoYXQgaXQg Y2Fubm90IHByb2R1Y2UgdGhlIHJlcXVlc3RlZCAobGFyZ2UpIHJlc3BvbnNlIHBheWxvYWQuDQoN ClNvbWUgYmFja2dyb3VuZCBkaXNjdXNzaW9uIGlzIGFsc28gb24gaHR0cDovL3N0YWNrb3ZlcmZs b3cuY29tL3F1ZXN0aW9ucy8xNTE5MjQ3Ny9odHRwLXN0YXR1cy1jb2RlLXdoZW4tc2luZ2xlLXJl cXVlc3QtYXNrcy1mb3ItdG9vLWxhcmdlLXJlc291cmNlLW9yLXRvby1tYW55LW9mIHdoaWNoIHN1 Z2dlc3RzIHRvIHVzZSA0MDMgLyA0LjAzIGZvciB0aGlzIGNhc2UuIFdoaWNoIHNlZW1zIG5vdCBp ZGVhbCBhcyB3ZWxsIGJlY2F1c2UgaXQgdGVsbHMgdGhlIGNsaWVudCB0aGF0IGl0cyBhdXRob3Jp emF0aW9uIGlzIGluc3VmZmljaWVudCB3aGljaCBpcyBub3QgdGhlIGNhc2UgaGVyZS4NCg0KRG9l cyBhbnlvbmUgaGF2ZSBhIHZpZXcgb24gdGhpcz8NCg0KYmVzdCByZWdhcmRzDQoNCkVza28gRGlq aw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5 IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRp bmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBl LW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_8220E33E87F547F798E6C7A3534601A2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8E09D68FEF73B94BACC6BB8B1ED65351@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgcmln aHQgZXJyb3Igc2hvdWxkIHN0aWxsIGJlIDQuMDMgRm9yYmlkZGVuLCBhcyBpdCBpcyB0aGUgY2xp ZW50IHdoaWNoIHNob3VsZCBtb2RpZnkgaXRzIHJlcXVlc3QsIHdpdGggc29tZXRoaW5nIGluIHRo ZSBwYXlsb2FkIHRvIHByb3ZpZGUgc3VmZmljaWVudCBpbmRpY2F0aW9uIHRvIHRoZSBjbGllbnQg dGhhdCB0aGUgcmVzcG9uc2Ugd2lsbCBub3QgZml0LiBJbiB0aGUgcGFydGljdWxhcg0KIGNhc2Ug d291bGQgdXNhZ2Ugb2YgYmxvY2t3aXNlIG9wdGlvbiBzb2x2ZSB0aGUgcHJvYmxlbS4gPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5wYWRkeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmNvcmUgJmx0O2NvcmUtYm91bmNl c0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O0RpamssIEVza28mcXVvdDsgJmx0O2Vz a28uZGlqa0BwaGlsaXBzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgMzEgSmFu dWFyeSAyMDE3IGF0IDIwOjU5PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtjb3JlIChjb3JlQGlldGYu b3JnKSZxdW90OyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W2Nv cmVdIENvQVAgcmVzcG9uc2UgY29kZSBpbiBjYXNlIG9mICZxdW90O3Jlc3BvbnNlIHBheWxvYWQg dG9vIGxhcmdlJnF1b3Q7ID8gNC4xMz88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBm b2xsb3dpbmcgcXVlc3Rpb24gY2FtZSB1cCBpbiBhIHN5c3RlbSBkZXNpZ24gdGhhdCB1c2VzIENv QVAuIFdoYXQgaWYgYSBjbGllbnQgYXNrcyBmb3IgYSByZXNvdXJjZSAoZS5nLiB1c2luZyBxdWVy eSBhcmd1bWVudHMpIHRoYXQgd291bGQgZ2V0IHByb2hpYml0aXZlbHkgbGFyZ2UsIHN1Y2ggdGhh dCB0aGUgc2VydmVyIGNhbid0IHNlcnZlIGl0PyBMb29raW5nIGF0IENvQVAgY29kZSA0LjEzIChS ZXF1ZXN0DQogRW50aXR5IFRvbyBMYXJnZSA7IG9yIGluIHVwZGF0ZWQgSFRUUCBqYXJnb24gJnF1 b3Q7UGF5bG9hZCBUb28gTGFyZ2UmcXVvdDsgcGVyIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3MjMxI3NlY3Rpb24tNi41LjExIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM3MjMxI3NlY3Rpb24tNi41LjExPC9hPiApOyBpdCBzZWVtcyB0byBvbmx5IHBl cnRhaW4gdG8gdGhlIHJlcXVlc3QgcGF5bG9hZCBzaXplIOKAkyBub3QgdGhlIHJlc3BvbnNlIHBh eWxvYWQgc2l6ZS4gSW4gYm90aCB0aGUgSFRUUCBhbmQgQ29BUCBjYXNlcy4gU28gaXQgc2VlbXMg dW5zdWl0YWJsZSBmb3IgdGhlIHNpdHVhdGlvbiBJIGRlc2NyaWJlIGFib3ZlLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjQuMDAgQmFkIFJlcXVlc3Qgc2VlbXMgdW5zdWl0YWJsZSBiZWNhdXNl IHRoZSBzeW50YXggLyBmb3JtYXR0aW5nIG9mIHRoZSBDb0FQIHJlcXVlc3QgaXMgZmluZS4gJm5i c3A7NS4wMCBzZWVtcyBwb3NzaWJsZSBpZiB3ZSB0YWtlIHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGl0 IGlzIHRoZSBzZXJ2ZXIncyBmYXVsdCB0aGF0IGl0IGNhbm5vdCBwcm9kdWNlIHRoZSByZXF1ZXN0 ZWQgKGxhcmdlKSByZXNwb25zZSBwYXlsb2FkLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNv bWUgYmFja2dyb3VuZCBkaXNjdXNzaW9uIGlzIGFsc28gb24gPGEgaHJlZj0iaHR0cDovL3N0YWNr b3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy8xNTE5MjQ3Ny9odHRwLXN0YXR1cy1jb2RlLXdoZW4tc2lu Z2xlLXJlcXVlc3QtYXNrcy1mb3ItdG9vLWxhcmdlLXJlc291cmNlLW9yLXRvby1tYW55LW9mIj4N Cmh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvMTUxOTI0NzcvaHR0cC1zdGF0dXMt Y29kZS13aGVuLXNpbmdsZS1yZXF1ZXN0LWFza3MtZm9yLXRvby1sYXJnZS1yZXNvdXJjZS1vci10 b28tbWFueS1vZjwvYT4gd2hpY2ggc3VnZ2VzdHMgdG8gdXNlIDQwMyAvIDQuMDMgZm9yIHRoaXMg Y2FzZS4gV2hpY2ggc2VlbXMgbm90IGlkZWFsIGFzIHdlbGwgYmVjYXVzZSBpdCB0ZWxscyB0aGUg Y2xpZW50IHRoYXQgaXRzIGF1dGhvcml6YXRpb24NCiBpcyBpbnN1ZmZpY2llbnQgd2hpY2ggaXMg bm90IHRoZSBjYXNlIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgYW55b25lIGhh dmUgYSB2aWV3IG9uIHRoaXM/IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iZXN0IHJlZ2FyZHM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXNrbyBEaWprIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwv c3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Z3JheSI+VGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90 ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlDQogaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcs IGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlc3Ryb3kgYWxsDQogY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8220E33E87F547F798E6C7A3534601A2ciscocom_-- From nobody Tue Jan 31 09:22:46 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27EA129515 for ; Tue, 31 Jan 2017 09:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THmszcUjXqfc for ; Tue, 31 Jan 2017 09:22:42 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0550612948C for ; Tue, 31 Jan 2017 09:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0VHMax0023438; Tue, 31 Jan 2017 18:22:36 +0100 (CET) Received: from [192.168.217.124] (p5DC7E5A6.dip0.t-ipconnect.de [93.199.229.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vCY3w5VpRz3ZVL; Tue, 31 Jan 2017 18:22:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Tue, 31 Jan 2017 18:22:36 +0100 X-Mao-Original-Outgoing-Id: 507576155.993258-6a8d3f494a320df22a29b91c41adb30d Content-Transfer-Encoding: quoted-printable Message-Id: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> References: To: "Dijk, Esko" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 17:22:44 -0000 Hi Esko, good question. I agree that 4.13 does not apply, as it is about the request payload. If you consider management of resource consumption to be part of = authorization, 4.03 is somewhat plausible, but it might set the client = up on a goose chase for more permissions. 5.00 of course always is possible, as are 5.01 or 5.03. 5.03 has = max-age (retry-after) semantics that maybe don=E2=80=99t fit very well = here; it is really meant for temporary conditions. There is little guidance in RFC 7230 (or RFC 2616) when to use 501 = (which our 5.01 references); it only gets specific about using it as a = response when the request method is not implemented at all. So, no, I don=E2=80=99t think we have a good fit here. Is the use case = important enough that we want to invent a new status code? Otherwise, = 4.03 seems to be as good to me as 5.01. Gr=C3=BC=C3=9Fe, Carsten > On 31 Jan 2017, at 16:29, Dijk, Esko wrote: >=20 > Dear all, > =20 > the following question came up in a system design that uses CoAP. What = if a client asks for a resource (e.g. using query arguments) that would = get prohibitively large, such that the server can't serve it? Looking at = CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon = "Payload Too Large" per = https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only = pertain to the request payload size =E2=80=93 not the response payload = size. In both the HTTP and CoAP cases. So it seems unsuitable for the = situation I describe above. > =20 > 4.00 Bad Request seems unsuitable because the syntax / formatting of = the CoAP request is fine. 5.00 seems possible if we take the = perspective that it is the server's fault that it cannot produce the = requested (large) response payload. > =20 > Some background discussion is also on = http://stackoverflow.com/questions/15192477/http-status-code-when-single-r= equest-asks-for-too-large-resource-or-too-many-of which suggests to use = 403 / 4.03 for this case. Which seems not ideal as well because it tells = the client that its authorization is insufficient which is not the case = here. > =20 > Does anyone have a view on this?=20 > =20 > best regards > =20 > Esko Dijk=20 > =20 >=20 > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jan 31 22:56:46 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006D8129969 for ; Tue, 31 Jan 2017 22:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug-7l3OG3g7e for ; Tue, 31 Jan 2017 22:56:42 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00063.outbound.protection.outlook.com [40.107.0.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580B9129967 for ; Tue, 31 Jan 2017 22:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XqN0ZLd9oX9LDjAbvDLw10wsIcd7dRuTnryvdBODAZg=; b=Ir3eY9Rv00p6CaFQ2VyGKVFEfRbz5dptVMq+p2I17KnFV0luQLTka7u5HZ/NeH8+PZGW1S5vbSg+og2/mtLDDEV8xVxigrc915FtGo7248BEpHaNQfYyKuQLIPyLInvWltXJmBoeF7m1oQW1fvyVnUJ7RMvuPo8+6J+EPQ1t+NI= Received: from VI1PR0802MB2383.eurprd08.prod.outlook.com (10.172.14.135) by VI1PR0802MB2384.eurprd08.prod.outlook.com (10.172.14.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 1 Feb 2017 06:56:38 +0000 Received: from VI1PR0802MB2383.eurprd08.prod.outlook.com ([10.172.14.135]) by VI1PR0802MB2383.eurprd08.prod.outlook.com ([10.172.14.135]) with mapi id 15.01.0860.026; Wed, 1 Feb 2017 06:56:38 +0000 From: Lauri Piikivi To: Carsten Bormann Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AQHSe+ambm/FOu6tBUOVMgNcjJP/vaFTuNyA Date: Wed, 1 Feb 2017 06:56:38 +0000 Message-ID: References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> In-Reply-To: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Lauri.Piikivi@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.140.96.140] x-ms-office365-filtering-correlation-id: ae8c23a1-c6ca-4617-e9df-08d44a6f786c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR0802MB2384; x-microsoft-exchange-diagnostics: 1; VI1PR0802MB2384; 7:vWFruUc6WAD/QOqGWSnUCJPf48qcus+BPA3IqFWg5fHfDJk99adHf6q9eTYcvButoa8PgIh18xhVK4NLgwNFdCk7+/ylsnk4RIA2pqgUW5ykklrdBsjtk92TD+FMaN8JJQoXYo22tsqV4A48djbK/DZFJJwiCxAuMBB2iJtnkuKT/G1udMkjg31B37+RAq/NS3T1FCSSit/iLX6LHXQAoAFp0lvPlQPB3kZkk/lZ7/WKRXK9iVEAk9P2oQcfpULw7Y7ej0WgUUzbtvLrSOPeRWEb/WT1GOU8k2xcwqvHUcOm7jc+noO4VZdDiUnQFswMwsqVG3RLbnV5A6nhZhQWp8ZxRu+20SxDs4QyMfobznZlng46W1c9c2/DxQkS9T5mujfK/Mo9s8aZ3qZmmoNdzy4dVdWU/MDMyGm6CY7SqLGRo1lnw6PZMXMtSAEd2EVpE7B1+8HEGQvUg8aVZTwyqyMWFBffEse9KpCZejAm7BHTr0KDnMh6j4wqwdO2unAq++1uI1Mi+usNvPY/Sh6yg3GJkEA5K8FTfg/OtknqDEyycw1bWwYUL7uJ5qosppus x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(185212123834332)(260087099026482); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:VI1PR0802MB2384; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0802MB2384; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(199003)(40434004)(85714005)(24454002)(374574003)(189002)(55904004)(53754006)(229853002)(6306002)(8676002)(6486002)(7736002)(305945005)(3280700002)(99286003)(25786008)(53936002)(6506006)(77096006)(6436002)(6512007)(66066001)(5660300001)(81156014)(8936002)(81166006)(54906002)(105586002)(83716003)(101416001)(50986999)(86362001)(106116001)(6916009)(106356001)(15395725005)(82746002)(110136003)(2950100002)(38730400001)(2900100001)(122556002)(102836003)(36756003)(2906002)(4326007)(1720100001)(54356999)(92566002)(3846002)(966004)(97736004)(3660700001)(189998001)(5890100001)(33656002)(6116002)(68736007)(76176999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0802MB2384; H:VI1PR0802MB2383.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <98CFBECC44860C4590C29B086D667E11@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 06:56:38.6520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2384 Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 06:56:45 -0000 SGkgYWxscywNCg0KSSB0aGluayB0aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIGZ1cnRoZXIgY29k ZXMuIFdlIGZhbGwgYmFjayBvbiBIVFRQIHNwZWNzLCBhbmQgdGhvc2UgYXJlIGJhc2ljYWxseSBt YWRlIGZvciB1c2VyIGludGVyYWN0aW9uIHdpdGggYSBsaW1pdGxlc3Mgc2VydmVyLiBUaGV5IGFy ZSBub3QgYSBnb29kIG1hdGNoIGZvciBJb1Qgd2hlcmUgYXBwcyBjb21tdW5pY2F0ZSwgb2Z0ZW4g Y29uc3RyYWluZWQgYXBwcy4gVGhlcmUgaXMgc3BhY2UgZm9yIGRlZmluaW5nIG1hY2hpbmUgdW5k ZXJzdGFuZGFibGUgY29kZXMsIG9yIGV4dGVuZCBoZWFkZXJzIG9yIHNvbWV0aGluZyBzbyB0aGF0 IHdlIGNhbiBhY3R1YWxseSBjb21tdW5pY2F0ZSB3aGF0IHRoZSBpc3N1ZSBpcy4NCg0KSSBwcm9w b3NlIGEgYml0IG9mIGluZm8gZ2F0aGVyaW5nLCBJICBpbWFnaW5lIHRoZXJlIGFyZSBtb3JlIHNp bWlsYXIga2luZHMgb2Ygc2l0dWF0aW9ucyB3aGVyZSBIVFRQIGhhcyBub3QgaGFkIHRoZSByaWdo dCBjb2RlLg0KDQpJdCBpcyBhIGJpdCBtb3JlIHdvcmssIGJ1dCBpbiBteSBvcGluaW9uIG5lZWRl ZCBpbiBtaWQtdG8tbG9uZyB0ZXJtIGZvciBpbnRlcm5ldCBvZiB0aGluZ3MuDQoNCkJSDQotIExh dXJpDQoNCj4gT24gMzEgSmFuIDIwMTcsIGF0IDE5OjIyLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZz4gd3JvdGU6DQo+DQo+IEhpIEVza28sDQo+DQo+IGdvb2QgcXVlc3Rpb24uDQo+DQo+ IEkgYWdyZWUgdGhhdCA0LjEzIGRvZXMgbm90IGFwcGx5LCBhcyBpdCBpcyBhYm91dCB0aGUgcmVx dWVzdCBwYXlsb2FkLg0KPg0KPiBJZiB5b3UgY29uc2lkZXIgbWFuYWdlbWVudCBvZiByZXNvdXJj ZSBjb25zdW1wdGlvbiB0byBiZSBwYXJ0IG9mIGF1dGhvcml6YXRpb24sIDQuMDMgaXMgc29tZXdo YXQgcGxhdXNpYmxlLCBidXQgaXQgbWlnaHQgc2V0IHRoZSBjbGllbnQgdXAgb24gYSBnb29zZSBj aGFzZSBmb3IgbW9yZSBwZXJtaXNzaW9ucy4NCj4NCj4gNS4wMCBvZiBjb3Vyc2UgYWx3YXlzIGlz IHBvc3NpYmxlLCBhcyBhcmUgNS4wMSBvciA1LjAzLiAgNS4wMyBoYXMgbWF4LWFnZSAocmV0cnkt YWZ0ZXIpIHNlbWFudGljcyB0aGF0IG1heWJlIGRvbuKAmXQgZml0IHZlcnkgd2VsbCBoZXJlOyBp dCBpcyByZWFsbHkgbWVhbnQgZm9yIHRlbXBvcmFyeSBjb25kaXRpb25zLg0KPg0KPiBUaGVyZSBp cyBsaXR0bGUgZ3VpZGFuY2UgaW4gUkZDIDcyMzAgKG9yIFJGQyAyNjE2KSB3aGVuIHRvIHVzZSA1 MDEgKHdoaWNoIG91ciA1LjAxIHJlZmVyZW5jZXMpOyBpdCBvbmx5IGdldHMgc3BlY2lmaWMgYWJv dXQgdXNpbmcgaXQgYXMgYSByZXNwb25zZSB3aGVuIHRoZSByZXF1ZXN0IG1ldGhvZCBpcyBub3Qg aW1wbGVtZW50ZWQgYXQgYWxsLg0KPg0KPiBTbywgbm8sIEkgZG9u4oCZdCB0aGluayB3ZSBoYXZl IGEgZ29vZCBmaXQgaGVyZS4gIElzIHRoZSB1c2UgY2FzZSBpbXBvcnRhbnQgZW5vdWdoIHRoYXQg d2Ugd2FudCB0byBpbnZlbnQgYSBuZXcgc3RhdHVzIGNvZGU/ICBPdGhlcndpc2UsIDQuMDMgc2Vl bXMgdG8gYmUgYXMgZ29vZCB0byBtZSBhcyA1LjAxLg0KPg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+ DQo+DQo+PiBPbiAzMSBKYW4gMjAxNywgYXQgMTY6MjksIERpamssIEVza28gPGVza28uZGlqa0Bw aGlsaXBzLmNvbT4gd3JvdGU6DQo+Pg0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gdGhlIGZvbGxvd2lu ZyBxdWVzdGlvbiBjYW1lIHVwIGluIGEgc3lzdGVtIGRlc2lnbiB0aGF0IHVzZXMgQ29BUC4gV2hh dCBpZiBhIGNsaWVudCBhc2tzIGZvciBhIHJlc291cmNlIChlLmcuIHVzaW5nIHF1ZXJ5IGFyZ3Vt ZW50cykgdGhhdCB3b3VsZCBnZXQgcHJvaGliaXRpdmVseSBsYXJnZSwgc3VjaCB0aGF0IHRoZSBz ZXJ2ZXIgY2FuJ3Qgc2VydmUgaXQ/IExvb2tpbmcgYXQgQ29BUCBjb2RlIDQuMTMgKFJlcXVlc3Qg RW50aXR5IFRvbyBMYXJnZSA7IG9yIGluIHVwZGF0ZWQgSFRUUCBqYXJnb24gIlBheWxvYWQgVG9v IExhcmdlIiBwZXIgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02 LjUuMTEgKTsgaXQgc2VlbXMgdG8gb25seSBwZXJ0YWluIHRvIHRoZSByZXF1ZXN0IHBheWxvYWQg c2l6ZSDigJMgbm90IHRoZSByZXNwb25zZSBwYXlsb2FkIHNpemUuIEluIGJvdGggdGhlIEhUVFAg YW5kIENvQVAgY2FzZXMuIFNvIGl0IHNlZW1zIHVuc3VpdGFibGUgZm9yIHRoZSBzaXR1YXRpb24g SSBkZXNjcmliZSBhYm92ZS4NCj4+DQo+PiA0LjAwIEJhZCBSZXF1ZXN0IHNlZW1zIHVuc3VpdGFi bGUgYmVjYXVzZSB0aGUgc3ludGF4IC8gZm9ybWF0dGluZyBvZiB0aGUgQ29BUCByZXF1ZXN0IGlz IGZpbmUuICA1LjAwIHNlZW1zIHBvc3NpYmxlIGlmIHdlIHRha2UgdGhlIHBlcnNwZWN0aXZlIHRo YXQgaXQgaXMgdGhlIHNlcnZlcidzIGZhdWx0IHRoYXQgaXQgY2Fubm90IHByb2R1Y2UgdGhlIHJl cXVlc3RlZCAobGFyZ2UpIHJlc3BvbnNlIHBheWxvYWQuDQo+Pg0KPj4gU29tZSBiYWNrZ3JvdW5k IGRpc2N1c3Npb24gaXMgYWxzbyBvbiBodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25z LzE1MTkyNDc3L2h0dHAtc3RhdHVzLWNvZGUtd2hlbi1zaW5nbGUtcmVxdWVzdC1hc2tzLWZvci10 b28tbGFyZ2UtcmVzb3VyY2Utb3ItdG9vLW1hbnktb2Ygd2hpY2ggc3VnZ2VzdHMgdG8gdXNlIDQw MyAvIDQuMDMgZm9yIHRoaXMgY2FzZS4gV2hpY2ggc2VlbXMgbm90IGlkZWFsIGFzIHdlbGwgYmVj YXVzZSBpdCB0ZWxscyB0aGUgY2xpZW50IHRoYXQgaXRzIGF1dGhvcml6YXRpb24gaXMgaW5zdWZm aWNpZW50IHdoaWNoIGlzIG5vdCB0aGUgY2FzZSBoZXJlLg0KPj4NCj4+IERvZXMgYW55b25lIGhh dmUgYSB2aWV3IG9uIHRoaXM/DQo+Pg0KPj4gYmVzdCByZWdhcmRzDQo+Pg0KPj4gRXNrbyBEaWpr DQo+Pg0KPj4NCj4+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1h eSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUg bGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocyku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IGNvcmUgbWFpbGluZyBsaXN0DQo+PiBjb3JlQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBt YWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0K From nobody Tue Jan 31 23:21:59 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90EC129422 for ; Tue, 31 Jan 2017 23:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhT5FZfFPXnd for ; Tue, 31 Jan 2017 23:21:56 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0562B129420 for ; Tue, 31 Jan 2017 23:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v117LfYl006393; Wed, 1 Feb 2017 08:21:41 +0100 (CET) Received: from [192.168.217.124] (p5DC7E5A6.dip0.t-ipconnect.de [93.199.229.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vCvh43Kb6z3ZlX; Wed, 1 Feb 2017 08:21:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Wed, 1 Feb 2017 08:21:39 +0100 X-Mao-Original-Outgoing-Id: 507626499.190179-35f1a12fb5a60acbbfdc348a499ff261 Content-Transfer-Encoding: quoted-printable Message-Id: <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> To: Lauri Piikivi X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 07:21:58 -0000 Hi Lauri, indeed, the CoRE world is different from the HTTP world. > I propose a bit of info gathering, I imagine there are more similar = kinds of situations where HTTP has not had the right code. When we do this, I would like to approach new codes not just with = =E2=80=9Cwhat should the server do=E2=80=9D but more importantly with = =E2=80=9Chow is the client going to react differently=E2=80=9D. If the = error response is just about telling what went wrong so a human can = debug the situation, diagnostic payloads are fine. If we need more = detail in an error response so the client can formulate a better request = based on those details, we may want to standardize =E2=80=9Cproblem = detail=E2=80=9D payloads, inspired by RFC 7807. Gr=C3=BC=C3=9Fe, Carsten