From nobody Sun May 3 15:46:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98853A090E; Sun, 3 May 2020 15:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC0QXf6xYfYq; Sun, 3 May 2020 15:46:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2FB3A08FC; Sun, 3 May 2020 15:46:32 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 043MkPn8005596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 May 2020 18:46:28 -0400 Date: Sun, 3 May 2020 15:46:25 -0700 From: Benjamin Kaduk To: Klaus Hartke Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-stateless@ietf.org, "core@ietf.org WG" Message-ID: <20200503224625.GF27494@kduck.mit.edu> References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 22:46:36 -0000 Hi Klaus, On Wed, Apr 29, 2020 at 01:11:04PM +0200, Klaus Hartke wrote: > Hi Ben, > > here's the next batch. Please see inline below. > > Best regards, > Klaus > > > Benjamin Kaduk wrote: > > Section 3.1 > > > > o A client SHOULD integrity protect the state information serialized > > in a token, unless processing a response does not modify state or > > cause any other significant side effects. > > > > If the intent is that the "does not modify state" clause is the only case > > when one would disregard the need for integrity protection, "MUST [...] > > unless" seems more appropriate. (I would prefer unconditional MUST and am > > not sure I understand the cases where there is a need to skip integrity > > protection.) > > The intent here is that a client must do integrity protection, but > there may exist valid reasons in particular circumstances to ignore > this requirement. In this case, the full implications must be > understood and carefully weighed. > > All of the circumstances that come to my mind here are those where a > modified token doesn't actually hurt. For example, if a client sends a > request to some server at regular intervals, it might only be > interested in whether the response has an error or success code and > not even deserialise the token. > > What's the best way to capture this? Before I get into suggested text, I want to check that I understand the situation properly -- in such a case where the client is not even deserializing the token, why would the client not be able to use a regular token and not look at that token's value? It doesn't seem like the client is gaining anything from having the serialized state available. Your description makes it sound like we may have to just do "SHOULD integrity protect" without the "unless [...]" clause. > > o Even when the serialized state is integrity protected, an attacker > > may still replay a response, making the client believe it sent the > > same request twice. For this reason, the client SHOULD implement > > > > (Basically the same comments about "SHOULD".) > > See above. > > This section is about protecting the serialized state, but of course > the requests and responses need to be protected as a whole as well > (e.g., using DTLS or OSCORE). In some circumstances, receiving a > replayed token might not hurt if the client can verify that the > response is coming from the right server. Presumably the same cases where a replayed response from the right server would be tolerable? Such cases are ... rare, in my opinion. > > cause other any significant side effects. For replay protection, > > integrity protection is REQUIRED. > > > > I'm not entirely sure if the normative keyword is needed for effect, here; > > it's simply a fact that replay protection is impossible in the absence of > > integrity protection, isn't it? > > Right. The intention here was to turn the "SHOULD integrity protect > the state information" from above into a "MUST". But I can lowercase > the "REQUIRED" or remove the sentence. I'd suggest rewording to say that "replay protection is impossible if integrity protection is not in use" (or similar). > > o If processing a response without keeping request state is > > sensitive to the time elapsed since sending the request, then the > > serialized state SHOULD include freshness information (e.g., a > > timestamp). > > > > Continuing the theme, this seems like a conditional MUST (not SHOULD). > > Actually, all the rest of the SHOULDs in this section do. > > See above. > > > This particular one should also note that the response processing needs to > > actually check the timestamp and reject ones that are insufficiently fresh. > > I've made the following change (ignoring the SHOULD/MUST discussion): > > OLD: > > If processing a response without keeping request state is > sensitive to the time elapsed since sending the request, > then the serialized state SHOULD include freshness > information (e.g., a timestamp). > > NEW: > > If processing a response without keeping request state is > sensitive to the time elapsed since sending the request, then the > client SHOULD include freshness information (e.g., a timestamp) in > the serialized state and reject any response where the freshness > information is insufficiently fresh. Sounds good (ignoring the SHOULD/MUST discussion), thanks. > > Also, integrity protection is again required for this to work. > > Right. I think I'll remove the sentence "For replay protection, > integrity protection is REQUIRED." from above so that I don't have to > repeat it for every item. I think it's quite obvious. Ah, fair enough (my suggestion above notwithstanding). > > Section 5.2 > > > > The use of encryption, integrity protection, and replay protection of > > serialized state is recommended, unless a careful analysis of any > > potential attacks to security and privacy is performed. [...] > > > > I suggest an alternative wording: > > > > % It is generally expected that the use of encryption, integrity protection, > > % and replay protection for serialized state is appropriate. However, a > > % careful analysis of any potential attacks to the security and privacy > > % properties of the system might reveal that there are cases where such > > % cryptographic protections do not add value in a specific case. > > Sounds good. Thanks! Thanks, Ben From nobody Sun May 3 21:15:07 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C083A0BD1 for ; Sun, 3 May 2020 21:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taitradio.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIWpJOA40VZD for ; Sun, 3 May 2020 21:15:05 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 377F43A0BCF for ; Sun, 3 May 2020 21:15:04 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id re23so12762367ejb.4 for ; Sun, 03 May 2020 21:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taitradio.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=ErZs2Lg/pWwuTMFW2pQUvSFCJURJy+zIq+T/JeoSP0k=; b=Zyh0I1z37z7qgq2sMPahRpT7Lnl12bRy+59JxZUr5cENbiY5u8ldjw68af8wQ7YWSA wu7VVZ5MPlMeeLr7E51t4i+XpBbgJqwlBz+cpUmA3iTAhxqSld6HgMfgey6ErOOp3t+A 7PVunpR53zO5r2XwD/UH2oOES0Vto4H63UEAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ErZs2Lg/pWwuTMFW2pQUvSFCJURJy+zIq+T/JeoSP0k=; b=tcRBxJQOYxcX1WQD+Lq+g4hsld/F4hKg3SAF2/4i5e5xv54ODzeUkR6p81uvC122bX 0bw6/fGxjR6/mhSM3K7MyDY4lbWJv7Ptfs1DCES6o5gWRWlaj87Wk7lhZOQcWv8AoGvJ vb8i9DmRcSQL6p6/+ytPc446c1oz2yd4YF/Wzp8XbSFe5cVqF5hmicTKZ17INykeEcyD ljGoMuE7QBRtvzCpyDGQQVVZA2JaF51jZERZRgZwWawPcOoMgSu9wvISNx4g6g/eK3nW DZzwZ8PDv4uWNJbkBvQHt5UF96TLmnS+3+og2LxkwcmvV4tee6zHdxrQ0NA6pd2lRNVb 59+g== X-Gm-Message-State: AGi0PubhZUF4wDN/wZ0bbPkiU9ToIUsOluk/LNecYkXfa4T2QxgbHefV wAnq7Q7U1u2NJRm6FauUM3saLr2Sw8osRW6myKxaZAgs7Zh4MGeGouHYTXmhgeJT94cKjSZBCz6 yqsIYbs/QK71TjUYQrA== X-Google-Smtp-Source: APiQypJzjyJoW2nxufplA+Pt2fQylrEoL3NsV6Vz2lgor2YFOwVw0058K15jYDFN9cFPFlEsedZZ6I0wOZKjngqrlQY= X-Received: by 2002:a17:906:4995:: with SMTP id p21mr12721210eju.19.1588565703281; Sun, 03 May 2020 21:15:03 -0700 (PDT) MIME-Version: 1.0 From: John Carter Date: Mon, 4 May 2020 16:14:52 +1200 Message-ID: To: core Content-Type: multipart/alternative; boundary="000000000000726f1e05a4cac6e1" Archived-At: Subject: [core] What is the best introduction to CoRE aims and rationale? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 04:15:07 -0000 --000000000000726f1e05a4cac6e1 Content-Type: text/plain; charset="UTF-8" I'm having a hard time convincing and explaining to some colleagues what the value of it is. In particular one colleague is very disbelieving that one can, in practice, gain effective decoupling of software systems by it. Thank you! -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer --000000000000726f1e05a4cac6e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm having a hard time convincing and explaining = to some colleagues what the value of it is.

In par= ticular one colleague is very disbelieving that one can, in practice, gain = effective decoupling of software systems by it.

Thank you!

--
John Carter
Ph= one : (64)(3) 358 6639
Tait Electronics=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0
PO Box = 1645 Christchurch
New Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--000000000000726f1e05a4cac6e1-- From nobody Sun May 3 23:59:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6963A0CDB for ; Sun, 3 May 2020 23:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_X5BfgDyQ97 for ; Sun, 3 May 2020 23:59:44 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503353A0CDA for ; Sun, 3 May 2020 23:59:44 -0700 (PDT) Received: from client-0127.vpn.uni-bremen.de (client-0127.vpn.uni-bremen.de [134.102.107.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49FtyQ6sJ6zyyg; Mon, 4 May 2020 08:59:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 4 May 2020 08:59:42 +0200 Cc: core X-Mao-Original-Outgoing-Id: 610268382.544759-c72035cdc21bdaf5a8dbf34c94611576 Content-Transfer-Encoding: quoted-printable Message-Id: <7FF773A8-62E2-400E-81FF-5C0B051E5319@tzi.org> References: To: John Carter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] What is the best introduction to CoRE aims and rationale? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 06:59:47 -0000 Hi John, while there is no single document that addresses your needs here, may I = point you to a T2TRG draft [1]: "RESTful Design for Internet of Things Systems", Ari Keranen, Matthias Kovatsch, Klaus Hartke, 2019-11-04, This document gives guidance for designing Internet of Things = (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product = of the IRTF Thing-to-Thing Research Group (T2TRG). This is less about just listing the benefits of REST-oriented design for = IoT and more about telling how to actually do that, but it should = contain enough material for a good start. If you have any feedback on how to clarify the argumentation there or = otherwise improve the document, I=E2=80=99m sure the authors [2] and/or = the T2TRG mailing list [3] would appreciate that. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/draft-irtf-t2trg-rest-iot [2]: mailto:draft-irtf-t2trg-rest-iot@ietf.org [3]: mailto:t2trg@irtf.org > On 2020-05-04, at 06:14, John Carter = wrote: >=20 > I'm having a hard time convincing and explaining to some colleagues = what the value of it is. >=20 > In particular one colleague is very disbelieving that one can, in = practice, gain effective decoupling of software systems by it. >=20 > Thank you! >=20 > --=20 > John Carter > Phone : (64)(3) 358 6639 > Tait Electronics =20 > PO Box 1645 Christchurch > New Zealand >=20 >=20 > This Communication is Confidential. We only send and receive email on = the > basis of the terms set out at www.taitradio.com/email_disclaimer > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon May 4 01:42:35 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A538D3A03FE for ; Mon, 4 May 2020 01:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7KVIGsVO9rM for ; Mon, 4 May 2020 01:42:31 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 E88483A03F6 for ; Mon, 4 May 2020 01:42:30 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id g13so19860546wrb.8 for ; Mon, 04 May 2020 01:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6UDjYk5cg5AkEVmijl4a91xNWgqkqdNVhochDLAwiM4=; b=bJiu/8aiRGlB+pW4ISHSB+W4bO9JIoFPBBK8N9oHFg731YqNaNscVT3m/CeY0CWuYa EuAflbu5chiZzQkGnOo3QmQDMdCjBMDrRnYKc3BTGhSqHGD7lFZ7IsA3n/+T2znOHCGH q/OlsbgFG6J+n+UKjRI1hSyRu7Gv+SOdUvx9RsFNqQvtAUMeaGfwO2aojrsnr4gUVDK8 CuxkcEv6LMaUvRjhC031KP0BnUXoePdfA3UnjJbngS6plmUEdxMJl1/JW54RPhZASLs3 SRbG4PzIeT42skEBD3GHBjnOU0XooORxgLmnCeXCruXN9P+pHVaUt3FRRYYRL8T6I9jv ShlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6UDjYk5cg5AkEVmijl4a91xNWgqkqdNVhochDLAwiM4=; b=I9loEp2dl7F/e2ZdlinE/ETAEKL85zlD5VGxC+klf7TOmBB+XvELxqLlmYMwk159WR y//4pMqW01Zs0tgC5MwulGLVkYKU3ADEvb4nPF1W4mTZ5sFJ8xmPfYnQRzh4chAf9zl2 DeZ7HOpCnw6lKNqvtIP1ph/INGXoZEVLXEVYubK4IUxXe/hW1L8VCmL9vfhCclx2hI4k BTdgLz3uvWiVPGrXTQVT2Me/lOrTqTisAhr6JOLADGuelv+JbbI79g4BlZtTyp5txj4x jBpQTPFTxAVKLC5cIZx/ufsaynH6Ky0/5HUdKRDyczMNnE9GYnjAfRYK0Gv+ClzmpMAq 78KQ== X-Gm-Message-State: AGi0Pua9Wyr/uQujqpotBSmWSm5mf5Ntpo6B8A5A4cIjdxhRNXs6mcWj ySqCbTTX+wDxjFK9jUpDINTqFQs9MpnpO+KQ1Pk2dS2W X-Google-Smtp-Source: APiQypLW7HHiTXmLj4QA0a7Z/4UzoLmx5BOB64O+JP7mEOlKqbSuz0ZeZkk1+95xHjdt0I1g+NzUMYS6Kl7P3WNaxTA= X-Received: by 2002:a5d:500b:: with SMTP id e11mr17586532wrt.272.1588581749143; Mon, 04 May 2020 01:42:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Mon, 4 May 2020 10:42:03 +0200 Message-ID: To: Klaus Hartke Cc: "core@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000dae08305a4ce82fa" Archived-At: Subject: Re: [core] Review of draft-ietf-core-comi-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 08:42:34 -0000 --000000000000dae08305a4ce82fa Content-Type: text/plain; charset="UTF-8" Hello Klaus, I apologize for the delay and thank you for your review! It was really useful for me and for the draft I believe. Please find my answers below (prefixed with [IP]). Please note that the diff after handing your comments is available at [1]. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-comi.txt&url2=https://core-wg.github.io/comi/draft-ietf-core-comi.txt On Mon, Apr 13, 2020 at 1:04 PM Klaus Hartke wrote: > Section 2.4: The document seems to use the terms "content format" as a > synonym for "content type". A content format is the combination of a > content type (which is the combination of a media type with specific > values for the media type's parameters) with a content coding. An > example for a media type is "text/plain", for a content type > "text/plain;charset=utf-8", and for a content format > "text/plain;charset=utf-8" combined with "gzip". I think you mean > content type, right? > [IP]: It seems to me that you are right, therefore I have changed content format to content type in all places where such a change seemed necessary. Please do not hesitate to let me know if I have missed any place or if I have misunderstood you. Section 2.4: In the table, all the media types incorrectly have a leading > "/". > > Section 4: It's not okay to mandate or recommend specific paths like > and . Not even with a lower-cased "recommended". It's fine to > define a path structure after the "root path" of the application and > use an example path in examples, but implementers should not be > restricted or discouraged in any way to choose a different path (see > BCP 190). The best choice is probably to use a long, not very nice > looking path like , so that > implementers immediately get the idea to pick a shorter path > themselves :-) > [IP]: I believe I captured what was suggested here, but please check if that is indeed the case. Section 4: The document specifies the API in terms of the CoAP > Uri-Query option a lot. The Uri-Query option is just the way how the > query string of the request URI is encoded in CoAP, though. It would > be better to specify the API in term of query strings and not to > mention the Uri-Query option. > > Section 4.1: It's unclear if a client should send the query string > or (with quotes, as shown in the table) for a Boolean > value. > [IP]: I believe now this is clear. It is now also clarified that 0 maps to false and 1 to true (which might not be what a person using a lot of bash would expect). Section 4.1: It's unclear if the int2str function returns "291" (5 > characters) or "291" (3 characters, typographically set in quotes). > > Section 4.2.2: It's unclear if a client should send the query string > or (with a space and single quotes, as shown in the > indented paragraph). > Section 4.2.3.1: It's unclear why a client needs to send the query > string instead of . The table in section 4.1 > seems to say that a string `key` is written as `key`, not as `"key"`. > Can a `key` contain `"` characters itself and, if yes, how are those > escaped? > [IP]: It should be clear now that it is without the quotes (for the three points). Section 4.5: If I understand this correctly, this enables getting > events by appending these to an internal "log file" and exposing the > latest few entries of the log file as the resource . This resource > can be observed, so that if new entries are appended, the resource > changes its state and the client gets notifications. Correct? It might > be worth pointing out that this scheme does guarantee delivery of all > entries in the log file to the client. It might also be a good idea to > remind implementers of what happens when the size of the last few > entries is greater than the MTU. > > Section 4.5: The last paragraph says "To check that the client is > still alive, the server MUST send Confirmable Message periodically." > That's what RFC 7641 already specifies. Please don't make normative > statements that repeat (or contradict) what RFC 7641 says. :-) > [IP]: As you pointed out, this is clearly specified in RFC 7641, so I removed it from this document. Klaus > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000dae08305a4ce82fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Klaus,

I apologize= for the delay and=C2=A0thank you for your r= eview! It was really useful for me and for the draft I believe. Please find= my answers below (prefixed with [IP]). Please note that the diff after han= ding your comments is available at [1].

Best regards,
Ivaylo
<= /div>


On Mon, Apr 13, 2020 at 1:04 PM Klaus Hartke <hartke@projectcool.de<= /a>> wrote:
S= ection 2.4: The document seems to use the terms "content format" = as a
synonym for "content type". A content format is the combination o= f a
content type (which is the combination of a media type with specific
values for the media type's parameters) with a content coding. An
example for a media type is "text/plain", for a content type
"text/plain;charset=3Dutf-8", and for a content format
"text/plain;charset=3Dutf-8" combined with "gzip". I th= ink you mean
content type, right?

[IP]: It seems to me that you are right, ther= efore I have changed content format to content type in all places where suc= h a change seemed necessary. Please do not hesitate to let me know if I hav= e missed any place or if I have misunderstood you.

Section 2.4: In the table, all the media types incorrectly have a leading &= quot;/".

Section 4: It's not okay to mandate or recommend specific paths like </c> and </s>. Not even with a lower-cased "recommended&qu= ot;. It's fine to
define a path structure after the "root path" of the application = and
use an example path in examples, but implementers should not be
restricted or discouraged in any way to choose a different path (see
BCP 190). The best choice is probably to use a long= , not very nice
looking path like </path/to/the/data/store/X9?k= =3D"eth0">, so that
implementers immediately get the idea to pick a shorter path
themselves :-)

[IP]:= I believe I captured what was suggested here, but please check if that is = indeed the case.

Section 4: The document specifies the API in terms of the CoAP
Uri-Query option a lot. The Uri-Query option is just the way how the
query string of the request URI is encoded in CoAP, though. It would
be better to specify the API in term of query strings and not to
mention the Uri-Query option.

Section 4.1: It's unclear if a client should send the query string
<?k=3D0> or <?k=3D"0"> (with quotes, as shown in the = table) for a Boolean
value.

[IP]: I bel= ieve now this is clear. It is now also clarified that 0 maps to false and 1= to true (which might not be what a person using a lot of bash would expect= ).

Section 4.1: It's unclear if the int2str function returns "291&quo= t; (5
characters) or "291" (3 characters, typographically set in quotes= ).

Section 4.2.2: It's unclear if a client should send the query string <?d=3Dt> or <?d=3D 't'> (with a space and single quotes= , as shown in the
indented paragraph).
Section 4.2.3.1: It's unclear why a client needs to send the query=
string <?k=3D"eth0"> instead of <?k=3Deth0>. The tabl= e in section 4.1
seems to say that a string `key` is written as `key`, not as `"key&quo= t;`.
Can a `key` contain `"` characters itself and, if yes, how are those escaped?

[IP]: It sh= ould be clear now that it is without the quotes (for the three points).
Section 4.5: If I understand this correctly, this enables getting
events by appending these to an internal "log file" and exposing = the
latest few entries of the log file as the resource </s>. This resourc= e
can be observed, so that if new entries are appended, the resource
changes its state and the client gets notifications. Correct? It might
be worth pointing out that this scheme does guarantee delivery of all
entries in the log file to the client. It might also be a good idea to
remind implementers of what happens when the size of the last few
entries is greater than the MTU.

Section 4.5: The last paragraph says "To check that the client is
still alive, the server MUST send Confirmable Message periodically." That's what RFC 7641 already specifies. Please don't make normative=
statements that repeat (or contradict) what RFC 7641 says. :-)

[IP]: As you pointed out, this i= s clearly specified in RFC 7641, so I removed it from this document.
Klaus

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000dae08305a4ce82fa-- From nobody Mon May 4 02:18:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A7C3A053E for ; Mon, 4 May 2020 02:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdt4G2DA2pSZ for ; Mon, 4 May 2020 02:18:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984DC3A0538 for ; Mon, 4 May 2020 02:18:31 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49Fy2Y3Qddz10Mm; Mon, 4 May 2020 11:18:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 4 May 2020 11:18:28 +0200 Cc: Klaus Hartke , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 610276708.852886-ac2f05dd927704c2b16bcd634848e6bf Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ivaylo Petrov X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] Review of draft-ietf-core-comi-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 09:18:34 -0000 On 2020-05-04, at 10:42, Ivaylo Petrov wrote: >=20 > Section 4: It's not okay to mandate or recommend specific paths like > and . Not even with a lower-cased "recommended". It's fine to > define a path structure after the "root path" of the application and > use an example path in examples, but implementers should not be > restricted or discouraged in any way to choose a different path (see > BCP 190). The best choice is probably to use a long, not very nice > looking path like , so that > implementers immediately get the idea to pick a shorter path > themselves :-) >=20 > [IP]: I believe I captured what was suggested here, but please check = if that is indeed the case. This problem of course comes up repeatedly in a number of WGs. Here is an example from a position on this as taken in the OAuth WG: = I don=E2=80=99t think that filling all examples with noise such as = /path/to/the/data/store is really helpful. I would prefer to have most examples use the IYDHABI (*) paths, with = only a few alternative paths (all different!) used in some examples. BCP 190 asks to ensure the server has a choice, not that all servers = must make different choices. Gr=C3=BC=C3=9Fe, Carsten (*) =E2=80=9Cif you don=E2=80=99t have a better idea=E2=80=9D=E2=84=A2 From nobody Mon May 4 04:18:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD82D3A07BA; Mon, 4 May 2020 04:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06FbIrAz-JmZ; Mon, 4 May 2020 04:18:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40050.outbound.protection.outlook.com [40.107.4.50]) (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 0A2273A07B9; Mon, 4 May 2020 04:18:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g4uFPGHQHRx7qd/rYjRnkcHDAFAEs3iZ+ARnZ68sfB/0GVwrgNcMTrv7sscFphl7qu5Op4upf89mY/LGOXbEUcwak/BpSYo+nkbvetHs26xjzEtv/ybzVekhU8wacQ54ppltxgNVC12/oytg4DhEYpOlz0m4sz4JiAzPyi8xVk9P0Wc9U5mKs9OR61ehDowT4LJFxJeyA/ub6sJIFSkVzIUqqiO4dpMEYbJVZwp99uphAOz4UvKdKkGQyZHdKxX6t3VhdmKIH+j8WAX31zYTDzlQIMKbrg9RMc5iIRgFxOrYgwbkga0SoCTdSpZhJ2Q+3/R1caRiU/HSdWZiMW04XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W0W8OQ5oZbDGu4g/k2z1M3dJ9cjH1Z0bgIk9FPhLyRY=; b=dy4qiqoNj1PwA+YG/93TVKxkEqIinKu77cn5MyqWLOAlDClUc621o002xrRj9YnIaFSjDPVGBzqAZuYlQqFpxREiI1KHgE9cZRPa+1RUA//1o0yjlGVyAfoCJSqoyOh67hSl7QkOX/nQj2zancwAvEOZUJfwG3n26eC435v7UBfZluXLRH1/K7KZhZeBv1Yh40Y0i3+TfAKyvBSJGAgllMYjUjlfB2Kxan9OBlaCJ6Opw8gmV26jnaa8lZlws8oyjc5KCvZQ57LtmZce1obIqr3+g6+mjpsgTPzh5llcL2GspcT1aspXJFcsnEH1g19orKpeuGFKNqeZifvCOJ+XnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W0W8OQ5oZbDGu4g/k2z1M3dJ9cjH1Z0bgIk9FPhLyRY=; b=rlbMP7fIOndXqzejp355F7zqhBRjVWsKiwpBmn5vpeI7T9ZfdCZus46ToX2TuTRblSlz5OK/S205n9GfkTduIaHRta7sGoxkSBp3cd92yY6YhimlXt9fbf2mvY+KaF4FcIKsCdoLZcfSlh1vvW21UWvlfcaXlH/hcQ2dW4ayVJg= Received: from AM7PR07MB6945.eurprd07.prod.outlook.com (2603:10a6:20b:1bf::11) by AM7PR07MB6293.eurprd07.prod.outlook.com (2603:10a6:20b:133::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.24; Mon, 4 May 2020 11:18:47 +0000 Received: from AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931]) by AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931%7]) with mapi id 15.20.2979.024; Mon, 4 May 2020 11:18:47 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "ace@ietf.org" Thread-Topic: Multicast notifications for distributing public keys to other group members Thread-Index: AQHWIgXHzV9mp3zMoEOsNx4hgbX4VQ== Date: Mon, 4 May 2020 11:18:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f70fc3b8-1b52-4f5e-3cd5-08d7f01cea65 x-ms-traffictypediagnostic: AM7PR07MB6293: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03932714EB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HNpGAPv8gknM+3eltCia/nUUre5/vdfRezKYdxXvwdCWdThQ1JXstViHzaaDCRkR0/V7W78Gp5zRmuMuH91+CzvJAZhOQkKtOA9clYeDUJJ0xnTA27yy0+Mbl4HWt/eAunJtIrzmayd6dYWfiXxWQGkLohkrH2SUOd897EH4to276cacyULdkMwF8QnJtmzR9co5fwNUyrcy3JZ0hWDf9uflbkdEpL0Y3p2Iy+GRRVZv1Xd8Ydvhb4ufAePb7FvLQ+xEUfcUqF0B4fBWSvW/933o6Bb0Z8I1yM5ncHqosiWZ17rEGsQ1o0ffO+wFdn5H52rCskeGMuK+p8wRw6ngt/9WcPkmYlsmZ8s25KX/7ccTOg6uDaSe23Qfk6/c/kwlMrJbhVk8FoVUn0nGDJoZ3+xp/09RmXxsoSI8FGRKOs59E7ImXJUhDQXo5L7Px5C64RiTkqsunF9N05U8TSg6u/y3TQNOAhVjYJ6YwcKTnflGxsRqTxBj2XbTneverVY1SS7gtmcOW5T84ro0ZLy/DQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6945.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(86362001)(15650500001)(76116006)(83080400001)(66446008)(66476007)(478600001)(6506007)(66556008)(450100002)(64756008)(26005)(186003)(66946007)(85182001)(2616005)(966005)(2906002)(85202003)(6512007)(5660300002)(71200400001)(36756003)(316002)(110136005)(66574012)(8676002)(8936002)(33656002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: L2/BKP3SC/E/uNHDbcgYy7HIDXRgEGkt3mku7RP6exNa7o0B+XYjVKwe6uvuG07gOq9s4et+XyhUWhTlymlQ5HrXLX1WEmDrcatdvEAOyALj9zxmvME3fW/s1kFHtNtCA6BWOCNqslFRMHn3vFtpP3UnbarZiIOiVdZRs4EfTbEy8LpbMzXkW3I3oaZst1mpk/43pbaXLEUK91mnU5QGQFGUEYS1k9VbNG5klOfA95w1Gt0A7W5LnWkW7AXR+N1t9KhxIm0MMlogFDAQhwX+6LiTRbVUGLTZff+U2NKdNQjU22lJNaZsOfZpsnMaG+SiYqsk/NESXNh6Q4BLP/it4DlBjYJAWkjqAg1P+XgD4hJsST63jGJbCnE2i8WqZ9wcDWZ/kolCLJVfd0g9r/w8x9pMJFImUd5Jqm1WPd5whWRtFRuZjA1XH2aEaHvryqhU8R5h4AdFwTQIwca7mkKNX4wqZIUI2nRinUxWjePRf6vKYVVDrgDDTzciIh4PnfdxQvxAua481mjqZ32/KNMg0LauBOU3TGYGIcYSxU6xQ1y3GarqUayoFgq6mwSzrIHIzV0Rmk+hkdOg3RCQP/pYWw467aW/o+/2Lp2N7lAvkD/xU33MkJ8KeoScpirib9IrfI48/6LMLAgQaOIzC9i2iwFq5sPH1yWS6spcoEwL3dXsdaVI/jntXX18VXCQXOG/Axt9owBJO3EJV8kX75sx0h9zdWntS73tziVT2T7wBe6E/+pjY3fM9CYn1VNmWkIExIltFizFNwgnwICmKlP59IQkMEmPpWKLBPLRMhXnv7g= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3E46990F4CE77A448017D45AF59815A5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f70fc3b8-1b52-4f5e-3cd5-08d7f01cea65 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 11:18:47.7741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4qENbUXI0z6xBo5B9nlOUTj6DcfyiJwBjy1SHaVxj308RBOS5Pm9pTTw4D17MoWIwv5L7TWOAawNh/OnAxeRHiP0hnh7IT8+NFjEKWCITp4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6293 Archived-At: Subject: [core] Multicast notifications for distributing public keys to other group members X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 11:18:52 -0000 DQpEZWFyIENvUkUgYW5kIEFDRSwNCg0KQXBvbG9naWVzIGZvciBjcm9zcy1wb3N0aW5nLCB0aGlz IGNvbmNlcm5zIHRoZSBzZWN1cml0eSBmb3IgQ29BUCBncm91cCBjb21tdW5pY2F0aW9ucyAod2hp Y2ggaXMgYSBDb1JFIGRyYWZ0KSBhbmQgdGhlIGN1cnJlbnQgc3BlY2lmaWVkIG1ldGhvZCB0byBy ZXRyaWV2ZSBwdWJsaWMga2V5cyBmb3IgZ3JvdXAgY29tbXVuaWNhdGlvbiAod2hpY2ggaXMgYW4g QUNFIGRyYWZ0KS4NCg0KV2hlbiBhIG5vZGUgam9pbnMgYSBncm91cCBbMF0gdGhlcmUgaXMgYSBu ZWVkIGZvciBncm91cCBtZW1iZXJzIHRvIGdldCBpdHMgcHVibGljIGtleS4gU2VjdGlvbiA0LjUg b2YgdGhlIGN1cnJlbnQgR2l0aHViIHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1hY2Uta2V5LWdyb3Vw Y29tbSAiS2V5IFByb3Zpc2lvbmluZyBmb3IgR3JvdXAgQ29tbXVuaWNhdGlvbiB1c2luZyBBQ0Ui IFsxXSBkZXNjcmliZXMgcHJvY2VkdXJlcyBmb3IgcmV0cmlldmluZyB0aGUgcHVibGljIGtleXMs IGJ5IGFjY2Vzc2luZyB0aGUgcmVzb3VyY2UgImFjZS1ncm91cC9HUk9VUE5BTUUvcHViLWtleSIg aW4gdGhlIEtEQy4gU2VjdGlvbiA0LjMgaW4gdGhlIHNhbWUgZG9jdW1lbnQgZGVzY3JpYmVzIHRo ZSBwcm9jZWR1cmUgdG8gIm1ha2UgdGhlIC4uLiByZXNvdXJjZSBPYnNlcnZhYmxlLCBhbmQgc2Vu ZCBub3RpZmljYXRpb25zIHRvIENsaWVudHMgd2hlbiB0aGUga2V5aW5nIG1hdGVyaWFsIGlzIHVw ZGF0ZWQiLg0KDQoxLiBUaGUgdXNlIG9mIG5vdGlmaWNhdGlvbnMgaXMgZ29vZCB0byBhdm9pZCBz aW1pbGFyIHJlcXVlc3RzIGZyb20gc2V2ZXJhbCBub2RlcyBpbiB0aGVzZSBjYXNlcy4gQnV0IHRo ZSBwcm9jZWR1cmUgaXMgb25seSBtZW50aW9uZWQgYnJpZWZseSBhcyBxdW90ZWQgYWJvdmUuIFdv dWxkIGl0IGJlIHBvc3NpYmxlIHRvIGV4cGFuZCBvbiB0aGlzIGFuZCBtYWtlIGl0IGEgcmVjb21t ZW5kZWQgbWVjaGFuaXNtIGluIHRoaXMgZHJhZnQsIG9yIGFsdGVybmF0aXZlbHksIGEgc2VwYXJh dGUgZHJhZnQ/DQoNCjIuIElmIHRoZSBudW1iZXIgb2YgbWVtYmVycyBpbiB0aGUgZ3JvdXAgaXMg bGFyZ2UsIGl0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyIHRvIHNlbmQganVzdCBvbmUgbXVsdGljYXN0 IG5vdGlmaWNhdGlvbiBbMl0gaW5zdGVhZCBvZiBtYW55IG5vdGlmaWNhdGlvbnMgd2l0aCB0aGUg c2FtZSBjb250ZW50LCBidXQgdGhpcyByZXF1aXJlcyB0aGUgc2VuZGluZyBub2RlIHRvIGJlIG1l bWJlciBvZiB0aGUgZ3JvdXAuIFRoZSBHcm91cCBNYW5hZ2VyIGlzIHRoZSBhdXRob3JpemVkIHBh cnR5IGRpc3RyaWJ1dGluZyBwdWJsaWMga2V5cyB0byBub2RlcyBvZiB0aGUgZ3JvdXAsIGJ1dCB3 ZSBkb24ndCB0aGluayBvZiBpdCBhcyBtZW1iZXIgb2YgdGhhdCBncm91cC4gSXMgaXQgd29ydGgg dG8gbWFrZSB0aGUgR00gYSBncm91cCBtZW1iZXIgYnkgZGVmYXVsdCB0byBlbmFibGUgdGhlIHVz ZSBvZiBbMl0gZm9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgcHVibGljIGtleSBvZiBhIChyZS0pam9p bmluZyBub2RlPyAgDQoNCkfDtnJhbg0KDQpbMF0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzDQpbMV0gaHR0cHM6Ly9hY2Utd2cuZ2l0aHVi LmlvL2FjZS1rZXktZ3JvdXBjb21tL2RyYWZ0LWlldGYtYWNlLWtleS1ncm91cGNvbW0uaHRtbCNu YW1lLXJldHJpZXZhbC1vZi1wdWJsaWMta2V5cy1hbg0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1vYnNlcnZlLW11bHRpY2FzdC1ub3RpZmljYXRpb25z DQoNCg0K From nobody Mon May 4 08:21:28 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A903A0A22 for ; Mon, 4 May 2020 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvDk7p1gvAk1 for ; Mon, 4 May 2020 08:21:25 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 61C023A0A25 for ; Mon, 4 May 2020 08:21:25 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id i10so21412478wrv.10 for ; Mon, 04 May 2020 08:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9FLOZvG2AXK6jdC0S7nIaJDJUEGo2bPPFRfT5kgi4KA=; b=vzrag4JdGM6puIfoFXcyeeCKjdIzYagZH7NDsjSiv5zZC8Yk+Oeh8IqUdBJ0FLKUuM nuVjyJjFFtvO4bWgwBtyDbCEogAb7cT1wtROUFJMpFBTvO5JFA7IEN1k0YtNGvR5b0m8 l29PXxkCkanQPoB8NEuQ9NT7sjPJfTU0pB9JJDev4DOVFMDDQO6Dz7qP801OtS5YJcK/ 2kUV7lk5P16AiQ5661MLmEHKv1HMv5RlDuvKdASW0vq0UfRI/IBdNFqGrUGYBRPp9Zsx M+0NuaxvvK8Do8fnreQSC/A04B0Xmhvjg4qk1Ndjt9+Iv+dPMvpYw7iXPM4DtEfPzKIt D93A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9FLOZvG2AXK6jdC0S7nIaJDJUEGo2bPPFRfT5kgi4KA=; b=iaWLiVyV73U8R0qAX7zZ4ZabdgILWC1ph8+bcQgICjCvihh4ThFoT0MHkD+ZTBRwmo K9JN41Jo2IJCgAmxToNoTgqlaqcZejQrSjZZQvWeKajneiOli7vodlrlVe/QzFzW0VRk kZ+F4pnCI+rWz+ayOYl44UERwiZeezHbMgUZ58puABQ1djLIt7qybxsszN7sa0bKJHtk LV/++L8ro/QLf+uKgJ6MSOmwfy4k73TVCSvZaRAjWHGMvDR2haZ+i2V5JgkVrhXXjVqu usMYDctKepV+yyT1s5yhXys2BzWq0fbukpE1YvBCdTy58/LYZeFdMRA2snEsiMsegl9t aG6g== X-Gm-Message-State: AGi0PuZYTYvQX5ghcKVoJBf2UN0UcUPZb0z69IqCiPqNEFaMSgMAtD7+ LvpRIXvBNbFqXDmPGEdgNWJynfGmC7zPpsgiUgvbPQ== X-Google-Smtp-Source: APiQypKUMMNF+fX0HHwtKX88GHXLjK06JmrJWsYeBkaZzefNqo18qmFPz6I7rRRrz1sxl/7qFiFJqnLi2AQLlQpvZ60= X-Received: by 2002:adf:f8c1:: with SMTP id f1mr8170287wrq.171.1588605683589; Mon, 04 May 2020 08:21:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Mon, 4 May 2020 17:20:57 +0200 Message-ID: To: Carsten Bormann Cc: Klaus Hartke , "core@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000007577c605a4d41584" Archived-At: Subject: Re: [core] Review of draft-ietf-core-comi-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 15:21:28 -0000 --0000000000007577c605a4d41584 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I am not mistaken, Carsten, your suggestion is to mostly use the same paths ("/c", "/s") and just have a few examples with different paths. Do you have an opinion about the wording - do I call the "default" path an example path (keep this currently text unchanged), do I call them suggested paths, so that it is clear that people are absolutely free to choose something else, do we write recommended path with lower case - something that Klaus does not seem to consider acceptable, or maybe there is a different option here? Klaus, is using mostly, but not always, the suggested paths in the examples a good option for you? Thanks, Ivaylo On Mon, May 4, 2020 at 11:18 AM Carsten Bormann wrote: > On 2020-05-04, at 10:42, Ivaylo Petrov wrote: > > > > Section 4: It's not okay to mandate or recommend specific paths like > > and . Not even with a lower-cased "recommended". It's fine to > > define a path structure after the "root path" of the application and > > use an example path in examples, but implementers should not be > > restricted or discouraged in any way to choose a different path (see > > BCP 190). The best choice is probably to use a long, not very nice > > looking path like , so that > > implementers immediately get the idea to pick a shorter path > > themselves :-) > > > > [IP]: I believe I captured what was suggested here, but please check if > that is indeed the case. > > This problem of course comes up repeatedly in a number of WGs. > Here is an example from a position on this as taken in the OAuth WG: < > https://mailarchive.ietf.org/arch/msg/oauth/QH7Mc2gDjONLi58c2g_5nt0UL44> > > I don=E2=80=99t think that filling all examples with noise such as > /path/to/the/data/store is really helpful. > I would prefer to have most examples use the IYDHABI (*) paths, with only > a few alternative paths (all different!) used in some examples. > > BCP 190 asks to ensure the server has a choice, not that all servers must > make different choices. > > Gr=C3=BC=C3=9Fe, Carsten > > (*) =E2=80=9Cif you don=E2=80=99t have a better idea=E2=80=9D=E2=84=A2 > > --0000000000007577c605a4d41584 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I am not mistaken, Carsten, your suggestion=C2= =A0is to mostly use the same paths ("/c", "/s") and jus= t have a few examples with different paths. Do you have an opinion about th= e wording - do I call the "default" path an example path (keep th= is currently text unchanged), do I call them suggested paths, so that it is= clear that people are absolutely free to choose something=C2=A0else, do we= write recommended path with lower=C2=A0case - something that Klaus does no= t seem to consider acceptable, or maybe there is a different option here?

Klaus, is using mostly, but not always, the= suggested paths in the examples a good option for you?

<= /div>
Thanks,
Ivaylo
=
<= /div>
<= /div>


On Mon, May 4, 2020 at 11:18 AM C= arsten Bormann <cabo@tzi.org> wro= te:
On 2020-05-0= 4, at 10:42, Ivaylo Petrov <ivaylo@ackl.io> wrote:
>
> Section 4: It's not okay to mandate or recommend specific paths li= ke
> </c> and </s>. Not even with a lower-cased "recommend= ed". It's fine to
> define a path structure after the "root path" of the applica= tion and
> use an example path in examples, but implementers should not be
> restricted or discouraged in any way to choose a different path (see > BCP 190). The best choice is probably to use a long, not very nice
> looking path like </path/to/the/data/store/X9?k=3D"eth0"&= gt;, so that
> implementers immediately get the idea to pick a shorter path
> themselves :-)
>
> [IP]: I believe I captured what was suggested here, but please check i= f that is indeed the case.

This problem of course comes up repeatedly in a number of WGs.
Here is an example from a position on this as taken in the OAuth WG: <https://mailarchive.ietf.org/ar= ch/msg/oauth/QH7Mc2gDjONLi58c2g_5nt0UL44>

I don=E2=80=99t think that filling all examples with noise such as /path/to= /the/data/store is really helpful.
I would prefer to have most examples use the IYDHABI (*) paths, with only a= few alternative paths (all different!) used in some examples.

BCP 190 asks to ensure the server has a choice, not that all servers must m= ake different choices.

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

(*) =E2=80=9Cif you don=E2=80=99t have a better idea=E2=80=9D=E2=84=A2

--0000000000007577c605a4d41584-- From nobody Mon May 4 10:42:03 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8D63A0DCB; Mon, 4 May 2020 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcHgwAF3Uqyy; Mon, 4 May 2020 10:41:54 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 00B2B3A0DCE; Mon, 4 May 2020 10:41:18 -0700 (PDT) Received: from mail-qt1-f177.google.com ([209.85.160.177]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jVf5d-0007Yx-5O; Mon, 04 May 2020 19:41:13 +0200 Received: by mail-qt1-f177.google.com with SMTP id g16so175509qtp.11; Mon, 04 May 2020 10:41:13 -0700 (PDT) X-Gm-Message-State: AGi0PubLtwGUaKbUVsKYqxNsQgo22erPQCaHAdexM/4LdXVli68Knnjx 1gQPo8abMmG8z1w/IseduG9uR7T8AtWTY1R3MMw= X-Google-Smtp-Source: APiQypKHzeW3TV0ugJZrZ3BwEQ3GBnpnw9g2Ac1qLZBsbZwpm51YWYn35mS11xqouywefP1VoPIBhe0yE1mUVZO0YIA= X-Received: by 2002:ac8:51cd:: with SMTP id d13mr254349qtn.174.1588614072019; Mon, 04 May 2020 10:41:12 -0700 (PDT) MIME-Version: 1.0 References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> <20200503224625.GF27494@kduck.mit.edu> In-Reply-To: <20200503224625.GF27494@kduck.mit.edu> From: Klaus Hartke Date: Mon, 4 May 2020 19:40:39 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Benjamin Kaduk Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-stateless@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1588614079; 4bb4f30e; X-HE-SMSGID: 1jVf5d-0007Yx-5O Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 17:41:57 -0000 Benjamin Kaduk wrote: > Klaus Hartke wrote: > > Benjamin Kaduk wrote: > > > Section 3.1 > > > > > > o A client SHOULD integrity protect the state information serialized > > > in a token, unless processing a response does not modify state or > > > cause any other significant side effects. > > > > > > If the intent is that the "does not modify state" clause is the only case > > > when one would disregard the need for integrity protection, "MUST [...] > > > unless" seems more appropriate. (I would prefer unconditional MUST and am > > > not sure I understand the cases where there is a need to skip integrity > > > protection.) > > > > The intent here is that a client must do integrity protection, but > > there may exist valid reasons in particular circumstances to ignore > > this requirement. In this case, the full implications must be > > understood and carefully weighed. > > > > All of the circumstances that come to my mind here are those where a > > modified token doesn't actually hurt. For example, if a client sends a > > request to some server at regular intervals, it might only be > > interested in whether the response has an error or success code and > > not even deserialise the token. > > > > What's the best way to capture this? > > Before I get into suggested text, I want to check that I understand the > situation properly -- in such a case where the client is not even > deserializing the token, why would the client not be able to use a regular > token and not look at that token's value? It doesn't seem like the client > is gaining anything from having the serialized state available. > > Your description makes it sound like we may have to just do "SHOULD > integrity protect" without the "unless [...]" clause. Hmm... the top-level section is about clients that avoid keeping per-request state, which a client can be regardless of whether it uses <=8 byte tokens or >8 byte tokens; but this sub-section talks about serialized state, from which indeed the client doesn't get anything if it's never deserialized... Maybe the best way forward is indeed to use SHOULD with the "unless [...]" part... If we change to MUST, then I can already anticipate people complaining that in their particular use case any integrity protection is just wasting precious bytes. The SHOULD would take care of that. And maybe we don't have to go into detail under which circumstances it might be justified to ignore this SHOULD. OLD: o A client SHOULD integrity protect the state information serialized in a token, unless processing a response does not modify state or cause any other significant side effects. NEW: o A client SHOULD integrity protect the state information serialized in a token. > > > o Even when the serialized state is integrity protected, an attacker > > > may still replay a response, making the client believe it sent the > > > same request twice. For this reason, the client SHOULD implement > > > > > > (Basically the same comments about "SHOULD".) > > > > See above. > > > > This section is about protecting the serialized state, but of course > > the requests and responses need to be protected as a whole as well > > (e.g., using DTLS or OSCORE). In some circumstances, receiving a > > replayed token might not hurt if the client can verify that the > > response is coming from the right server. > > Presumably the same cases where a replayed response from the right server > would be tolerable? Such cases are ... rare, in my opinion. OLD: o Even when the serialized state is integrity protected, an attacker may still replay a response, making the client believe it sent the same request twice. For this reason, the client SHOULD implement replay protection (e.g., by using sequence numbers and a replay window), unless processing a response does not modify state or cause other any significant side effects. For replay protection, integrity protection is REQUIRED. NEW: o Even when the serialized state is integrity protected, an attacker may still replay a response, making the client believe it sent the same request twice. For this reason, the client SHOULD implement replay protection (e.g., by using sequence numbers and a replay window). Does it look OK without the "unless [...]" parts? Klaus From nobody Mon May 4 11:12:03 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74333A1019 for ; Mon, 4 May 2020 11:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPpZLFtNieX9 for ; Mon, 4 May 2020 11:11:59 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 F06403A1005 for ; Mon, 4 May 2020 11:11:57 -0700 (PDT) Received: from mail-qk1-f182.google.com ([209.85.222.182]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jVfZM-0002kv-1r; Mon, 04 May 2020 20:11:56 +0200 Received: by mail-qk1-f182.google.com with SMTP id f83so438741qke.13 for ; Mon, 04 May 2020 11:11:56 -0700 (PDT) X-Gm-Message-State: AGi0PubPBmK0qAUUrAg6geekMM/M30IuOl5R9AUHNtvXvCyyZY05vkd7 pLibAHmGHtHD1Mm5kYmkOggofogB0oB1riWUiDw= X-Google-Smtp-Source: APiQypKRjw90DDZ7DdUw9T5UdealD3IXxWkuV9GI7aoBC6XnLJY7mvdbtQ9nuTeV9eKE95PLDhUTBOoEyGEY2qNxBMI= X-Received: by 2002:a05:620a:13c6:: with SMTP id g6mr437604qkl.453.1588615914773; Mon, 04 May 2020 11:11:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Klaus Hartke Date: Mon, 4 May 2020 20:11:22 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Ivaylo Petrov Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1588615918; b0e0659e; X-HE-SMSGID: 1jVfZM-0002kv-1r Archived-At: Subject: Re: [core] Review of draft-ietf-core-comi-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:12:02 -0000 Ivaylo Petrov wrote: > I have changed content format to content type in all places where such a change seemed necessary. Please do not hesitate to let me know if I have missed any place or if I have misunderstood you. Hmm... I think in section 2.4 you're actually talking about media types, not content types. (I know it's confusing! Have a look at https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-01) >> Section 4: It's not okay to mandate or recommend specific paths like >> and . Not even with a lower-cased "recommended". It's fine to >> define a path structure after the "root path" of the application and >> use an example path in examples, but implementers should not be >> restricted or discouraged in any way to choose a different path (see >> BCP 190). The best choice is probably to use a long, not very nice >> looking path like , so that >> implementers immediately get the idea to pick a shorter path >> themselves :-) > > [IP]: I believe I captured what was suggested here, but please check if that is indeed the case. Hmmm... maybe wasn't the best idea. Some examples now overflow the page width. And it's a bit difficult to see where the free-to-choose path segments end and the standardized path segments start. Maybe ? BTW, in examples I think should be or . looks like a relative URI where the first path segment happens to contain a dot. In see in some tables and examples still being used. Is that intentional? I think it would be better to use the same path prefix everywhere consistently. (At least the text should point out what free-to-choose path segments are used in examples.) >> Section 4: The document specifies the API in terms of the CoAP >> Uri-Query option a lot. The Uri-Query option is just the way how the >> query string of the request URI is encoded in CoAP, though. It would >> be better to specify the API in term of query strings and not to >> mention the Uri-Query option. >> >> Section 4.1: It's unclear if a client should send the query string >> or (with quotes, as shown in the table) for a Boolean >> value. > > [IP]: I believe now this is clear. It is now also clarified that 0 maps to false and 1 to true (which might not be what a person using a lot of bash would expect). The text now says: o The method int2str() is used to convert an integer value to a decimal string. For example, int2str(\x01\x23) returns the three- character string "291" (the quotes are added for readability, but they are not part of the payload). Why does int2str now take a byte string as input? And I think one of "the three-character string "291"" or "(the quotes are added for readability, but they are not part of the payload)" is enough, you don't need both :-) Proposal: o The method int2str() is used to convert an integer value to a decimal string. For example, int2str(0x0123) return the three- character string "291". The text now says on Booleans: o The boolean representations (0) and (1) are the single character strings U+0030 and U+0031, where false maps to (0) and true maps to (1). Why not just something like this? o The boolean values false and true are represented as the single-character strings "0" and "1" respectively. Then the text now says: The resulting key strings are joined using commas between two consecutive key values to produce the value of the 'k' parameter. That's a good clarification. The string value of the 'k' parameter is encoded in a Uri-Query as specified in [RFC7252] section 6.5. It seems after "Uri-Query", the word "option" is missing. I think I'd just omit this sentence, though. It should be clear that query parameters are encoded as Uri-Query options in CoAP, no? Klaus From nobody Tue May 5 09:46:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814DB3A09BA for ; Tue, 5 May 2020 09:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b_Wi3Ygogt5 for ; Tue, 5 May 2020 09:46:30 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041E73A0933 for ; Tue, 5 May 2020 09:45:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nf+05pNvZmSxCIeLN6ziJKcc0CNnSoSKd9CBbsUMxyDMsVTSUa8TsQDAEEDzYbwGfoicHAw66Ita4ytQjvyDLzxz5zbN1Ox/IbqsEssjXKuIHMGejF7S3TCzXnT8fZLm3vrCiGxAzMZMT+N0UhtfIp/s0r0Vt5NdYLbCxkDfniUZFQEOVoOs7MNnQlSpEhWECs+0XmhP1ZCze8Iw7DpFYHfTbHraSZ2IxkWHqm9qGHVSI8WpXDUzw67QXesVehtku921rCcBxFcv7susoK+X4H7rVn6qnLmEdTEL14Hbl/cVsZi1HH/8tDFfDMIWtimjWepV0tHY9Yk78GjdGaGaBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5rzSR/MNjVD1OjDKnSDkmAIsxwr0XRDGNvaZWwo6b5Q=; b=W4QUTbo/d3E5WA4bvo56oLajvPsM7Ksqr216xzRw66z+oiKNN8dcrI3E66yDjwvFaInwfEo3J93ZDrWbfeOspL6yjgho9fFiNrGNx8mvV7W+8OOaotF0TFqCdUFTmi7yQ9nU4KbXsJTwHTMpoSAkURYrCkTtVfa/aPGqxh0IsfledwbD+gaoSgxzjhlAw/Z0YWpsemP07z2HS+5Lx7iPPxrZEmaRWeiCTIYtkZyfWLVj1/E5cnjVIDCTFiM0jSfIexgAuBBRej0UI57hzEjGtBrc+QeEjuLdZ4FTKs8/vJZfo6elD0gxBnMfgMnECG0obme+hOCg9nD+Sa6vJ0T6fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5rzSR/MNjVD1OjDKnSDkmAIsxwr0XRDGNvaZWwo6b5Q=; b=kkvgefx2ukSEewwfCskyM9EA1/IJo5uyNNYbbaFPfKmyDhc/qZJyUPVkL6exxXXedJJfcV8FpaKbqGroglbyNWrDqpoIEWsYzMOGTq1CesQSbrfWFHY95BwWRY2scSP0m03E4I1GX834vyx+0syMbmXe6jDrCy9TtjeVD/+FC/A= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0431.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Tue, 5 May 2020 16:45:45 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2958.030; Tue, 5 May 2020 16:45:45 +0000 References: To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: Message-ID: <10bd7386-e5c4-dc9d-018d-6d0a563822f3@ri.se> Date: Tue, 5 May 2020 18:45:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OEW4pjS4xafEhbpqdZJ0Hwi1l056etwiD" X-ClientProxiedBy: HE1P189CA0011.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::24) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.2] (185.236.42.79) by HE1P189CA0011.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20 via Frontend Transport; Tue, 5 May 2020 16:45:44 +0000 X-Forwarded-Message-Id: X-Originating-IP: [185.236.42.79] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4e834d3f-5c9d-4b45-fb64-08d7f113c15b X-MS-TrafficTypeDiagnostic: VI1P189MB0431: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0394259C80 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JJAMOEy3wwbyvLBN5HRmwaj/dffrAYwjoUYgd70VQVhXNUTuEZ3BZnD9f15NQ26WBSoTFzy0OiVhU7ZTmrzthzQW6TeHTCHr/GhpZvLuQXoB1u9x5HZz0gF9gq0yKpuO8Hvpuk3zalKJj34kla+Hvfkc4uLTLF8+xGd2BfoAZ45+1NZCD4u0a+6T5DPrXnVtelGY0yUfhDSKX3EZuIoiPJl4xEBbbhDP8DWz0cjrW9gwPgTGXndD4307pAgl0C8p2AWSXaPMqTQdUHF4nieVedwrqjQWaLlt6nUJHQ5quHyRhWAKidYSUljpnO4QzH/HlTHdKDkOVnyqErdJOaknp86P1+TfVOlGEciwp4c7x4D7hwUiDLGlw/mNd206fuSyH8EU1Mtw3mr97JVARJ3Afuhg5FdZ6LEo6RDZNQK+xrBOUWoUMmcotxcoKgdSuDT9DpVhDWW54WkDYWH5OYM6V9UEaEy6d0r1jWP9l0F5QzaYLjsGKxWyM94RNLO0BTUt4w2SJ9D7FnGmRW7s1lH8SIj6spbia5FFGOOJ98r7P983Z1t5olWEhHee3yXgdAUuqxxdgEV6X+iOGpVciJulgKgbf4V4jSh3RkBal/dHbXJVA66hRZVoykuZsYPxAT+M+ebEcBglZ31jqwVvKIFqQw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(33430700001)(31686004)(66946007)(8676002)(66476007)(2616005)(16576012)(44832011)(956004)(36756003)(2906002)(8936002)(66556008)(235185007)(26005)(33440700001)(966005)(52116002)(498600001)(21480400003)(31696002)(86362001)(5660300002)(6486002)(6666004)(186003)(16526019)(6916009)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: EMGWX+GdstE1kQ4oduI6yFxUIg3ssKsZptPpROUb29VDv4R11ukqclXiUL5i+dpA2mEJYZhTLgoee4r3+KBO0erFBRXkq+RfBM81RlE7o57F9DBPKijxV/MKprf+LNTHQaO4TEmavG/SWryVZWw/YDQqhgTjjKjI0wmhYOmH6Raok/rxHROZgKQcr0b9HjX0VHoT3qsXkndVCxaMBRsnQ6P4zf7BtUnZdYniqRM0L23/rW1SMBGuOeBNnEd04giPuIFfL3jTfUS+5skBJm8bxY+s70JZoPTjPqwYFkJui/WSEV5qNDZJkhenpWqNEP6d53itC0IgCkqRCt3bbyjqwdKVdxH7A8hQuJeMqKthnNA5GC//tcFJ83ojXWXMSt5/8LPuXvmjV6uEI3Qikbe60ObBjEhYXanhO3c9VZ9UFrIRzpRytzKTc6ITybbjRScN1NgImUxC2nCCRmaJNahfri+3mTLuTK/lmTEmnlaWk4tdZ50YFXKF7d8TXQqTnKx0pqUzFBhIbiLYjKnkKQxnSlW06gpHipfiksVzrN3SknmqIPXuBZEeXlUqjn5g6M1/GH3qmJ466msSWNUHXbtZMV4f8d0XsAaWfL3cptVRHMaEGuLDIBoT11eGfNuDlTZ7u/B/LsAqlgFCE54vEwSBnbcKf1s7Na7cueFacvAhABkpRkALRU1Pbi9K0+ArYopLJeRf8yPaM91s33F6ig2HFL2BMNwbAVSflkF58Z16TCw9onA2ocJuKGUcAk6CslWV6fr3SDh2a2p/74HUbhe/czjI8KzCJYGrqLadIJqYPME= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 4e834d3f-5c9d-4b45-fb64-08d7f113c15b X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2020 16:45:44.9236 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PEqlSwRSJwu7vr4wOfRLlUiHeonva5K/YvrUvWojT4s0vO5KB3MVT8eOqToAoyFcbr6AWHxnkfu5nm8qjWR7hQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0431 Archived-At: Subject: [core] Reminder: Survey on planning for possible online IETF meetings X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 16:46:38 -0000 --OEW4pjS4xafEhbpqdZJ0Hwi1l056etwiD Content-Type: multipart/mixed; boundary="MhM3pW8csA2dMFkkdXQ8IN0UAoNHSu3G0" --MhM3pW8csA2dMFkkdXQ8IN0UAoNHSu3G0 Content-Type: multipart/alternative; boundary="------------DD89B792DF5922616934B3EB" Content-Language: en-US This is a multi-part message in MIME format. --------------DD89B792DF5922616934B3EB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, Please, participate in the survey below. Results will be very important for planning future IETF meetings. Thanks, /Marco > Begin forwarded message: > > *From: *IETF Executive Director > > *Subject: **Reminder: Survey on planning for possible online IETF > meetings* > *Date: *May 4, 2020 at 3:03:35 AM EDT > *To: *"IETF Announcement List" > > *Reply-To: *ietf108planning@ietf.org > > This is a reminder that we need the IETF community to help us plan for > the possibility that one or more upcoming IETF meetings in 2020 and > possibly 2021 may not be able to go ahead in person. =A0You can help us= > with this by filling out the following survey: > > https://www.surveymonkey.com/r/5328FFJ > > So far we have 114 responses and we would ideally like 500 or more. > > The survey contains the following pages and will take 15-20 minutes to > complete: > > 1. Welcome > 2. Online IETF 107 and the subsequent virtual interims > 3. Replacing a cancelled in-person meeting > 4. Online meeting format and timezone > 5. Replicating humming > 6. Replicating the hallway environment > 7. Fees > 8. Thanks and anything else > > We run the survey in anonymous mode which means that we only see data > that you explicitly provide. > > Thank you in advance for your help. > > --=20 > Alissa Cooper, IETF Chair > Jay Daley, IETF Executive Director > Colin Perkins, IRTF Chair > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --------------DD89B792DF5922616934B3EB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all,

Please, participate in the survey below. Results will be very important for planning future IETF meetings.

Thanks,
/Marco

Begin forwarded message:

From: IETF Executive Directo= r <exec-director@ietf.org>=
Subject: Reminder= : Survey on planning for possible online IETF meetings
Date: May 4, 2020 at 3:03:35= AM EDT
To: "IETF Announcement List" <ietf-announce@ietf.= org>
Reply-To: ietf108planning@ietf.org

This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. =A0You can help us= with this by filling out the following survey:

= https://www.surveymonkey.com/r= /5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting
= 4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you explicitly provide.
=
Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listi= nfo/ietf-announce

--------------DD89B792DF5922616934B3EB-- --MhM3pW8csA2dMFkkdXQ8IN0UAoNHSu3G0-- --OEW4pjS4xafEhbpqdZJ0Hwi1l056etwiD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6xmC8ACgkQ7iZktA5Y 2kMebAgAkUzMaxYWRdF+ObxPzmTQOdyyXioKvTUi99GNyMMVYIEc6bw/2MvTiL4O nVy7M/fwXrHDUNUqdESBRSPoQAHj0Nep/8NP/gjnkhUV7EvOzsqan6Sa7oC3vcTt +P2rDtXlEBV3kUVBbLqd1DseVarx1GDjoF5VbinUCCLLT+ZA2ES5zjtHzpadakIX G9gWgIqjU4ZJyz97S9UoTa1zivi3GML/COEFAUjXIisVXBPoEtSObAHJV+e3qybx 2Qoac2C1upIk4MgCGRvaxWmYdV56fWcf06tYva6MtdK5n9/yc2o8HjUnHYzAqU2x XrrhiHD2cGfzfJ4mmnWtI3tr2+bt7w== =sPb0 -----END PGP SIGNATURE----- --OEW4pjS4xafEhbpqdZJ0Hwi1l056etwiD-- From nobody Wed May 6 03:43:59 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B313A0932; Wed, 6 May 2020 03:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EY95BxtZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=og6tyKwF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idZ5MdFcTDya; Wed, 6 May 2020 03:43:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C8F3A0894; Wed, 6 May 2020 03:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2455; q=dns/txt; s=iport; t=1588761835; x=1589971435; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OiO7Noju3+Mq7NgAXsR9oMyowjbTe/pfRpRH6NgVJp4=; b=EY95BxtZOl1r/v0TKSBABDcIIvADNivWLl4mlQdntrsrZFvd5jJ7eVaV GcXuPJh4Yw8SEWrwtwaRbFwHNucCkrwDrXdfl+FPHUSnSC1f9NdJqXh8m zsShGnOLrsxkChJknKbhHUMfb/Ip4oDvVYFVlF9f6SPLqwetlLpgizuLF U=; IronPort-PHdr: =?us-ascii?q?9a23=3AgyqqIxWjVPLefkIdIBpTeHR34qTV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuDwBNlLJe/4oNJK1mgQmDG1EFgUY?= =?us-ascii?q?vKgqHXwOLNZpGglIDVAsBAQEMAQEtAgQBAYREAoIBJDgTAgMBAQsBAQUBAQE?= =?us-ascii?q?CAQUEbYVWDIYKKAYBASkPEQE+QiYBBAEaGoVQAy4BA6h4AoE5iGF0gTSDAAE?= =?us-ascii?q?BBYUkGIIOCYE4gmOJYRqBQT+BEUOHW4NDgi2yVQqCSJgznSCQF50cAgQCBAU?= =?us-ascii?q?CDgEBBYFpIimBLXAVgyRQGA2UNIpWdDcCBggBAQMJfJA6AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,358,1583193600"; d="scan'208";a="766687812" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 10:43:52 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 046Ahqux005973 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 10:43:53 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 05:43:52 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 06:43:51 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 06:43:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j2UK4t+vgigTOMAWbPjapuZLBDsDAPqIo+aHRzfr0nayu71892suJ+aO/Y9rud7Kf7ZNfmxXJ19BE9FbMJJclmCqwsLY4WJD1NQwg67QtE9FWdfqr5t93EeRqQlnzppwkWl5c+T6mtylwBziJogb7ve7oUQEi8g4KGwvj9ih9iKVDEJrCDt5HIW/jvwrVFhhjuf19SMnCBOqOKqsLAx2e0tDeBnrtIfd02nBCLX1rykeWeMZfoMkEvkTvVlM51DLZAs+Xsf2L4lMWVfYjxDx8kXCKL7ehNbgqWjRRhN/p5MXASJKNOIKsRRi7CWxO5hzwWt6rH8WtZPJifqgKk9Gng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2hyN6Ks8An4SFJGsZ8VcrVMhbwt17RuVX7fPpfygCKo=; b=ATUfiS74xQ7DMdCbFrUrJX9VyG+yXhJdBt1s1iqYfPVSNtZurIqlP7PinzudxsurLA4tj2AZr4hNAQMKOL+0SsBxYFVK9nWP5QmjcF45OCaTlI8rq0zy4q+nscjJVw+k+gZvy028QSjqUBD5fNIu/aIkQrzb7kcjOhcPmsmzBdlx/8SVTlr19noHHZ6QlL+HEiwXf6QG6Gev5BNQXPe2Qai3+LlpmGo+/d1+G5uOsDvD1ko/TAOe2x4T2ljXpfUQbY4c6ZLpKv7Sg/BlYmwrCyaEGx9sHeGI/li+VNJG2P/I6i7OK7omsPYHQ0Smssc+zuA8o5iblpbZcwqk6R0/6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2hyN6Ks8An4SFJGsZ8VcrVMhbwt17RuVX7fPpfygCKo=; b=og6tyKwFDrSWzW3t4y56vaiBLxyivmTlfUm1+kL633JosWKKz8Y6PypLmNDZFXfncbgYhh1kis5tEBBZrR71eONH8K0Pjxz2/vZAo5eKbMl944qB4XzmdE/Pb9Ymf8WpBjl5HXeTUc996/AJfQfIIu3NGl5tq+ObKLFLWc4kFEk= Received: from BY5PR11MB4355.namprd11.prod.outlook.com (2603:10b6:a03:1c3::13) by BY5PR11MB4338.namprd11.prod.outlook.com (2603:10b6:a03:1c8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 6 May 2020 10:43:50 +0000 Received: from BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::6911:81bd:3157:eeff]) by BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::6911:81bd:3157:eeff%7]) with mapi id 15.20.2979.028; Wed, 6 May 2020 10:43:50 +0000 From: "Rob Wilton (rwilton)" To: "core@ietf.org" , "netmod@ietf.org" , "draft-ietf-core-yang-cbor@ietf.org" Thread-Topic: CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] Thread-Index: AdYjjRJSrAgzJqA0Rj+Yt5Eb1SoE2w== Date: Wed, 6 May 2020 10:43:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f0c66cd-6326-4c80-3f64-08d7f1aa5d19 x-ms-traffictypediagnostic: BY5PR11MB4338: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3nnNQjf9o7kwodAugClrycZ0KvXfbbYrjoE15Gpl8vCAJl/EH7XYAdynYUdMND7nPqCuhKPVhhulQdXlR2q3Xa/qQCmmXD2irj8gB/u+H4ASy5nDNGKQnafhqqLmYR997Murqk4N0zx/nStnL1nRkmp7KvMdW618MqsMLLH9Wm6N+/uSlfYcwGI20cFUICKE3BDOO382vkBXI19eweuhWIKRND2NgD7IFcnv/DiVwXzckjDj6kIUxRFJBtczXoH2EGTYUTiNavlQv1FpL/gAnga4vUcjhX8aqVPawZ8uRuAHM1AiSIv0jvaxvxuv3SzhN0cjkE8KInSGF/hZXWuxdQbwp+fmDh2AcZgnK8Nl1eDjy24/wyDVqj5qFLUGP7HN+1IK4I4FPDZY5q24cr52wVUprfq+7HyQ/2GTTOAw7UwtEgUt5xSJntolsOyb+8WJ87frB49qx1wwpSleOju5Sf9+q5RCThLCZzwwf9/F0qZ5HkrTMShXNO9DTN1kdLlo8IpjTpVRdpQG/s1+bouNzQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4355.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(33430700001)(9686003)(66446008)(8676002)(5660300002)(64756008)(7696005)(2906002)(66946007)(71200400001)(66556008)(26005)(66476007)(55016002)(86362001)(76116006)(186003)(110136005)(478600001)(316002)(8936002)(450100002)(6506007)(52536014)(33440700001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mQwzJutiLwj2p6RXBcxX7atMw7bKOyMDUCShQaDEsNMfEA4qpxZtlukyg/eKgyWMi2UxrPayWjJyydpi4fVQnO537TXWGGJtq45BEfkogI6Av8iWibRTgQj1mIPX+KMZsAa0p7rDmkxdDNX3Fo4S/bLcNb72QOYZX4yq+LUzC4okhAfYTMiueq0rJuRe1wVx+WwaRZmSUbpM8KUCuzuL0jyh4tp1XPsub+GJRiX0TeczTMXXmL39Sd8SwNqm4LKlh8SeH3jX4zx4pcULclv5YPCYgz3Fm4+zNlZ8y4NVpYhf6M1a6sldqh/6yMN23Eca51rCAiL4GG5R899/e5h8EapiULyZJ2gq7HNUcTdTHz/UMkrX0NSOhhLnnOD5MWyMGrdmOkyV4GrDgDbTNHEMRnmrKXN4UMSI0B0K7xF43ipGSSSOgOtdyiZss61Ev1a+XSQYi4Ag0kjESsf3C9Gv8dYDyMwe6ElkT4Wv00iCbiJL13zHn/kjuKGr2mrZHA90llr37iRkk4A3pOOz1Q6p2w1rKIhLBNPaJ1Lsvi9owwFv8/WdXfPPac2SjFETXkJxJ/60WEtb4MsL8qazQXVLQ4u5oSsnqVJ8WOeOMNEHktSsiTiTHyxscq+rqCl0Vb256RTjVqckYo5g2xKhgTS+m2t7wasj3nAvoIoH5Ff/UtaY5LU2k+whhVMQHSSddaom7kF8yierNUTYjE70fJTFkhlCYr38gGbKEvn9ic962R/nzi1Jwt54l/GlAXcKCBRd4z9K5Ab4Z92mV5aqy0s25SRY14NyGkI6Nkl4NE711cU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f0c66cd-6326-4c80-3f64-08d7f1aa5d19 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 10:43:49.9617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +tY5AnCKFfnkizA66lVuEHBbLDuyJUo9uA6NydJCS9uf2LYFqKVPDICMTYI4Sri3bNkAjoTzqUCh/iW38EW8xw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4338 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: [core] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 10:43:58 -0000 Hi, [Cross posting to Netmod for wider YANG expertise.] I had a couple of questions on the CBOR YANG encoding of bits and unions (b= ased on draft-ietf-core-yang-cbor-12). Apologies if these have already bee= n discussed/closed in the WGLC. 1) Regarding the encoding of the bits datatype: [draft-ietf-core-yang-cbor-12, section 6.7] The CBOR YANG encoding of the bits datatype is defined as a byte string enc= oding of a bitfield. However, my concern here is that YANG bit positions a= re allowed to be up 2^32-1. E.g. the following, pathologically bad, bits definition would seem to have = a very inefficient encoding in CBOR: typedef alarm-state { type bits { bit unknown { position 4000000000; } bit under-repair; bit critical; bit major; bit minor; bit warning; bit indeterminate; } } How much should we be concerned about this pathological case? Would it be = reasonable for implementations to reject bitfields larger than a small set = size (e.g. perhaps 256 bits)? Or, if it is supported by the language then is it reasonable that implement= ation SHOULD support it? In which case I think that we might need a second= encoding of bits that supports this pathological case. Perhaps an array o= f 'set' bit positions, or alternatively the union string encoding of bits c= ould be used. 2) Regarding the encoding of unions: I was questioning whether the special encoding of bits type within a union = was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. Am I rig= ht to presume that this is to ensure that the CBOR encoding of unions is al= ways at least as specific as XML? If so, this seems like a reasonable desi= gn choice. But that leads on to these general YANG questions: Should the value encoding of a YANG union type behave the same way regardle= ss of whether the encoding is XML/JSON/CBOR? Or is it reasonable for there= to be differences in the case of conflicting values? Perhaps this is alre= ady answered by RFC 7951 that can behave differently from the XML encoding = of unions. Longer term, should YANG be looking for a discriminated-union type? Or per= haps it would be sufficient for tooling to flag up potentially ambiguous un= ion definitions, particularly those that may be encoding dependent. Regards, Rob [As an individual contributor] From nobody Wed May 6 05:19:20 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7113A09ED for ; Wed, 6 May 2020 05:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB05PlR-8K9D for ; Wed, 6 May 2020 05:19:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACEC3A09D2 for ; Wed, 6 May 2020 05:19:08 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49HFy23Jl5zyd9; Wed, 6 May 2020 14:19:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> Date: Wed, 6 May 2020 14:19:06 +0200 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 610460346.006689-4da5f37beb2552bee36325afb5689c4b Content-Transfer-Encoding: quoted-printable Message-Id: References: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] HREF compression encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:19:14 -0000 Hi Jim, This is an interesting proposal. Klaus and I had a chat about it now, which led to the following straw = man grammar: CRI-Reference =3D [ (?scheme, ?(host, ?port) // path.type), *path, ? (QUERY, +query) ? (FRAGMENT, fragment) ] scheme =3D ((SCHEMETEXT, text .regexp "[a-z][a-z0-9+.-]*")=20 // COAP // COAPS // HTTP // HTTPS) host =3D ((HOSTTEXT, text) // bytes .size 4 // bytes .size 16) port =3D 0..65535 path.type =3D 0..127 path =3D text query =3D text fragment =3D text SCHEMETEXT =3D -1 COAP =3D -2 COAPS =3D -3 HTTP =3D -4 HTTPS =3D -5 HOSTTEXT =3D true QUERY =3D -6 FRAGMENT =3D -7 Obviously, the specific marker values we use could be shuffled a bit, = but it seems we can cover the entire spectrum that is covered by the = existing syntax. There are a few things that need to be decided base on perceived = frequency of use (e.g., are text-valued host names the likely or the = unlikely case =E2=80=94 depending on that, the marker is placed on the = host text or on the path sequence, or the absent host could be = represented by `false`), so we should come up with some rough = estimations here. Comments welcome... Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-22, at 20:20, Jim Schaad wrote: >=20 > I had a slightly different proposal to what Klaus presented at the = last interim in terms of doing href compression. It is based on the = fact that URIs have a relatively fixed pattern and keeps the CBOR coding = directly rather than moving to some type of binary encoding. > =20 > The standard pattern for a URI is scheme://hostname/path/path/=E2=80=A6 = Using this for compression purposes by removing all of the tagging = which keeps to the same pattern you would compress = coap://example.com/foo/abc=E2=80=A6xyz to > =20 > [ =E2=80=9Ccoap=E2=80=9D, =E2=80=9Cexample.com=E2=80=9D, =E2=80=9Cfoo=E2= =80=9D, =E2=80=9Cabc=E2=80=A6xyz=E2=80=9D] > 1 1 1 1 2 =3D 6 bytes of padding > =20 > This is the same amount of padding as his binary compression method. = There is a slight loss over his method when you want to do port numbers, = queries or fragments as they would need to have a integer tag inserted = so you get > =20 > [ =E2=80=9Ccoap=E2=80=9D, =E2=80=9Cexample.com=E2=80=9D, =E2=80=9Cfoo=E2= =80=9D, =E2=80=9Cbar=E2=80=9D, Query, =E2=80=9Ca=3Db=E2=80=9D, = =E2=80=9Cc=3Dd=E2=80=9D, Fragment, =E2=80=9Cgohere=E2=80=9D] > 1 1 1 1 1 1 1 1 1 = 1 =3D 10 bytes > =20 > In the binary encoding this would only require 9 bytes > =20 > Moving to an IP address adds no additional padding as the difference = between a text string, a byte string of length either 4 or 8 can easily = be detected. Relative URIs are encoded using similar tagging so you end = up with > =20 > [ Absolute, =E2=80=9Cfoo=E2=80=9D, =E2=80=9Cbar=E2=80=9D ] > 1 1 1 1 =3D 4 byte > =20 > [ Relative, 2, =E2=80=9Cfoo=E2=80=9D, =E2=80=9Cbar=E2=80=9D ] > 1 1 1 1 1 =3D 5 bytes > =20 > Using the binary mode these would be 4 bytes and 4 bytes respectively = (I think as no examples are in the slides) > =20 > I believe that the advantage of this proposal is that there is no new = encoder/decoder needed as this is pure CBOR. The compressed outputs are = of similar lengths as the binary version and processing them I believe = will result in near identical code sizes. The code to do absolute and = relative processing as well as generating CBOR options is going to be = very similar. > =20 > Jim > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed May 6 06:31:30 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E573A041C for ; Wed, 6 May 2020 06:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Kkye+cMk; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Kkye+cMk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V2BzuU4_8i3 for ; Wed, 6 May 2020 06:31:24 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2081.outbound.protection.outlook.com [40.107.20.81]) (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 43C143A0405 for ; Wed, 6 May 2020 06:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=grCXOvYs7EH7OWhpc19oeZRd+S07R2ZUHtP1w1DeKfM=; b=Kkye+cMkxerZrNg1oSKos7tjrBWGQEy1IS61hBLVF+aHQbBLwcyAKNOLVSo16DUHplkrSzN8hJmloRBUcHwqiaDKaHn6463EWBOkVz+704ZKKt8dWkuc9atImpuFr7VhCJ5R6OKQlVraIvd6v1yjGFosQaPw8SI+Pll6nzAuC08= Received: from MRXP264CA0037.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::25) by VE1PR08MB5262.eurprd08.prod.outlook.com (2603:10a6:803:106::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.29; Wed, 6 May 2020 13:31:21 +0000 Received: from VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:14:cafe::73) by MRXP264CA0037.outlook.office365.com (2603:10a6:500:14::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28 via Frontend Transport; Wed, 6 May 2020 13:31:21 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT050.mail.protection.outlook.com (10.152.19.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Wed, 6 May 2020 13:31:20 +0000 Received: ("Tessian outbound e88319d7ccd0:v54"); Wed, 06 May 2020 13:31:19 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 81b202fc56f90a56 X-CR-MTA-TID: 64aa7808 Received: from f63ef915baa2.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 21417B4A-21C6-401C-A751-063B2FE7318E.1; Wed, 06 May 2020 13:31:14 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f63ef915baa2.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 06 May 2020 13:31:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YRA9xj+70+0Fr6nYvKDDf+sdqykfIX586LUj3ZKlB6Fn4gJ1ifdC9mk4KI5q8Q7bYrW+y7s6b+PntIWw2dQVGGYp4f/gSRiPTNSfv3uLsQghaUgeGCBoO0nbe14UJ4l3PCmMYEZOE4yGtfGIJ+EJLVabbCmi4K1R/9iBt4vYaNdQuYiYa5YaNYXD9lfH2d2wvHJXfIe8DoiHDpwEKxKc1pkaWcmM/DOll2XXO7hlxj1IPGxyCJAFDAe/e573SNquJcSm5IP2chzeJv7QTV1Uj/PsUC+NM6/chZ3NYc0me7zSA8Jqu4mRRDqwpbfiB1MF1QczH5kHEEy12QyrqBC61g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=grCXOvYs7EH7OWhpc19oeZRd+S07R2ZUHtP1w1DeKfM=; b=Kf1672o6sRZX851LT1PQ3jhdZE2lMwGO+bnqpMreD+ZPAGAE0kAVN1+VYuYKHNSTZ84058pwPaqH0we9cHSkZulwYPTQCi/R7B0/u0aAyQu+u4XZ2mzYzLFD2SM3+kMr5Q0MvEb92Gk8sTMNcSogqnSr681owhP3EsrAuxYHmzakKfpA0ygmEmTQ7+LmL22e2zRrrLUjCeK7LgBK4dXxrJLJJcshcuvA7kj4vB1B/6ovKmND2+EtvrOprrRSg2TjLlV8JDinFLWj7KefcGVqX5sOuKwlZIzdQhQCqUYMVlCvpRIFpiG3FmlvAFpRzWWTPsbGo6kpDEWyrLauPzpsgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=grCXOvYs7EH7OWhpc19oeZRd+S07R2ZUHtP1w1DeKfM=; b=Kkye+cMkxerZrNg1oSKos7tjrBWGQEy1IS61hBLVF+aHQbBLwcyAKNOLVSo16DUHplkrSzN8hJmloRBUcHwqiaDKaHn6463EWBOkVz+704ZKKt8dWkuc9atImpuFr7VhCJ5R6OKQlVraIvd6v1yjGFosQaPw8SI+Pll6nzAuC08= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4984.eurprd08.prod.outlook.com (2603:10a6:20b:ee::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Wed, 6 May 2020 13:31:13 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2958.030; Wed, 6 May 2020 13:31:13 +0000 From: Thomas Fossati To: Carsten Bormann , Jim Schaad CC: "core@ietf.org WG" , Thomas Fossati Thread-Topic: [core] HREF compression encoding Thread-Index: AdYY0kiSZ0ZIX97ER3mBegRkAxq6IQKzkDEAAASdEQA= Date: Wed, 6 May 2020 13:31:13 +0000 Message-ID: References: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b95ce0bb-ae6f-4024-953a-08d7f1c1c361 x-ms-traffictypediagnostic: AM6PR08MB4984:|AM6PR08MB4984:|VE1PR08MB5262: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 03950F25EC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: db+Jb05fhat069wIvpfjgOErxSd9RJwQ3jP4Jfa5errSHqyV7INVPKviop/dujAYsqPrPkF/cyNoyqa38BGrCWgaYLFs+yATNQG5OFmRrZE4avxDvwcKzE+eOI2aKkSwPMvv6k5tY4bpYg9Kw/zpRUF/V7CEksgj4xMYnW2mJ56VFD5GONv0spQwT8GZnt+XO4UTfJF5d3FwKh+Jo0CDgJZSD7eHkZkdRVqdEtiN2Pj7OzIkYSk5NBmX8RYrhxXU2hQOE04yI3O5LgROcgxGv5Av/7DyRWtMvK+auEW6XfRuZkVQwyFxdyF2CjujOK6P0r+wailxANIynyAajvE0BRnjDC7XKdy9W3Kt2UOZwiwP0p7G421Pq+6WU66yAm5txiSXqDf0KgyhNETQdQL7ejWa1TClHw/WTdCUIqcmgT8KRcHXPv92l5xBS4XuRJIgjN5x80Dtn1751RHMn05ZEdnQ2dPKSWbIlQoUcALpDRXlqK9wJTudf9/Ery1DP/SnrUneYJbKFvymy7WVxCoGkw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(39860400002)(396003)(376002)(136003)(33430700001)(33440700001)(6512007)(6506007)(8676002)(6486002)(186003)(2906002)(5660300002)(53546011)(86362001)(26005)(4326008)(76116006)(91956017)(66946007)(64756008)(66476007)(71200400001)(8936002)(316002)(54906003)(110136005)(33656002)(2616005)(478600001)(36756003)(66556008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aFS0QydHN3F8/4avexlXwYzEP9bJEZsSQk0lZSB5nKv55xey791qiP+ydKEhLrTNlJhZDR2398hkW5XkzD3fkNAD998hCRFP42TptpaHRsPOT3TcYoSHaMpDeQ6dNlbAegqT7yNkR9eP/yH6heB8fjeI/gSnYZVxDFWOIXo+f+d0/y6KX4FkYlsXAsdw2Q5A79vh2StS5s6Aj12KrvFVgRusD5Hqs7mitD7Hxb240oVRtxRU89B1u97YI2cSv4EyTj5eeiiSAxcNBh/mxDoLPTDBWGYMD6PH6P3c6nzna42tDnIkZKqAC/TzbI+2gvBZ5n1DVI7GKoMKO0h5PQQbA2q2u1RGzH377NTgKYCHQQQct0xTeTHATJRqZVT1zstKAJ1hsR8I9inbeOfZhh7/shvMwL2orsMjq5EHHtRQitEnS9oXVehG6WfBK9fbAB/ZoiEuC2OLeMcXhSpc5LSKLAmQOHruQGmZb7fMvFJ9VVV+pdAw9H47w4p5mbAiHrom3U9R0HtzrSfXD7oSORcmRS2wZpKOj3Wm4RF3udjYn2DThGIFEXH3W+Ykvn65/QNmO/CtMUa6ff887X3O/DqYBHWOR4hV9qRQRpGPmnDnQM4cu+KChAGkU/vGIj2kv1tZi/WfhmuouMxiExVoxyXz1xSyR9sGZAAO5R9daaF15QavlSQXI10s/OD98shbQ7yyt2jJ5k/P/ruxWpMkEUvrzEyQa+8Zcb0TZYjE5kM4vDSgx0PXd9HQQ8/fa71UTnqOXi3ICLOwT+S4pjRTQM1AufSEWAaN0+EeH+u1NIZugKw= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4984 Original-Authentication-Results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(396003)(39860400002)(46966005)(33430700001)(110136005)(356005)(33656002)(478600001)(81166007)(6506007)(54906003)(82740400003)(86362001)(186003)(26005)(2616005)(4326008)(53546011)(316002)(47076004)(82310400002)(33440700001)(8936002)(70586007)(6486002)(336012)(8676002)(36906005)(6512007)(5660300002)(2906002)(70206006)(36756003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 762d32e2-4190-4215-8b9c-08d7f1c1bf3c X-Forefront-PRVS: 03950F25EC X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xy+aolT2Mh4/GTb4veaD8HxjAcyBdhJ3xSinE6PtLenDch4i21gaUB9mhzr21elcO2L8NZZPJ36zeclskcW9ro2N4nHO6ap9O21NnP66ANvVmLIVDWuPhRJOSaCk38Y44jTnAQ/8LyN/Pc1dNPizh0uhqqsIo3JHX9wAQ0QyRLh0eAfG88ncCinEb+7+q+uCoGgsYDYHztuDpnB4/OH6j6rmBcGocpAaFfBhWJghJgUu8R7BF2ACXC+bZD8UDccN9uvsJgGarxfBjPRa8vHan3cELDEku7JL5QdVipFSNkVCz7PeG4nTJ71S3XE97Mzh6v4bxnuy1NAmw3jK1EO3FegDIB6X/84F6dg1PEB1V/dLDfPzPexQzaqW0gSlc2f6fNKK+Xo/+n/63GYilVNmNHTSHBLelZf/aNP8j9fbG71Z54EA4EM9GUXmlnp721MYDNb1BjBaLCLj6qI1XtEnBOH3sXi/BdZ/km62knp2gkGG9I+0SgmqwZfrZXPbsfGCCywNY64dT9FjOVfu+jkNNe74omHvJ9XzkOa7TB7WJAZ0yxi/KzSG6P6X7wEq5/m5VMJ9UoS4KOvrpjcM/2uRzw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2020 13:31:20.2450 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b95ce0bb-ae6f-4024-953a-08d7f1c1c361 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5262 Archived-At: Subject: Re: [core] HREF compression encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 13:31:28 -0000 T24gMDYvMDUvMjAyMCwgMTM6MTksICJjb3JlIG9uIGJlaGFsZiBvZiBDYXJzdGVuIEJvcm1hbm4i IDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNhYm9AdHppLm9yZz4gd3JvdGU6 DQo+IEtsYXVzIGFuZCBJIGhhZCBhIGNoYXQgYWJvdXQgaXQgbm93LCB3aGljaCBsZWQgdG8gdGhl IGZvbGxvd2luZyBzdHJhdw0KPiBtYW4gZ3JhbW1hcjoNCj4NCj4gQ1JJLVJlZmVyZW5jZSA9IFsN Cj4gICAoP3NjaGVtZSwgPyhob3N0LCA/cG9ydCkgLy8gcGF0aC50eXBlKSwNCj4gICAqcGF0aCwN Cj4gICA/IChRVUVSWSwgK3F1ZXJ5KQ0KPiAgID8gKEZSQUdNRU5ULCBmcmFnbWVudCkNCj4gXQ0K Pg0KPiBzY2hlbWUgICAgPSAoKFNDSEVNRVRFWFQsIHRleHQgLnJlZ2V4cCAiW2Etel1bYS16MC05 Ky4tXSoiKQ0KPiAgICAgICAgICAgICAvLyBDT0FQIC8vIENPQVBTIC8vIEhUVFAgLy8gSFRUUFMp DQo+IGhvc3QgICAgICA9ICgoSE9TVFRFWFQsIHRleHQpIC8vIGJ5dGVzIC5zaXplIDQgLy8gYnl0 ZXMgLnNpemUgMTYpDQo+IHBvcnQgICAgICA9IDAuLjY1NTM1DQo+IHBhdGgudHlwZSA9IDAuLjEy Nw0KPiBwYXRoICAgICAgPSB0ZXh0DQo+IHF1ZXJ5ICAgICA9IHRleHQNCj4gZnJhZ21lbnQgID0g dGV4dA0KPg0KPiBTQ0hFTUVURVhUID0gLTENCj4gQ09BUCA9IC0yIENPQVBTID0gLTMgSFRUUCA9 IC00IEhUVFBTID0gLTUNCj4gSE9TVFRFWFQgPSB0cnVlDQo+IFFVRVJZID0gLTYNCj4gRlJBR01F TlQgPSAtNw0KDQpWZXJ5IHNtb290aCwgSSBsaWtlIGl0Lg0KDQo+IE9idmlvdXNseSwgdGhlIHNw ZWNpZmljIG1hcmtlciB2YWx1ZXMgd2UgdXNlIGNvdWxkIGJlIHNodWZmbGVkIGEgYml0LA0KPiBi dXQgaXQgc2VlbXMgd2UgY2FuIGNvdmVyIHRoZSBlbnRpcmUgc3BlY3RydW0gdGhhdCBpcyBjb3Zl cmVkIGJ5IHRoZQ0KPiBleGlzdGluZyBzeW50YXguICBUaGVyZSBhcmUgYSBmZXcgdGhpbmdzIHRo YXQgbmVlZCB0byBiZSBkZWNpZGVkIGJhc2UNCj4gb24gcGVyY2VpdmVkIGZyZXF1ZW5jeSBvZiB1 c2UgKGUuZy4sIGFyZSB0ZXh0LXZhbHVlZCBob3N0IG5hbWVzIHRoZQ0KPiBsaWtlbHkgb3IgdGhl IHVubGlrZWx5IGNhc2UgLSBkZXBlbmRpbmcgb24gdGhhdCwgdGhlIG1hcmtlciBpcyBwbGFjZWQN Cj4gb24gdGhlIGhvc3QgdGV4dCBvciBvbiB0aGUgcGF0aCBzZXF1ZW5jZSwgb3IgdGhlIGFic2Vu dCBob3N0IGNvdWxkIGJlDQo+IHJlcHJlc2VudGVkIGJ5IGBmYWxzZWApLCBzbyB3ZSBzaG91bGQg Y29tZSB1cCB3aXRoIHNvbWUgcm91Z2gNCj4gZXN0aW1hdGlvbnMgaGVyZS4NCg0KQSBxdWljayBx dWVzdGlvbiBvbiAicGVyY2VpdmVkIGZyZXF1ZW5jeSBvZiB1c2UiOiBob3cgZG8gd2UgcGxhbiB0 bw0KZXZhbHVhdGUgdGhhdD8gIElzIHRoZXJlIGEgcmVwcmVzZW50YXRpdmUgY29ycHVzIHRoYXQg Y2FuIGJlIG1pbmVkPw0KDQpjaGVlcnMsIHRoYW5rcyENCg0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0K From nobody Wed May 6 07:42:44 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFEB3A0C18 for ; Wed, 6 May 2020 07:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgOwtwP4CmpH for ; Wed, 6 May 2020 07:42:34 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE49B3A0C26 for ; Wed, 6 May 2020 07:42:16 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 May 2020 07:42:04 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> In-Reply-To: Date: Wed, 6 May 2020 07:42:01 -0700 Message-ID: <03cc01d623b4$8283a7c0$878af740$@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: AQF3IyvGSPj7FWkIh2hLJEkWXqN4kAM3xeaGqT9gjnA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] HREF compression encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 14:42:43 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Wednesday, May 6, 2020 5:19 AM To: Jim Schaad Cc: core@ietf.org WG Subject: Re: [core] HREF compression encoding Hi Jim, This is an interesting proposal. [JLS] I do hope you are not implying that most of my proposals are = uninteresting =F0=9F=98=89 Klaus and I had a chat about it now, which led to the following straw = man grammar: CRI-Reference =3D [ (?scheme, ?(host, ?port) // path.type), *path, ? (QUERY, +query) ? (FRAGMENT, fragment) ] scheme =3D ((SCHEMETEXT, text .regexp "[a-z][a-z0-9+.-]*")=20 // COAP // COAPS // HTTP // HTTPS) host =3D ((HOSTTEXT, text) // bytes .size 4 // bytes .size 16) port =3D 0..65535 path.type =3D 0..127 [JLS] I think that from the other work Klaus and I have been sending = back and forth, it might be that this should be path.type =3D ABSOLUTE | 0..127 I at least found it much easier to completely separate the absolute path = from relative path when doing processing. path =3D text query =3D text fragment =3D text SCHEMETEXT =3D -1 COAP =3D -2 COAPS =3D -3 HTTP =3D -4 HTTPS =3D -5 HOSTTEXT =3D true = QUERY =3D -6 FRAGMENT =3D -7 [JLS] I am glad we finally have gotten around to the idea that we should = be using abbreviated schemes. It might be that we want to make the = schemes at the end of the list so that other could be registered and it = would be easy to determine which are schemes and which are not as they = would be a single range. Obviously, the specific marker values we use could be shuffled a bit, = but it seems we can cover the entire spectrum that is covered by the = existing syntax. There are a few things that need to be decided base on perceived = frequency of use (e.g., are text-valued host names the likely or the = unlikely case =E2=80=94 depending on that, the marker is placed on the = host text or on the path sequence, or the absent host could be = represented by `false`), so we should come up with some rough = estimations here. [JLS] Yes this needs to be done, and I don't know have any good idea of = how to do this. It seems it is going to be heavily influenced by the = set of applications that you choose to look at and how they are = weighted. An RD is going to be heavily into absolute paths. On the = other hand, from what I remember, the coffee pot is build almost = entirely from relative paths. One of the nice things from the proposal = is that we no longer need to worry about the relative frequencies on the = balance between text and numeric addresses. =20 Comments welcome... Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-22, at 20:20, Jim Schaad wrote: >=20 > I had a slightly different proposal to what Klaus presented at the = last interim in terms of doing href compression. It is based on the = fact that URIs have a relatively fixed pattern and keeps the CBOR coding = directly rather than moving to some type of binary encoding. > =20 > The standard pattern for a URI is = scheme://hostname/path/path/=E2=80=A6 Using=20 > this for compression purposes by removing all of the tagging which=20 > keeps to the same pattern you would compress=20 > coap://example.com/foo/abc=E2=80=A6xyz to > =20 > [ =E2=80=9Ccoap=E2=80=9D, =E2=80=9Cexample.com=E2=80=9D, = =E2=80=9Cfoo=E2=80=9D, =E2=80=9Cabc=E2=80=A6xyz=E2=80=9D] > 1 1 1 1 2 =3D 6 bytes of padding > =20 > This is the same amount of padding as his binary compression method. =20 > There is a slight loss over his method when you want to do port=20 > numbers, queries or fragments as they would need to have a integer tag = > inserted so you get > =20 > [ =E2=80=9Ccoap=E2=80=9D, =E2=80=9Cexample.com=E2=80=9D, = =E2=80=9Cfoo=E2=80=9D, =E2=80=9Cbar=E2=80=9D, Query, = =E2=80=9Ca=3Db=E2=80=9D, =E2=80=9Cc=3Dd=E2=80=9D, Fragment, = =E2=80=9Cgohere=E2=80=9D] > 1 1 1 1 1 1 1 1 1 = 1 =3D 10 bytes > =20 > In the binary encoding this would only require 9 bytes > =20 > Moving to an IP address adds no additional padding as the difference=20 > between a text string, a byte string of length either 4 or 8 can=20 > easily be detected. Relative URIs are encoded using similar tagging=20 > so you end up with > =20 > [ Absolute, =E2=80=9Cfoo=E2=80=9D, =E2=80=9Cbar=E2=80=9D ] > 1 1 1 1 =3D 4 byte > =20 > [ Relative, 2, =E2=80=9Cfoo=E2=80=9D, =E2=80=9Cbar=E2=80=9D ] > 1 1 1 1 1 =3D 5 bytes > =20 > Using the binary mode these would be 4 bytes and 4 bytes respectively = > (I think as no examples are in the slides) > =20 > I believe that the advantage of this proposal is that there is no new = encoder/decoder needed as this is pure CBOR. The compressed outputs are = of similar lengths as the binary version and processing them I believe = will result in near identical code sizes. The code to do absolute and = relative processing as well as generating CBOR options is going to be = very similar. > =20 > Jim > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed May 6 08:53:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F603A083B; Wed, 6 May 2020 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZcYy5NXJZH5; Wed, 6 May 2020 08:52:45 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1CA3A084B; Wed, 6 May 2020 08:52:45 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49HLhW5vhYzyst; Wed, 6 May 2020 17:52:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 6 May 2020 17:52:43 +0200 Cc: "core@ietf.org" , "netmod@ietf.org" , "draft-ietf-core-yang-cbor@ietf.org" X-Mao-Original-Outgoing-Id: 610473163.169731-0d1a5aae028e7031f9f6528a208f3dfb Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:52:48 -0000 Hi Rob, > 1) Regarding the encoding of the bits datatype: > [draft-ietf-core-yang-cbor-12, section 6.7] >=20 > The CBOR YANG encoding of the bits datatype is defined as a byte = string encoding of a bitfield. However, my concern here is that YANG = bit positions are allowed to be up 2^32-1. >=20 > E.g. the following, pathologically bad, bits definition would seem to = have a very inefficient encoding in CBOR: >=20 > typedef alarm-state { > type bits { > bit unknown { > position 4000000000; My knee jerk reaction would be =E2=80=9Cdon=E2=80=99t do that then=E2=80=9D= [1]. [1]: http://catb.org/jargon/html/D/Don-t-do-that-then-.html > } > bit under-repair; > bit critical; > bit major; > bit minor; > bit warning; > bit indeterminate; > } > } >=20 >=20 > How much should we be concerned about this pathological case? Would = it be reasonable for implementations to reject bitfields larger than a = small set size (e.g. perhaps 256 bits)? >=20 > Or, if it is supported by the language then is it reasonable that = implementation SHOULD support it? In which case I think that we might = need a second encoding of bits that supports this pathological case. = Perhaps an array of 'set' bit positions, or alternatively the union = string encoding of bits could be used. This could reduce the attack vector by malicious YANG specification, but = I think an arbitrary limit (such as the 256 mentioned above) should = work, too. (Except that arbitrary limits always come back to bite you, but that=E2=80= =99s what we have software maintenance contracts for.) > 2) Regarding the encoding of unions: >=20 > I was questioning whether the special encoding of bits type within a = union was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. = Am I right to presume that this is to ensure that the CBOR encoding of = unions is always at least as specific as XML? If so, this seems like a = reasonable design choice. =20 The semantics of Union types in YANG is closely married to the XML = representation of YANG; if two branches of a union have a (non-empty) = intersection in their XML encoding, this ambiguity is pretty much = considered a feature. So YANG-CBOR falls back to something that looks more like XML encoding = (i.e., is less efficient) in unions. The one nice thing is that a YANG spec writer can avoid the pathology by = not using unions in this way; unfortunately, the fallback cannot rely on = recognizing that the intersection is non-empty. It occurs to me that this fallback could also be used for the above = anomalies; we would need to agree on a threshold when that becomes = active. > But that leads on to these general YANG questions: >=20 > Should the value encoding of a YANG union type behave the same way = regardless of whether the encoding is XML/JSON/CBOR? =20 Of course it =E2=80=9Cshould=E2=80=9D, while retaining reasonableness = for each of the encodings, but that ship seems to have sailed (at least = for 1.0/1.1). > Or is it reasonable for there to be differences in the case of = conflicting values? Perhaps this is already answered by RFC 7951 that = can behave differently from the XML encoding of unions. >=20 > Longer term, should YANG be looking for a discriminated-union type? = Or perhaps it would be sufficient for tooling to flag up potentially = ambiguous union definitions, particularly those that may be encoding = dependent. These are all good questions. I don=E2=80=99t have an answer, except that the marriage of YANG to XML = semantics probably should get a divorce at some point. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 6 09:16:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF33A0B9F for ; Wed, 6 May 2020 09:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpqwwa0G2iTJ for ; Wed, 6 May 2020 09:14:56 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 5D1DA3A0B94 for ; Wed, 6 May 2020 09:14:56 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id b8so1291289ybn.0 for ; Wed, 06 May 2020 09:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VKytoqgY9T8ga3XpvnPQTZ2tC7y8XiUr6yecXXE8cnw=; b=rrh0vAYqvZxTaBC0JGLcy1OVBY1f+Q5R3YTXRHcorCSoXLM5bxdadmCrbBaMknu+Db 3BO3Z0kM7SW4j6PllhzHHDBbZXLY12BXeZeYxLYARJVnTFPUHuB1XxduW+gTF4E5Jzmj cyyEkOY0ISSp9BUiuiAHiXptBu8yRlERmntWFdS21ZqC7JrNsm4iU4fxjG5MqAg7dMcj xRug/fD9akRmw/FWLb6wXnmDifwCUaE6XHoRtALoRg1ki0vM5Wp5tni0k1BM4X0aUTqH cGuPLRLfLt52GEb3JPUXHRHc2zMkAL07iz0Rz2sLKQqY9pRUp1xX2e7j+00YpDlMmlES 25JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VKytoqgY9T8ga3XpvnPQTZ2tC7y8XiUr6yecXXE8cnw=; b=ErIIcEUN2PfUw/dzoKvp1BTL9c5bVLee5JetpIgrWUTt7ws/iyfENiJ2aBEuMYkb1+ B/JaLOpxcf8JZBSfX8bZbMqh0c0aI30pZjyk2e9QarCpeGK1U45D0sSeo8pew8METPGk j5MIk6iJaAnFrTjJFljO7UvjGFKXtTpHNsgnzs08qmxLnTVLfuqikYPABZfGSUkjjocl RJDHlv7wYH4JMFREKjY0LD4/vLC5G1GDMo1ZDZ7ongv/bSlS4mzExFnPNGaaxMc3jpXS ydZbgrVrHFIEP4OJ1sIZv9fQSW47E0itMNT0OGFZ2uhzuK40P9xUBaAXg2hHJu51E/gS Kdow== X-Gm-Message-State: AGi0PuYNcZXIL4kXGG7M/spxyv+1wfvFNMW8AqEiEC6meGLW+P4NSWeM BveJlqths7cc7/jWOdsYPwY55WluGvzOv0e5KhzIjQ== X-Google-Smtp-Source: APiQypIf68IQgXvKdMZc6vEKy6X+/106PRuQJ9pSvtaFMNYmSQYpMTRKqpZGV1fYLZa0RJEdr1To6C4BgBFK1j4Oyms= X-Received: by 2002:a25:d015:: with SMTP id h21mr13561746ybg.145.1588781695370; Wed, 06 May 2020 09:14:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 6 May 2020 09:14:44 -0700 Message-ID: To: Carsten Bormann Cc: "Rob Wilton (rwilton)" , "draft-ietf-core-yang-cbor@ietf.org" , "netmod@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000094260e05a4fd1028" Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 16:15:00 -0000 --00000000000094260e05a4fd1028 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 6, 2020 at 8:52 AM Carsten Bormann wrote: > Hi Rob, > > > 1) Regarding the encoding of the bits datatype: > > [draft-ietf-core-yang-cbor-12, section 6.7] > > > > The CBOR YANG encoding of the bits datatype is defined as a byte string > encoding of a bitfield. However, my concern here is that YANG bit > positions are allowed to be up 2^32-1. > > > > E.g. the following, pathologically bad, bits definition would seem to > have a very inefficient encoding in CBOR: > > > > typedef alarm-state { > > type bits { > > bit unknown { > > position 4000000000; > > My knee jerk reaction would be =E2=80=9Cdon=E2=80=99t do that then=E2=80= =9D [1]. > > [1]: http://catb.org/jargon/html/D/Don-t-do-that-then-.html > > I remember this issue was discussed by the WG. The only real reason to assign explicit bit positions is to match some protocol specification, which would never waste space in a bitset. Rob has a valid concern -- what if a large bit position is encountered? > > } > > bit under-repair; > > bit critical; > > bit major; > > bit minor; > > bit warning; > > bit indeterminate; > > } > > } > > > > > > How much should we be concerned about this pathological case? Would it > be reasonable for implementations to reject bitfields larger than a small > set size (e.g. perhaps 256 bits)? > > > > Or, if it is supported by the language then is it reasonable that > implementation SHOULD support it? In which case I think that we might ne= ed > a second encoding of bits that supports this pathological case. Perhaps = an > array of 'set' bit positions, or alternatively the union string encoding = of > bits could be used. > > This could reduce the attack vector by malicious YANG specification, but = I > think an arbitrary limit (such as the 256 mentioned above) should work, t= oo. > (Except that arbitrary limits always come back to bite you, but that=E2= =80=99s > what we have software maintenance contracts for.) > > This is the approach we started with for the union type but ended up changing it later. It is better to fully support YANG semantics with a less efficient encoding, rather than tag some YANG modules as "unsupportable". > 2) Regarding the encoding of unions: > > > > I was questioning whether the special encoding of bits type within a > union was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. = Am > I right to presume that this is to ensure that the CBOR encoding of union= s > is always at least as specific as XML? If so, this seems like a reasonab= le > design choice. > > The semantics of Union types in YANG is closely married to the XML > representation of YANG; if two branches of a union have a (non-empty) > intersection in their XML encoding, this ambiguity is pretty much > considered a feature. > So YANG-CBOR falls back to something that looks more like XML encoding > (i.e., is less efficient) in unions. > The one nice thing is that a YANG spec writer can avoid the pathology by > not using unions in this way; unfortunately, the fallback cannot rely on > recognizing that the intersection is non-empty. > > It occurs to me that this fallback could also be used for the above > anomalies; we would need to agree on a threshold when that becomes active= . > > Would it be possible to have 2 encoding formats for bits? 1) binary encoding using bit positions (only bit positions 0 -- 255 allowed) 2) YANG XML encoding using bit names (any bit positions over position 255) The client and server already have to deal with the YANG XML encoding for union types so this would not be that different. > > But that leads on to these general YANG questions: > > > > Should the value encoding of a YANG union type behave the same way > regardless of whether the encoding is XML/JSON/CBOR? > > Of course it =E2=80=9Cshould=E2=80=9D, while retaining reasonableness for= each of the > encodings, but that ship seems to have sailed (at least for 1.0/1.1). > > > Or is it reasonable for there to be differences in the case of > conflicting values? Perhaps this is already answered by RFC 7951 that ca= n > behave differently from the XML encoding of unions. > > > > Longer term, should YANG be looking for a discriminated-union type? Or > perhaps it would be sufficient for tooling to flag up potentially ambiguo= us > union definitions, particularly those that may be encoding dependent. > > These are all good questions. > I don=E2=80=99t have an answer, except that the marriage of YANG to XML s= emantics > probably should get a divorce at some point. > > This is already the case but the RFCs have not caught up yet. If YANG is ever updated the XML-specific text will probably get moved to a separate document. > Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000094260e05a4fd1028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 6, 2020 at 8:52 AM Carste= n Bormann <cabo@tzi.org> wrote:
Hi Rob,

> 1) Regarding the encoding of the bits datatype:
> [draft-ietf-core-yang-cbor-12, section 6.7]
>
> The CBOR YANG encoding of the bits datatype is defined as a byte strin= g encoding of a bitfield.=C2=A0 However, my concern here is that YANG bit p= ositions are allowed to be up 2^32-1.
>
> E.g. the following, pathologically bad, bits definition would seem to = have a very inefficient encoding in CBOR:
>
>=C2=A0 =C2=A0typedef alarm-state {
>=C2=A0 =C2=A0 =C2=A0type bits {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit unknown {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0position 4000000000;

My knee jerk reaction would be =E2=80=9Cdon=E2=80=99t do that then=E2=80=9D= [1].

[1]: http://catb.org/jargon/html/D/Don-t-do-th= at-then-.html


I remember this issue was discussed by= the WG.
The only real reason to assign explicit bit positions is= to match some protocol specification,
which would never waste sp= ace in a bitset.

Rob has a valid concern -- what i= f a large bit position is encountered?
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit under-repair;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit critical;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit major;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit minor;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit warning;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bit indeterminate;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
>
> How much should we be concerned about this pathological case?=C2=A0 Wo= uld it be reasonable for implementations to reject bitfields larger than a = small set size (e.g. perhaps 256 bits)?
>
> Or, if it is supported by the language then is it reasonable that impl= ementation SHOULD support it?=C2=A0 In which case I think that we might nee= d a second encoding of bits that supports this pathological case.=C2=A0 Per= haps an array of 'set' bit positions, or alternatively the union st= ring encoding of bits could be used.

This could reduce the attack vector by malicious YANG specification, but I = think an arbitrary limit (such as the 256 mentioned above) should work, too= .
(Except that arbitrary limits always come back to bite you, but that=E2=80= =99s what we have software maintenance contracts for.)



This is the approach we= started with for the union type but ended up changing it later.
= It is better to fully support YANG semantics with a less efficient encoding= , rather than
tag some YANG modules as "unsupportable".=

> 2) Regarding the encoding of unions:
>
> I was questioning whether the special encoding of bits type within a u= nion was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7].=C2= =A0 Am I right to presume that this is to ensure that the CBOR encoding of = unions is always at least as specific as XML?=C2=A0 If so, this seems like = a reasonable design choice.=C2=A0

The semantics of Union types in YANG is closely married to the XML represen= tation of YANG; if two branches of a union have a (non-empty) intersection = in their XML encoding, this ambiguity is pretty much considered a feature.<= br> So YANG-CBOR falls back to something that looks more like XML encoding (i.e= ., is less efficient) in unions.
The one nice thing is that a YANG spec writer can avoid the pathology by no= t using unions in this way; unfortunately, the fallback cannot rely on reco= gnizing that the intersection is non-empty.

It occurs to me that this fallback could also be used for the above anomali= es; we would need to agree on a threshold when that becomes active.



Would it be possib= le to have 2 encoding formats for bits?=C2=A0
=C2=A0 =C2=A01) bin= ary encoding using bit positions (only bit positions 0 -- 255 allowed)
=C2=A0 =C2=A02) YANG XML encoding using bit names (any bit positions = over position 255)

The client and server already h= ave to deal with the YANG XML encoding for union types
so this wo= uld not be that different.

=C2=A0
> But that leads on to these general YANG questions:
>
> Should the value encoding of a YANG union type behave the same way reg= ardless of whether the encoding is XML/JSON/CBOR?=C2=A0

Of course it =E2=80=9Cshould=E2=80=9D, while retaining reasonableness for e= ach of the encodings, but that ship seems to have sailed (at least for 1.0/= 1.1).

> Or is it reasonable for there to be differences in the case of conflic= ting values?=C2=A0 Perhaps this is already answered by RFC 7951 that can be= have differently from the XML encoding of unions.
>
> Longer term, should YANG be looking for a discriminated-union type?=C2= =A0 Or perhaps it would be sufficient for tooling to flag up potentially am= biguous union definitions, particularly those that may be encoding dependen= t.

These are all good questions.
I don=E2=80=99t have an answer, except that the marriage of YANG to XML sem= antics probably should get a divorce at some point.



This is already the cas= e but the RFCs have not caught up yet.
If YANG is ever updated th= e XML-specific text will probably get moved to a separate document.
=C2=A0
Gr=C3=BC=C3=9Fe, Carsten



Andy
=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000094260e05a4fd1028-- From nobody Wed May 6 10:22:03 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60F43A0876; Wed, 6 May 2020 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONnvacFzY4Xi; Wed, 6 May 2020 10:21:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773B83A0873; Wed, 6 May 2020 10:21:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B4D83818F; Wed, 6 May 2020 13:19:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B7FE68C; Wed, 6 May 2020 13:21:24 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , "netmod\@ietf.org" , "core\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 17:22:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> Or, if it is supported by the language then is it reasonable that >> implementation SHOULD support it? In which case I think that we mig= ht >> need a second encoding of bits that supports this pathological case. >> Perhaps an array of 'set' bit positions, or alternatively the union >> string encoding of bits could be used. > This could reduce the attack vector by malicious YANG specification, > but I think an arbitrary limit (such as the 256 mentioned above) shou= ld > work, too. (Except that arbitrary limits always come back to bite yo= u, > but that=E2=80=99s what we have software maintenance contracts for.) I think that the YANG knows what the maximum value is. So I think that anyone generating code from specific YANG definitions could size their array based upon that value. If it's a generic decoder for YANG encoded content, then it might need a hint from the application, or it could have a compile-time arbitrary limi= t. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6y8hQACgkQgItw+93Q 3WU55ggAjJOvePdYGu/wC8aT2TqG0YWE8nuWDmd087yoEhvGx6ERnolDLX0cj7Rz KGlqBGNKBJhHX+DY+j3PmHdm6Ol65N79mBWBTlODZ9kg+zRJBdVXTzxU2/Aup8XG NtIRn38W6kkQ8CrWmTTwgjpAV8Gwvi31AzRi/gklYsz1+tqVxFaDQCq0el28n2H4 DauHsfWuB6j/bl9Trb06XVU8FKVpyz6wPVuQmEUBa4oRGDs28xCYFWXY1MEEkDhA RsFoOfxM80ch23TfkBeIi3B8BR+hT2FQnHsSHzftHlopRnlpBQlXKnKwAiIFPOdI Ptlq2rmaeOGa+L4YX5YwDo4U4euCDQ== =L4lH -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 7 20:28:21 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98A63A0EB8 for ; Thu, 7 May 2020 20:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAbcHuRwnrUJ for ; Thu, 7 May 2020 20:27:47 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 66E533A0ECA for ; Thu, 7 May 2020 20:27:47 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id a8so197374ybs.3 for ; Thu, 07 May 2020 20:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kYAIPQbrRCti9atcryh65k++mW+h3/kojqvNwni+yeo=; b=uEsFDqe15GzD9YPvUwgHHJ790VgP94yTy56SiL0sShCuj0MQC2/IaM8Z+sLuF3FrWZ Nmc/CW5tOy2LUmAwB5zLQdmO2dZlTE0d8kHql+l0VZPMLCSvOby7T5hvaTm1EEvM2FUz BltIstSc8PeNRYiYC26bcgkvoishOaFaAY4WDCPmo92blDeqKrnrapKXToNJz+M5Y/Lp CzNmsC+7Gyxxi8U8WT3HzL5TVpFW1Z2jyOLHoDiQB2byDbxFTMqqBSVfhmFrSsqfyDaD dzg8vSTAA+sW0QzkU79yYAHq8b84XHc7veo6iH900bXW4fHoWgRUYMDsnNMqumxfVDVG nd1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kYAIPQbrRCti9atcryh65k++mW+h3/kojqvNwni+yeo=; b=ZAqjO+Vnti9v50sQNJjXqeiflPZKRu9N05gGAPNLf8au+vvNOtDVNNHcgoBU72tSty 0YKhkxh3WBMiRDlZqkmt5FvYCT/1llKnGRwqO2u93V9VJTluXUcLSEYRh+CE2dZ9vWPf I9VuG8sX0CaugvbEqqS563iDbG3Y6gRQND7rJ3K/d4wYKFCAEgj2vUWGIE6M0JIYM2u3 gsW1AXFNjY9u3G+FYVWElZQc/OHiKjf1DEMEOnu213nciwMIOZRRtK7rCEFhNNsRAa62 CiqL5CcYmnods6MCDu9WUChqzx1vfedIVOk9oY+oLMl9/qURX9BsenvGWrZ1xgpNG79G j14A== X-Gm-Message-State: AGi0PubIZcTDzhH1R6fxAD2U48DmwPZJq4jCwWNCGnWrSl2Y/12KS2Ik JBaUibLa99ix/89gvZWlD33oqZoUItJMtKxRp7QAIg== X-Google-Smtp-Source: APiQypJyNNpM4IAsMqwtpvGXQv0R/WgwVJhuP7WcbsuoEmLHrB8YDy455MqKyK76BH3cCvGUdul65w4GrZTrK740vKA= X-Received: by 2002:a25:1f05:: with SMTP id f5mr1305468ybf.44.1588908466108; Thu, 07 May 2020 20:27:46 -0700 (PDT) MIME-Version: 1.0 References: <28486.1588785684@localhost> In-Reply-To: <28486.1588785684@localhost> From: Andy Bierman Date: Thu, 7 May 2020 20:27:35 -0700 Message-ID: To: Michael Richardson Cc: Carsten Bormann , "netmod@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b41f1e05a51a94e1" Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 03:27:54 -0000 --000000000000b41f1e05a51a94e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 6, 2020 at 10:22 AM Michael Richardson wrote: > > Carsten Bormann wrote: > >> Or, if it is supported by the language then is it reasonable that > >> implementation SHOULD support it? In which case I think that we > might > >> need a second encoding of bits that supports this pathological cas= e. > >> Perhaps an array of 'set' bit positions, or alternatively the unio= n > >> string encoding of bits could be used. > > > This could reduce the attack vector by malicious YANG specification= , > > but I think an arbitrary limit (such as the 256 mentioned above) > should > > work, too. (Except that arbitrary limits always come back to bite > you, > > but that=E2=80=99s what we have software maintenance contracts for.= ) > > I think that the YANG knows what the maximum value is. > So I think that anyone generating code from specific YANG definitions cou= ld > size their array based upon that value. > If it's a generic decoder for YANG encoded content, then it might need > a hint from the application, or it could have a compile-time arbitrary > limit. > > There are 2 competing goals: fidelity and efficiency For network management and telemetry, fidelity is critical. Missing data and altered data are dealbreakers. I think 1 point Rob is making is that the bitset encoding can end up being much less efficient than an XSD-style list of tokens. Encoding bit position 4 million requires an octet string 500,000 bytes long. Obviously not a workable solution, even for an unconstrained device/network= . Also not OK to drop bit values that seem too big for the implementation. That is not reliable enough. Why is the bit position allowed to be a uint32 in YANG? Who knows, but it has to be supported. -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > _______________________ Andy > ________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000b41f1e05a51a94e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 6, 2020 at 10:22 AM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Carsten Bormann <cabo@= tzi.org> wrote:
=C2=A0 =C2=A0 >> Or, if it is supported by the language then is it re= asonable that
=C2=A0 =C2=A0 >> implementation SHOULD support it?=C2=A0 In which cas= e I think that we might
=C2=A0 =C2=A0 >> need a second encoding of bits that supports this pa= thological case.
=C2=A0 =C2=A0 >> Perhaps an array of 'set' bit positions, or = alternatively the union
=C2=A0 =C2=A0 >> string encoding of bits could be used.

=C2=A0 =C2=A0 > This could reduce the attack vector by malicious YANG sp= ecification,
=C2=A0 =C2=A0 > but I think an arbitrary limit (such as the 256 mentione= d above) should
=C2=A0 =C2=A0 > work, too.=C2=A0 (Except that arbitrary limits always co= me back to bite you,
=C2=A0 =C2=A0 > but that=E2=80=99s what we have software maintenance con= tracts for.)

I think that the YANG knows what the maximum value is.
So I think that anyone generating code from specific YANG definitions could=
size their array based upon that value.
If it's a generic decoder for YANG encoded content, then it might need<= br> a hint from the application, or it could have a compile-time arbitrary limi= t.


There are 2 competing goals: fidelity = and efficiency

For network management and telemetr= y, fidelity is critical.
Missing data and altered data are dealbr= eakers.

I think 1 point Rob is making is that the = bitset encoding can end up being much less efficient
than an XSD-= style list of tokens.=C2=A0 Encoding bit position 4 million requires an oct= et string 500,000 bytes long.
Obviously not a workable= solution, even for an unconstrained device/network.
Also not OK = to drop bit values that seem too big for the implementation.
That= is not reliable enough.

Why is the=C2=A0bit posit= ion allowed to be a uint32 in YANG? Who knows, but it has to=C2=A0be suppor= ted.

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


Andy=

=C2=A0
________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000b41f1e05a51a94e1-- From nobody Thu May 7 23:23:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ECC3A07B3; Thu, 7 May 2020 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSdzMuN1UOen; Thu, 7 May 2020 23:22:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C7A3A07AC; Thu, 7 May 2020 23:22:53 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49JKy259G1z160b; Fri, 8 May 2020 08:22:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Fri, 8 May 2020 08:22:50 +0200 Cc: Michael Richardson , "netmod@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 610611769.63589-0126c9a162f42fb31b8b7d109f46dc62 Content-Transfer-Encoding: quoted-printable Message-Id: <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> References: <28486.1588785684@localhost> To: Andy Bierman X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 06:22:58 -0000 On 2020-05-08, at 05:27, Andy Bierman wrote: >=20 > Why is the bit position allowed to be a uint32 in YANG? Who knows, but = it has to be supported. If we think that is the way to go, I like Kio=E2=80=99s proposal over in = the CBOR list: We probably should arm that with some text that says (in nicer words) = that this is an emergency representation and implementations should not = invoke it for sane YANG models (with an operable definition of sane). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 8 00:18:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3C83A0851 for ; Fri, 8 May 2020 00:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b14SVjcEflLw for ; Fri, 8 May 2020 00:18:00 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2074.outbound.protection.outlook.com [40.107.21.74]) (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 D32B13A084D for ; Fri, 8 May 2020 00:17:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h3QeIRxNStWcvHAv7VWc6+Fc8uH4C5jkXcpnx5WG6MgIkkSIn/RHYyJwCu5vBdUCMeNwP7XQLEvZ/S8q4H9PycUlgE/dyGnxNeMcMXuI2Qpq9hMYo5QvZlQyR+52hfXyGywDZS16BwarUevXFv4h+OmudKlUeTJMMglARVxhgY6z+ZDX19tHXmYEDuxjGffm1Zbm4lyZBCTKGjwwtDfxI+hpXf3VirDCoE9njiEgOJPhc+jRbwi6tUlnGbqMJN8ezHJzAZu8FTDuSLd8oW2oYmQ9psu4O1K5RKAZIasRCNtVPilQpUPVgehM0Csa6KaKnq1YWx6YxvlHN/b3Mikb+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9awTsv7oI0ioCDfst+Ab+meGYyod254SPXQYVZ/r4sg=; b=hN2Wo0JLA6ygkpgeHQczsOL4+9XmC3iq6erEhqJmXepgX3q+7K0S42JvM0PD4ABPY481JyVnCfQ0WdnVsmiSC4mKviOK7pt5L00CfRPp6pc54YJLj409V0+F7GNbLiUhTRHrZZaqmKxHZpHacrTJ09aWqPCXC4cAAYzc8SH2sIiybdv5c95g5+eaihWnWDt5LU7O43Rm818jFN3v4oJHg2PytbxEb8DjEe6xO5G9QtJsbnBFT4ve98NWHPGiA5cjuueMCYJ0ebjM0pf22KNWwBbz9AsR4JIgHJ2jcfLrHz5DSZS0JETQvSxCabWZMxfnjvdH5mrCQGBjbmx36koQrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9awTsv7oI0ioCDfst+Ab+meGYyod254SPXQYVZ/r4sg=; b=TMKcCmcdPTYY9u/8E2Jlz+rc/5T7jujHCjupeUGX1oGcZPjc9r8dDO6q6WZXUl3K3pQBttCnFdUrQJWYradDBRw1zOSTsK2nddSnNDQaMnRtZG9pLeJHemIQvrtHDS58k5mXWRdMTAZbEa+Cuou1hObxNqd/ZiJoI3MrqWljsTY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0480.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.33; Fri, 8 May 2020 07:17:56 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2958.030; Fri, 8 May 2020 07:17:56 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Fri, 8 May 2020 09:17:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2yKPxTAggmywrNq91NQs8Myuzqc55o94U" X-ClientProxiedBy: AM6P191CA0009.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::22) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.7] (134.19.189.38) by AM6P191CA0009.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26 via Frontend Transport; Fri, 8 May 2020 07:17:55 +0000 X-Originating-IP: [134.19.189.38] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f618034c-c16c-4708-8995-08d7f31fede5 X-MS-TrafficTypeDiagnostic: VI1P189MB0480: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 039735BC4E X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SBqtsY3A2uXalXekfcnY/VzhbDF0bETH50KXC2yoJps4fAsRiGofYP6p1QQXgQYpgxLNuiJ31G6B/hGpn3N8Hy23sFqzkIYkTcbFoI2Bu0EcRpE+s7eiSkdiJTbz+v9a6uZ36Jtofd78nKCxR09n/0fAP9Enh9drFj5J/bjXJVVyjKUpDMQEHq1lON62VBMErOl/V29fc84GpM9VfHHA0It+lU/xB8PJRrl+cye8CxLXBCPy0RKt/40DWHKrFmD6F7M1RjIa0rkh99fRzCa+nTXmC+fC566rItDK5UQ6kfTy8aYTnrbirwUD+ffXzyVuP65n38DunhnwIQ7fXIM837+mZXzAFiMGiNYiD9LHF+1Y0/x4sD+88Jz1SsswbygKXLEzWj7Iv0mMpjFWf4bN/uvNrEDt2ruU3CYcpedtRKN2wZ58ZG99P6bqx+yH576V4Saihr8wF9L9WreWao6s/+fId1N+S7JOKoBIU5caLBVLSlqhnBjQL2vj7YIh1PDUycNAKsXaxxOmXtnmLKJGCKSGM9pnBQisUj5aec+0SniQOd4xrlZEdEeGzUCrE1GamGJYySsHWtuKlDzG4ZACaadBT6J5RoUue1Tkt4GWLBmOIb7TQA5zMtEOn8a0vQOcHX8vWkKRQy0wt8X9YPr5zA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39860400002)(33430700001)(316002)(6666004)(31696002)(31686004)(16576012)(66476007)(66556008)(21480400003)(52116002)(33964004)(6486002)(83300400001)(83290400001)(83280400001)(235185007)(83320400001)(83310400001)(66574014)(33440700001)(6916009)(5660300002)(16526019)(44832011)(8936002)(186003)(2906002)(53546011)(966005)(956004)(2616005)(66946007)(26005)(8676002)(86362001)(478600001)(36756003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: R8RAwJO6UaZcynuy7qfuqL4AD3Y0G5a6ByFrGRHT2F+Maevvad5agSx/BpjmO5203eaAODif7kbvNcMulJJVa8EeXl/L3cFP8Dj56tgX00TtJt4wGNz8VNZ7S9FP8lQvoZkMaRQWTVZzukfF+NhD9OEA1cIdYTGTJcU2D6wrdN71weEKDulnTRvU766zQXqqN/LIJ2rLvaHcTy5O9l0Uzqbn8lkBISUIoy3aH5O43xeyYWaYARB0sxlwyzc3Ok8G7HQ1CoTKJrFThOljLKJpEcONpiJVmY0wL3SJoUZCefUiQAYppjhmQfvfqBe+mu1ucl02HeGbPm5cOB7inDJKOLJcHEe9tfLRkRKe9wavMXkiQ8x8GyMPmhzp6e0+N8+yc/sebtYWJxnzeFJepslkaPcw21fUMwjvB4qYPYthUzLWbcJWLADFMkJvfAm/W3D33+L2T/VBwZm9/eKrWRiZ9+ru0WWbpANW2lHjRWVD3RI= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f618034c-c16c-4708-8995-08d7f31fede5 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2020 07:17:56.4918 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ucv19oRoE+89nQRT74J4dKC2aSYWlhGj0+CeCDqJFm+X4y74q9Srla5hFO6o9bUljiwFLjd4wiju3OC2Gpy8qA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0480 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 07:18:07 -0000 --2yKPxTAggmywrNq91NQs8Myuzqc55o94U Content-Type: multipart/mixed; boundary="t5yVI9byQQeQFNJyk85RHJUzsqsmx1V1j" --t5yVI9byQQeQFNJyk85RHJUzsqsmx1V1j Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a kind reminder that this call for adoption ends in a few days. Best, /Marco On 2020-04-27 18:28, Marco Tiloca wrote: > Dear CoRE WG, > > Considering the interest shown during the April virtual meeting, this > mail starts a call for adoption on: > > https://tools.ietf.org/html/draft-bormann-core-senml-versions-01 > > Please, reply to the mailing list with your comments, including but not= > limited to whether or not you support adoption. > > This WG adoption call will end on Tuesday, 12th of May. > > Best, > /Marco > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --t5yVI9byQQeQFNJyk85RHJUzsqsmx1V1j-- --2yKPxTAggmywrNq91NQs8Myuzqc55o94U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl61B6IACgkQ7iZktA5Y 2kO6gAf/ZWvl/S+LdHw8kNCvdvamiHdE/EXvMxaqYmmUt05le0qEkjKA9rBl+1qt dVimBlexxyx178CJP0MOq1efC1bueB8qW1+x3niH3o6+eyfwduVcLabN3d+aL/F1 Bex1r4yif9meyk8EAIcgtV2SKYqEx63GWUHgUGPzAFfXqjwN6Otv+C7+1BaWOgMl 24ygn5UObCoUlla1qomLsTV/Hdmp+DcmML3MDUvQXSBiXZAiMs5L1atyrapdMaVn +ywOG0oTiYHLLYkg0nnt/0ddqKLfedB/e3GoK2WW66fyP6PsHA6gvYNjlWoXB1Ud 41IhNAhkoNOCNgOnVEMy5yAmIF1RpA== =QI3J -----END PGP SIGNATURE----- --2yKPxTAggmywrNq91NQs8Myuzqc55o94U-- From nobody Fri May 8 00:19:19 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17173A084E for ; Fri, 8 May 2020 00:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzsy6XyF6QIO for ; Fri, 8 May 2020 00:19:15 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50042.outbound.protection.outlook.com [40.107.5.42]) (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 844683A084D for ; Fri, 8 May 2020 00:19:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FWqL7/VKqk0jLT5KjYxDEd2+hOeqdj4ziBGVU+wdCfDE5Bf/TXuupmInmDL3QQkO0GcQ/IhbNjcx7xCn1uqzKdQQ/KnP0/MDWnYPNcilfozORLT6UNKEjOXXZ5g1AqoWmRG2+REq8hxCsxBhntbZ2sTFQWEPgVF2JrGNJ2cu731c5giK0TbswIO8hzN+0JwLBjCOU3i2Cgf9RFUttFsNfzKO9M7G2sPvFkYoVomtDZefB6U7SK6OGo+xjgUUTNljrbLHf9mS8J3zgMrA7+fp7vtJ1Eodi17GozZAFl/KVSucaL8CzfYFyRXF15IARKEa2TMNMrR9GvCsbZ3pOwvLvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zQ/5Y6hpwT7+GmeG5a2Ttjctq1xuzJfQz8Yeznzd60M=; b=A9aSLVJmFIKHBA0h25g7MxOv9AmLgfqD8fAeMfWEejVXaynS5dDsEWk2r6VhyBG1XNVDaO+RYBE0GNGxLVAWU/FevhrFqrZMj8xhosDxta4CPV7ZrMT5ZULwfLnbTXjfBmBIEwCyKUP6gjwy02jI1D9ZDak2T6pqjyu2Dp2PqkE0mZgbWd5QXgOFB119d2SoHl1A2LY0CUc1kejF+vuUtU2g59d2Rmq3vEpgqICT1Jpff3rweDVS9Gb3A7jUuYm8vvVFpmLHe9xXCWvAgp+NqQ9KX3qYcRxgfmcAG8eWTZxzNuxeSDzDJVe5Ne6UbuLv+m4/TElLev/cIa/FnQ5UMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zQ/5Y6hpwT7+GmeG5a2Ttjctq1xuzJfQz8Yeznzd60M=; b=PATOCoDAUwO0aamEYAWKzq7BRjTiJZPoYhs0+XU963ZOahrt2s50RUC5kmymyNOYVs4zb+Iddh1IhxQE/n6URdQlGVk75caAM+RGWtMP6wtxFUdsiYJM/q2N/u944nzAUZjiRyvnkSo7BPYHpvsSIU+Qb0NmR+uN9zhZ9cKzXRA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0366.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:36::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.29; Fri, 8 May 2020 07:19:13 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2958.030; Fri, 8 May 2020 07:19:13 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <459f0bd5-bc77-97bc-2328-06b167010cfb@ri.se> Date: Fri, 8 May 2020 09:19:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Nh2cny7i4lf2xYpx9AE4D0KERyY2HO8qE" X-ClientProxiedBy: AM6P191CA0013.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::26) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.7] (134.19.189.38) by AM6P191CA0013.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Fri, 8 May 2020 07:19:12 +0000 X-Originating-IP: [134.19.189.38] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: aad64116-78ba-4cac-64a7-08d7f3201ba9 X-MS-TrafficTypeDiagnostic: VI1P189MB0366: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 039735BC4E X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: V8/x+VwiYPxWU06ys5DWoIs8ZgPwJIqPqAoAnOh7PROi2Zsdfzn0vgwAeCooDRuhzpvp6Z7adFWhnfBCXzrpqtqCHr+XV+q45aZi8C2+GFE3042l5ybuQVk1W8sk64Cup6hTlrDqipAhW5YcMLFxCbVjeI4yBAGn/02lVIjOErjkrucGw2tG9BqgYXmMuDuTRbDE4ZbxMc6i/LZ26bZjXeEtM0kYEjHX2nIToRo1wr9MMWeYL5ltvCGYqUsMkARoQdVxdHzTvup+QJFgan01csgx2j3M+ZF6PkFd8Uc/XhNfN63G9fGWyyG6MA7lkHxHBtisEpT5+n+3VKhHWJc4bF2uEm6oRH3TCU3o1zsqmrSzSUnjY7eJvLOZk9qVa3YCLlpFKqX2wTPkIF3W/MPehbhx8oLvyZjPS4DjfflKg2bWfjka3iBtOokB1crTDUiSSVzGo7XPPTwPjFycZtrjhOCxC+w4banZItoGjhAGUyBuy971uoTzEPFUuex6uL8jXU4BSZ0Yhhn19b6pSMxBrByJky47jZhlM6qWyTxdWTKhEpEjRBBk2xv4OomphsMHTIXJ8WgTcyZ77QwVWdiVxSl+wtnCm1jGmsVgrYaTHczw5OGOQOXjpA+85ToZyfJP7I/xTcPlFKF8ZbhBdMchvg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(33430700001)(36756003)(31696002)(33440700001)(66946007)(8676002)(66574014)(956004)(83310400001)(83320400001)(83280400001)(2616005)(83290400001)(83300400001)(235185007)(5660300002)(31686004)(478600001)(86362001)(44832011)(21480400003)(66556008)(66476007)(6916009)(16526019)(186003)(26005)(52116002)(33964004)(966005)(16576012)(53546011)(316002)(8936002)(6486002)(2906002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: fzHmYPiX1IK3B6rp2jK3eH5B1kPeYX4XIRpM99TzwQODrP22YW7kRrZ1GpvytF1VxrjleQaFvlAGCIreFRfWGUHfkl94pKWutlpGx/jgapLWfMIfp692K4Ha5m+S4Ro20sOo7RG6uyDzvrZg7GyEUi5md4wpQ4vVU+v9lgE3QkbZG3g3LPL1xsdjxAW6KEc3HjpTFoc5dH7ekxWItSkplJaL4nfdkCOrmzbvuqa6MZw0aWDQuGLI3bISJ4JnyBC79k1Heuj8psnMHbNTEpeYZaGkrw4+T5e0aQheGIz5LqPFMtiWe4ZPFJ3a122HXqnS1sj0pwZNYflvHzndKG5LK528as+PKMVwd21OCNW7GqQEMmjBUZCS/AkFVW6vJPQ37tGVKR92n/LEG0E0zQ8jDuGBkgLw0MPh6KHqycwLFToYbsuGWUNRs7+rszy6SW44Vo1OeE57ARypz4ofXgWQycUEgnhZPQxKmDSbs/5PeMY= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: aad64116-78ba-4cac-64a7-08d7f3201ba9 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2020 07:19:12.9401 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: C8ieiMV6ci72/nwl1+/ETLmggJTr+f8oBWf2/zZGkwesnX5WKVudV4NZOSGQduYelELtTUm1PQlWfsl4F0kwsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0366 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 07:19:18 -0000 --Nh2cny7i4lf2xYpx9AE4D0KERyY2HO8qE Content-Type: multipart/mixed; boundary="qICnp6NuZ41AvvyJxNyGxPVMSDqRzrDU0" --qICnp6NuZ41AvvyJxNyGxPVMSDqRzrDU0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a kind reminder that this call for adoption ends in a few days. Best, /Marco On 2020-04-27 18:33, Marco Tiloca wrote: > Dear CoRE WG, > > Considering the interest shown during the April virtual meeting, this > mail starts a call for adoption on: > > https://tools.ietf.org/html/draft-fossati-core-coap-problem-02 > > Please, reply to the mailing list with your comments, including but not= > limited to whether or not you support adoption. > > This WG adoption call will end on Tuesday, 12th of May. > > Best, > /Marco > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --qICnp6NuZ41AvvyJxNyGxPVMSDqRzrDU0-- --Nh2cny7i4lf2xYpx9AE4D0KERyY2HO8qE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl61B+8ACgkQ7iZktA5Y 2kNrQQf+LYuwNvVKmR7yFYW/IGUQ84XM9M5m8ynk1U8XC+ct+BfPw7Zhct50gGCq shgqZ0F0US8Hzp0FALZT4hNXqqiJNlE6brJfDOWWONacXPdXQt6iD4n4jrYF8cUm EWXuMemQ6eT370T4fxkUl6VVnPW8tB9zTxftzWipD/yFnE5VWeme3ZAasqppwdgl 1N1r1EbUlxi3D6A4GhwH9ER9YMvQUc9xHcZQ2oRGrlev6uoaz12QTqKCtWEaqmS1 UeJ+Sm9qWvy6z4r+ufD+aFCrbcroCXXXiUwcO48AdmDamKOK+GQNGl8E9ByF+1oM deHNpkNNCXp2TbJeEM4xuM2QKg3PXg== =vlSJ -----END PGP SIGNATURE----- --Nh2cny7i4lf2xYpx9AE4D0KERyY2HO8qE-- From nobody Fri May 8 08:52:01 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABDC3A0BB2 for ; Fri, 8 May 2020 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZI-yzPi57GC for ; Fri, 8 May 2020 08:51:52 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 383483A0BAE for ; Fri, 8 May 2020 08:51:52 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id i16so1155064ybq.9 for ; Fri, 08 May 2020 08:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mY87m/tJI7hneJvMdWPXq8YJTENVCkCa3y80ZFMOnuQ=; b=dcJfFpHIdtUu4vuEL6TjWZnxbIimG7vEEPKaiKzPuae1gWXOrCoxRocZKTQVgyut0g bvQW6XDdb1gOpZhrWXEscZk0jnKsTgWRrQLW4/HplGohoEhkgL3EaGI3wDpSH2o7IYJG ct0b9oHmv4NcM3DAN13rryAUvr9mo/i6pTQuOdsN/UV4jyTggrxZwZVfvl8ylBbsUtix c/crbg00ZkDSqZgg81gaSXjqacTGcCLjXlqoyMMjiwwpoaeLrgXfKzBhVGQQ/lIEgl0P Y3g5GJxXNBmmf0PNnIXXNQOLKJ1zSHF3Q7Kx6mHUwOW7MGX3fpkmYweH7FbB1cnLHIds 5Qzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mY87m/tJI7hneJvMdWPXq8YJTENVCkCa3y80ZFMOnuQ=; b=CQwI3wJx9ER1OCDDw4S9VmFkhGSaWHc8EyynegP+Hn1bUCh7/bPO+vnpzya5xeiHZ8 iBEWuQm7q8QJSZqnGO+KRT0RPDiJeXrhjcSEVtlXaiU9MtfwIeAjT9Kr2oohV4w9DJSM eAzSUOqHUn8VSQ6fd6cUlF9mEESM36j3O5fobeKdDKoDgzn1yLB8JPTvPxCubyUCsUOB ZbHYzc/oQHMnSQhONU9kf3CHBK6yvjq+DfFzoORdLc+pV50STQGL4r8t6ZRIxfdc+wKR 24SyPPe45ZsRhvLfMky+i29qFN5UGROJchIkN7ggJorFreEaY5ZEAuZpZURFJMnFlq+0 jehA== X-Gm-Message-State: AGi0PuboWAk6bglaVbcbqBUcd8OMcnvj0W0ITQlzju9kxP3ZRk+gOhUf h3V6nRMMaK3nzvGNGf89SSm/mLIckHgIa7HwCqvrNEtb X-Google-Smtp-Source: APiQypK8LRLVFNtcySIxWq+rVAjIVmjG6JjntZHRTgT6qI6GnRGRsTh0w4lHA7ifEwBVDShHgsBsJq92xK0k51H2vuY= X-Received: by 2002:a25:3252:: with SMTP id y79mr6188889yby.274.1588953110948; Fri, 08 May 2020 08:51:50 -0700 (PDT) MIME-Version: 1.0 References: <28486.1588785684@localhost> <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> In-Reply-To: <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> From: Andy Bierman Date: Fri, 8 May 2020 08:51:40 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "netmod@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be42b905a524f9e0" Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:51:55 -0000 --000000000000be42b905a524f9e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 7, 2020 at 11:22 PM Carsten Bormann wrote: > On 2020-05-08, at 05:27, Andy Bierman wrote: > > > > Why is the bit position allowed to be a uint32 in YANG? Who knows, but > it has to be supported. > > If we think that is the way to go, I like Kio=E2=80=99s proposal over in = the CBOR > list: > > > Yes -- this encoding should work well > We probably should arm that with some text that says (in nicer words) tha= t > this is an emergency representation and implementations should not invoke > it for sane YANG models (with an operable definition of sane). > > Not sure what this means. Wouldn't this map approach be used all the time for a bits type? The "normal" case would be a small number of octets representing all the bits present (e..g 0x7 for 3 bits : bit 0 to bit 2) This would simply be 1 map entry with {offset=3D0,length=3D1,value=3D0x7} The actual bitmap is conceptually constructed by starting with an array of zero bytes. Overlapping offsets are allowed. Duplicate offsets are allowed. There is no requirement to list offsets in ascending order. There is no canonical representation. Each map entry is added to the array using a "bit or" operator. After all map entries are processed the full bits value is known. This allows an implementation to encode bits serially (often done this way with YANG bit names) So the same bitset 0x7 could be sent different ways including: { 0, 1, 0x1 } { 0, 1, 0x2 } { 0, 1, 0x4 } If the position is really bit 4 million (bit 1 in byte 500,000) { 0, 500000, 0x1 } > Gr=C3=BC=C3=9Fe, Carsten > > Andy --000000000000be42b905a524f9e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 7, 2020 at 11:22 PM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On 2020-05-08, a= t 05:27, Andy Bierman <andy@yumaworks.com> wrote:
>
> Why is the bit position allowed to be a uint32 in YANG? Who knows, but= it has to be supported.

If we think that is the way to go, I like Kio=E2=80=99s proposal over in th= e CBOR list:
<https://mailarchive.ietf.o= rg/arch/msg/cbor/3sZ4YfWLzmVVnNnQbttkovgjTP8>



Yes -- this encoding sh= ould work well
=C2=A0
We probably should arm that with some text that says (in nicer words) that = this is an emergency representation and implementations should not invoke i= t for sane YANG models (with an operable definition of sane).



Not sure what this mean= s.
Wouldn't this map approach be used all the time for a bits= type?
The "normal" case would be a small number of oct= ets representing all the bits present
=C2=A0(e..g 0x7 for 3 bits = : bit 0 to bit 2)
This would simply be 1 map entry with {offset= =3D0,length=3D1,value=3D0x7}

The actual bitmap is = conceptually constructed by starting with an array of zero bytes.
Overlapping offsets are allowed. Duplicate offsets are allowed.
= There is no requirement to=C2=A0list offsets in ascending order.
= There is no canonical representation.

Each map ent= ry is added to the array using a "bit or" operator.
Aft= er all map entries are processed the full bits value is known.
Th= is allows an implementation to encode bits serially (often done this way wi= th YANG bit names)

So the same bitset 0x7 could be= sent different ways including:

=C2=A0 { 0, 1, 0x1= }
=C2=A0 { 0, 1, 0x2 }
=C2=A0 { 0, 1, 0x4 }
=
If the position is really bit 4 million (bit 1 in byte 500,0= 00)

=C2=A0 { 0, 500000, 0x1 }

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



Andy
=C2=A0
--000000000000be42b905a524f9e0-- From nobody Fri May 8 08:58:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8185D3A0A87 for ; Fri, 8 May 2020 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYTeJ7lVSy2G for ; Fri, 8 May 2020 08:58:26 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 07FC63A0BD2 for ; Fri, 8 May 2020 08:58:25 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id v5so671973ybh.2 for ; Fri, 08 May 2020 08:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PHffSXQRoVbiTEf/OZNx55cgS877CFikbGJ8bJYg0ac=; b=ug1kx7L7NWo2uPXg/Npa7/Idbz5GeduuZ2J+KTPOq9Z7kBUWqANlTf+Ml+dTFinexp UYF5L9B0kBF3/3ViTzcxTEwxdwEqfAgYsdjrlYM/U9n88pO2icIRbqGxbqFMdMPlVdkL hkt8Fp0YbkwbZXrdDW4AzB3Q9RZfG65XzggG9ZxxoJwoWeCozcCUEFB88/uYPDBwx5jI 2qS2CwJhqbS3/hDg6fpukmfSKT53kFHohrs1dF4FVzgtupu8aaVOEVUMFity/k8BLVh9 I++u3DvmUKOsWis7U3QX9Szn/5B3nkARfVOOxRd5H4QX853APP0IhTMhfiwv2BezyOrU iz5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PHffSXQRoVbiTEf/OZNx55cgS877CFikbGJ8bJYg0ac=; b=IgvpToq/FS5WiZI3X8CZCGI5YuNGbz71trh6kxJOniGKhPj0AxSm0JWrI9nMPO1GbJ E0L2wo4bAdgNoj0f8uyYo07qeIb5kUFotCK7aa5BXka8xLGrztKY6LoNLXF1adUqnswM 6yBzJqt2b4jXhhljJlCrPPKnc1HT9G0IIFPxJvGvdfUDeQ+y6NJpcc9PQFjuSdlkitew kvyfTOYWcro2c1doOAnG5HuuO3FhCPH2NCurIfxt/dA6gt/DjUnhBIJBXgGUsN8+NOMM zdmUnsRuT5kIIqyHH7IFR7+CpyYwbvboX4aA8QVC74YSUwH28Y9NrX/WezAcUyft7yDG AScA== X-Gm-Message-State: AGi0PuZ8wA9lgER/PFl2SgMqyxKGZI/m48Ozj4EKVyRugG4zriy7Bk52 BI5glStU1su7GeGcC72sYRBiY/bMrqcGS6j2P/dfilOy X-Google-Smtp-Source: APiQypJhML78D9o3o0CRh4yTOkfvVR3WMJqeKYq5KKUr/kZhgbV5alqtuf6djLmNrMfC3e1HZ9ecvDZ8xzzj95+CCOE= X-Received: by 2002:a25:ac92:: with SMTP id x18mr5718855ybi.59.1588953504716; Fri, 08 May 2020 08:58:24 -0700 (PDT) MIME-Version: 1.0 References: <28486.1588785684@localhost> <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> In-Reply-To: From: Andy Bierman Date: Fri, 8 May 2020 08:58:14 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "netmod@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000036b30b05a5251127" Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:58:30 -0000 --00000000000036b30b05a5251127 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 8, 2020 at 8:51 AM Andy Bierman wrote: > > > On Thu, May 7, 2020 at 11:22 PM Carsten Bormann wrote: > >> On 2020-05-08, at 05:27, Andy Bierman wrote: >> > >> > Why is the bit position allowed to be a uint32 in YANG? Who knows, but >> it has to be supported. >> >> If we think that is the way to go, I like Kio=E2=80=99s proposal over in= the CBOR >> list: >> >> >> > > Yes -- this encoding should work well > > >> We probably should arm that with some text that says (in nicer words) >> that this is an emergency representation and implementations should not >> invoke it for sane YANG models (with an operable definition of sane). >> >> > > Not sure what this means. > Wouldn't this map approach be used all the time for a bits type? > The "normal" case would be a small number of octets representing all the > bits present > (e..g 0x7 for 3 bits : bit 0 to bit 2) > This would simply be 1 map entry with {offset=3D0,length=3D1,value=3D0x7} > > The actual bitmap is conceptually constructed by starting with an array o= f > zero bytes. > Overlapping offsets are allowed. Duplicate offsets are allowed. > There is no requirement to list offsets in ascending order. > There is no canonical representation. > > Each map entry is added to the array using a "bit or" operator. > After all map entries are processed the full bits value is known. > This allows an implementation to encode bits serially (often done this wa= y > with YANG bit names) > > So the same bitset 0x7 could be sent different ways including: > > { 0, 1, 0x1 } > { 0, 1, 0x2 } > { 0, 1, 0x4 } > > If the position is really bit 4 million (bit 1 in byte 500,000) > > { 0, 500000, 0x1 } > > oops: correction: (bit 0 in byte 500000) { 500000, 1, 0x1 } > > >> Gr=C3=BC=C3=9Fe, Carsten >> >> > > Andy > > --00000000000036b30b05a5251127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 8, 2020 at 8:51 AM Andy B= ierman <andy@yumaworks.com>= wrote:


On Thu, May 7, 2020 at 11:22 PM Carsten Borma= nn <cabo@tzi.org&g= t; wrote:
On 202= 0-05-08, at 05:27, Andy Bierman <andy@yumaworks.com> wrote:
>
> Why is the bit position allowed to be a uint32 in YANG? Who knows, but= it has to be supported.

If we think that is the way to go, I like Kio=E2=80=99s proposal over in th= e CBOR list:
<https://mailarchive.ietf.o= rg/arch/msg/cbor/3sZ4YfWLzmVVnNnQbttkovgjTP8>



Yes -- this encoding sh= ould work well
=C2=A0
We probably should arm that with some text that says (in nicer words) that = this is an emergency representation and implementations should not invoke i= t for sane YANG models (with an operable definition of sane).



Not sure what this mean= s.
Wouldn't this map approach be used all the time for a bits= type?
The "normal" case would be a small number of oct= ets representing all the bits present
=C2=A0(e..g 0x7 for 3 bits = : bit 0 to bit 2)
This would simply be 1 map entry with {offset= =3D0,length=3D1,value=3D0x7}

The actual bitmap is = conceptually constructed by starting with an array of zero bytes.
Overlapping offsets are allowed. Duplicate offsets are allowed.
= There is no requirement to=C2=A0list offsets in ascending order.
= There is no canonical representation.

Each map ent= ry is added to the array using a "bit or" operator.
Aft= er all map entries are processed the full bits value is known.
Th= is allows an implementation to encode bits serially (often done this way wi= th YANG bit names)

So the same bitset 0x7 could be= sent different ways including:

=C2=A0 { 0, 1, 0x1= }
=C2=A0 { 0, 1, 0x2 }
=C2=A0 { 0, 1, 0x4 }
=
If the position is really bit 4 million (bit 1 in byte 500,0= 00)

=C2=A0 { 0, 500000, 0x1 }

=

oops: correction:=C2=A0 (bit 0= in byte 500000)

=C2=A0 { 500000, 1, 0x1 }
=C2=A0
=C2=A0 =C2=A0 =C2=A0
Gr=C3=BC=C3=9Fe, Carsten



Andy
=C2=A0
--00000000000036b30b05a5251127-- From nobody Fri May 8 10:49:11 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC73A0E6D; Fri, 8 May 2020 10:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9YtZCz2C4_H; Fri, 8 May 2020 10:48:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F973A0F81; Fri, 8 May 2020 10:48:14 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 8 May 2020 10:48:08 -0700 From: Jim Schaad To: 'Andy Bierman' , 'Carsten Bormann' CC: , References: <28486.1588785684@localhost> <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> In-Reply-To: Date: Fri, 8 May 2020 10:48:06 -0700 Message-ID: <000701d62560$d681d790$838586b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01D62526.2A23E9F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGvOgo1j9qnmiUTiQ47GeqPTSRnBgJo+5o3AkgWSoMCnG1H8QJr3z1uAQLtspwCHJEHgaiFhoQQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:48:50 -0000 ------=_NextPart_000_0008_01D62526.2A23E9F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Does yang consider that there is a difference between a bit being = present and zero and a bit being absent? =20 From: core On Behalf Of Andy Bierman Sent: Friday, May 8, 2020 8:58 AM To: Carsten Bormann Cc: core@ietf.org; netmod@ietf.org Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits = [draft-ietf-core-yang-cbor-12] =20 =20 =20 On Fri, May 8, 2020 at 8:51 AM Andy Bierman > wrote: =20 =20 On Thu, May 7, 2020 at 11:22 PM Carsten Bormann > wrote: On 2020-05-08, at 05:27, Andy Bierman > wrote: >=20 > Why is the bit position allowed to be a uint32 in YANG? Who knows, but = it has to be supported. If we think that is the way to go, I like Kio=E2=80=99s proposal over in = the CBOR list: =20 =20 Yes -- this encoding should work well =20 We probably should arm that with some text that says (in nicer words) = that this is an emergency representation and implementations should not = invoke it for sane YANG models (with an operable definition of sane). =20 =20 Not sure what this means. Wouldn't this map approach be used all the time for a bits type? The "normal" case would be a small number of octets representing all the = bits present (e..g 0x7 for 3 bits : bit 0 to bit 2) This would simply be 1 map entry with = {offset=3D0,length=3D1,value=3D0x7} =20 The actual bitmap is conceptually constructed by starting with an array = of zero bytes. Overlapping offsets are allowed. Duplicate offsets are allowed. There is no requirement to list offsets in ascending order. There is no canonical representation. =20 Each map entry is added to the array using a "bit or" operator. After all map entries are processed the full bits value is known. This allows an implementation to encode bits serially (often done this = way with YANG bit names) =20 So the same bitset 0x7 could be sent different ways including: =20 { 0, 1, 0x1 } { 0, 1, 0x2 } { 0, 1, 0x4 } =20 If the position is really bit 4 million (bit 1 in byte 500,000) =20 { 0, 500000, 0x1 } =20 =20 oops: correction: (bit 0 in byte 500000) =20 { 500000, 1, 0x1 } =20 =20 Gr=C3=BC=C3=9Fe, Carsten =20 =20 Andy =20 ------=_NextPart_000_0008_01D62526.2A23E9F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Does yang = consider that there is a difference between a bit being present and zero = and a bit being absent?

 

From: core = <core-bounces@ietf.org> On Behalf Of Andy = Bierman
Sent: Friday, May 8, 2020 8:58 AM
To: = Carsten Bormann <cabo@tzi.org>
Cc: core@ietf.org; = netmod@ietf.org
Subject: Re: [core] [netmod] CBOR YANG = encoding of union & bits = [draft-ietf-core-yang-cbor-12]

 

 

 

On = Fri, May 8, 2020 at 8:51 AM Andy Bierman <andy@yumaworks.com> = wrote:

 

 

On = Thu, May 7, 2020 at 11:22 PM Carsten Bormann <cabo@tzi.org> = wrote:

On 2020-05-08, at 05:27, Andy Bierman = <andy@yumaworks.com> wrote:
>
> Why = is the bit position allowed to be a uint32 in YANG? Who knows, but it = has to be supported.

If we think that is the way to go, I like = Kio=E2=80=99s proposal over in the CBOR list:
<https://mailarchive.ietf.org/arch/msg/cbor/3sZ4YfWLzmVV= nNnQbttkovgjTP8>

 

 

Yes -- this encoding should work = well

 

We probably should arm that with some = text that says (in nicer words) that this is an emergency representation = and implementations should not invoke it for sane YANG models (with an = operable definition of sane).

 

 

Not sure what this means.

Wouldn't this map approach be used all the time for a = bits type?

The = "normal" case would be a small number of octets representing = all the bits present

 (e..g 0x7 for 3 bits : bit 0 to bit = 2)

This would simply be 1 = map entry with = {offset=3D0,length=3D1,value=3D0x7}

 

The actual bitmap is conceptually constructed by = starting with an array of zero bytes.

Overlapping offsets are allowed. Duplicate offsets are = allowed.

There is no = requirement to list offsets in ascending = order.

There is no = canonical representation.

 

Each map entry is added to the array using a "bit = or" operator.

After = all map entries are processed the full bits value is = known.

This allows an = implementation to encode bits serially (often done this way with YANG = bit names)

 

So the same bitset 0x7 could be sent different ways = including:

 

  { 0, 1, 0x1 }

  { 0, 1, 0x2 }

  { 0, 1, 0x4 }

 

If the position is really bit 4 million (bit 1 in byte = 500,000)

 

  { 0, 500000, 0x1 }

 

 

oops: correction:  (bit 0 in byte = 500000)

 

  { 500000, 1, 0x1 }

 

     

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

 

 

Andy

 

------=_NextPart_000_0008_01D62526.2A23E9F0-- From nobody Fri May 8 10:56:38 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B463A0E90 for ; Fri, 8 May 2020 10:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY6_UVLTWiB9 for ; Fri, 8 May 2020 10:56:34 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 98BBC3A0E8E for ; Fri, 8 May 2020 10:56:34 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id o198so1345393ybg.10 for ; Fri, 08 May 2020 10:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EQcA9Mn4lpEA96JwwtWqPgf/r9Ggb3M4mHHa9oo7GSg=; b=cCNnCg9S1FunBEKSt3NZBXbWtOfhL7YWADdyy5IX6L5mfV2Sy9Qm/feQNZcrmuChmH L16cNU4JWEu9XfF6zLqrOtG4hWiaB6izrCPF8t4AAHNOE7nbfaytj+WbHCbWvF4JhzGl O2a4puMgVV33Nu8UZ2MPhVPfBJS22kFDco2qtRvQ7CzlQ3cggvjbTa9SJ5BddPaQ+Adp RxkyvG2eLRtbGnpw3/Tpk/UkDUKsSYnlT9lH9OFeE4heI3wCbAKV3OUddYMNUMicy0Om ID+vQgFeXDI7rn0hE2jeWnlCKsc0L8o85GSAyn3t3EQqw7nnzFgaOgjNINwW/Vx2PRPw g6cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EQcA9Mn4lpEA96JwwtWqPgf/r9Ggb3M4mHHa9oo7GSg=; b=FAOjH5tdYee4pDRfSXKwmGz+daGI50n9i5MfBLuNbzcHJpEsWn3bz6G4QF1te2FN4V eqn6yudXXFfX+UZ/FHd/t+f2Hn0/pwkOgoB2YN+HG5I1et3ynOZNz7hKVD2JjkQk2Ei7 rM8HnPwJSk4LU9E4X6dzcAQ+OxWKWTEgh58M3wDSDrnJkDKtuw4itJu5mE4uupu3Rd3w NEd6Sw89m0+MR90fQGOmxnyeu3AQ/ysjUVbxk98ukOtvRlbuW4SiEZ/vJtfcCQpr1pgg z28PCq4y3trxV4kTit0fNkQA9VXQLWWxS88uXph6wEu8ZtJbAp2Ci0/oNHxa4MlktCDg tW0Q== X-Gm-Message-State: AGi0Puap9yJj1ecgXyHLbX3B0QIgG/wMtckk+zvnXHw2e9g4dQcYMr9P zwt1SCX52F23jAD/8L3Wt9+TwvgajYENiVINPnoXqA== X-Google-Smtp-Source: APiQypL8d/Hf3O+vw92qp4rteT+mMrAQVLfMoxdN6JL4rr+7rH9tCUd3WlQ/67yuti1dA/kaqUaopOk8E2iOvw3lS6U= X-Received: by 2002:a5b:784:: with SMTP id b4mr6402701ybq.134.1588960593483; Fri, 08 May 2020 10:56:33 -0700 (PDT) MIME-Version: 1.0 References: <28486.1588785684@localhost> <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> <000701d62560$d681d790$838586b0$@augustcellars.com> In-Reply-To: <000701d62560$d681d790$838586b0$@augustcellars.com> From: Andy Bierman Date: Fri, 8 May 2020 10:56:22 -0700 Message-ID: To: Jim Schaad Cc: Carsten Bormann , Core , NetMod WG Content-Type: multipart/alternative; boundary="000000000000bcb72105a526b733" Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:56:38 -0000 --000000000000bcb72105a526b733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 8, 2020 at 10:48 AM Jim Schaad wrote: > Does yang consider that there is a difference between a bit being present > and zero and a bit being absent? > > > leaf bits-leaf { type bits { bit zero { position 0; } bit one { position 1; } bit two { position 2; } bit 4million { position 4000000; } } } I think I see your point. The value "" is valid for this leaf indicating no bits are set. In order to send this value: { 0, 1, 0x0 } Any YANG bit that is present is represented by a bit with the value 1 in the corresponding position and octet. Andy *From:* core *On Behalf Of *Andy Bierman > *Sent:* Friday, May 8, 2020 8:58 AM > *To:* Carsten Bormann > *Cc:* core@ietf.org; netmod@ietf.org > *Subject:* Re: [core] [netmod] CBOR YANG encoding of union & bits > [draft-ietf-core-yang-cbor-12] > > > > > > > > On Fri, May 8, 2020 at 8:51 AM Andy Bierman wrote: > > > > > > On Thu, May 7, 2020 at 11:22 PM Carsten Bormann wrote: > > On 2020-05-08, at 05:27, Andy Bierman wrote: > > > > Why is the bit position allowed to be a uint32 in YANG? Who knows, but > it has to be supported. > > If we think that is the way to go, I like Kio=E2=80=99s proposal over in = the CBOR > list: > > > > > > > Yes -- this encoding should work well > > > > We probably should arm that with some text that says (in nicer words) tha= t > this is an emergency representation and implementations should not invoke > it for sane YANG models (with an operable definition of sane). > > > > > > Not sure what this means. > > Wouldn't this map approach be used all the time for a bits type? > > The "normal" case would be a small number of octets representing all the > bits present > > (e..g 0x7 for 3 bits : bit 0 to bit 2) > > This would simply be 1 map entry with {offset=3D0,length=3D1,value=3D0x7} > > > > The actual bitmap is conceptually constructed by starting with an array o= f > zero bytes. > > Overlapping offsets are allowed. Duplicate offsets are allowed. > > There is no requirement to list offsets in ascending order. > > There is no canonical representation. > > > > Each map entry is added to the array using a "bit or" operator. > > After all map entries are processed the full bits value is known. > > This allows an implementation to encode bits serially (often done this wa= y > with YANG bit names) > > > > So the same bitset 0x7 could be sent different ways including: > > > > { 0, 1, 0x1 } > > { 0, 1, 0x2 } > > { 0, 1, 0x4 } > > > > If the position is really bit 4 million (bit 1 in byte 500,000) > > > > { 0, 500000, 0x1 } > > > > > > oops: correction: (bit 0 in byte 500000) > > > > { 500000, 1, 0x1 } > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > Andy > > > > --000000000000bcb72105a526b733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 8, 2020 at 10:48 AM Jim S= chaad <ietf@augustcellars.com<= /a>> wrote:
<= div lang=3D"EN-US">
=

Does yang consider that there is a difference betwee= n a bit being present and zero and a bit being absent?

=C2=A0



=C2=A0 leaf bits-leaf {
=C2=A0 =C2=A0 =C2= =A0 type bits {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit zero { posi= tion 0; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit one { positi= on 1; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit two { position= 2; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit 4million { position 4= 000000; }
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 }

=
I think I see your point.
The value "" is va= lid for this leaf indicating no bits are set.
In order to send th= is value:
=C2=A0 =C2=A0{ 0, 1, 0x0 }

Any= YANG bit that is present is represented by a bit with the value 1 in the c= orresponding position and octet.


An= dy


<= /u>

From: core <core-bounces@ietf.org> On Behalf Of Andy Bierman=
Sent: Friday, May 8, 2020 8:58 AM
To: Carsten Bormann = <cabo@tzi.org><= br>Cc: core@ietf.= org; netmod@ietf.o= rg
Subject: Re: [core] [netmod] CBOR YANG encoding of union &= amp; bits [draft-ietf-core-yang-cbor-12]

=C2=A0

=C2=A0

=C2=A0

On Fri, May 8, 2020 at 8:51 AM Andy Bierman &l= t;andy@yumaworks.co= m> wrote:

=C2=A0

<= u>=C2=A0

On Thu, May 7, 2020= at 11:22 PM Carsten Bormann <cabo@tzi.org> wrote:

On 2020-05-08, a= t 05:27, Andy Bierman <andy@yumaworks.com> wrote:
>
> Why is the bit po= sition allowed to be a uint32 in YANG? Who knows, but it has to be supporte= d.

If we think that is the way to go, I like Kio=E2=80=99s proposal = over in the CBOR list:
<https://mailarchive= .ietf.org/arch/msg/cbor/3sZ4YfWLzmVVnNnQbttkovgjTP8>

=C2=A0

=C2=A0

Yes -- this encoding should work well

=

=C2=A0

We probably should arm= that with some text that says (in nicer words) that this is an emergency r= epresentation and implementations should not invoke it for sane YANG models= (with an operable definition of sane).

=

=C2=A0

=C2=A0

Not sure wh= at this means.

Wouldn= 9;t this map approach be used all the time for a bits type?

The "normal" case would be a = small number of octets representing all the bits present

<= /div>

=C2=A0(e..g 0x7 for 3 bits : bit 0 to bit = 2)

This would simply be = 1 map entry with {offset=3D0,length=3D1,value=3D0x7}

=C2=A0

The actual bitmap is conceptually constructed by starting with = an array of zero bytes.

= Overlapping offsets are allowed. Duplicate offsets are allowed.

There is no requirement to=C2=A0lis= t offsets in ascending order.

There is no canonical representation.

=C2=A0

Each map entry is added to the array using a "bit or" operator= .

After all map entries = are processed the full bits value is known.

This allows an implementation to encode bits serially (= often done this way with YANG bit names)

=C2=A0

= So the same bitset 0x7 could be sent different ways including:

=C2=A0

<= p class=3D"MsoNormal">=C2=A0 { 0, 1, 0x1 }

=C2=A0 { 0, 1, 0x2 }

=C2=A0 { 0, 1, 0x4 }

=C2=A0

If= the position is really bit 4 million (bit 1 in byte 500,000)=

=C2=A0

=C2=A0 { 0, 500000, 0x1 }

=

=C2=A0

=C2=A0

oops: correction:=C2=A0 (bit 0 in byte 500000)=

=C2=A0

=C2=A0 { 500000, 1, 0x1 }

=

=C2=A0

=C2=A0 =C2=A0 =C2=A0

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

=C2=A0

<= u>=C2=A0

Andy=

=C2=A0

<= /div>
--000000000000bcb72105a526b733-- From nobody Fri May 8 11:13:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84FE3A10A8; Fri, 8 May 2020 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 uUdifJIgePE6; Fri, 8 May 2020 11:13:11 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10056.outbound.protection.outlook.com [40.107.1.56]) (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 5255D3A10A5; Fri, 8 May 2020 11:13:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a66o4hXtQjtnqsInXk7nWuVdmsoJ2EtsNgUt5TlkViAbkuOaFgvQi/yw4ZQNGQhvyP/AWK6NI2X8rbojdOh9Ct3uWAwQnYPZ3X1pWcWZV7QvNq0xfpdHQTyLrgNz9szKz36QXu6DSDo5/gHKIjK4UstxNhOkLeITHuWk4R2a5yqROPcIuzNPddvlgoPoFzeO0srQJFfs6jpnLOpPHBjIiS3k9Ks/e1dSOzugDEV41oKlWPuUp4Y4ZrSy2xAgg2iHml70aynZ2z6dbm2zChypGxGPQH9Ht6IzYpPynzNikV8gKdBUOEqWdnAIXfhY5S9P9tzLLfcLV3W/GuxX+QJAig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AArX5TiOPYPs/9ms8KPrg4MB1WFS9FpB4aoHsZVKw80=; b=MSCSgZaOq0dPJhaiD9DAfYF4qq6l0LUXRRe+i0/UJxdi2reYLRNMlaomKASbr8923loaE6/bJk4IUZRa4KaHnF2ooOK6uEtaCgbZasVXYzQYNS2KUpEc6rgvg3ZbZmYivBfUFp1odJnL/ehfs19AC6HRC3I/6Q0dseku3AjpCM3G3smgs4wrfPATbcbYhspge1yXYM9qN7m3uZ9M4k+oYLaGSa69/A+bzRlvGnr12ubXwLCgYSOFql/ELgWM8gCDNM1IKJgTuQzKe15RqWHQboqXk2r26MTeWemOJnV0lbIjuJxnQxzDxJtfVKYEob7xm3/wOUWz0UcdjTwUQzFYww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AArX5TiOPYPs/9ms8KPrg4MB1WFS9FpB4aoHsZVKw80=; b=LLGls5Ctxdu+EPfXvbiQWEpCDkiWQnPEJMHMw5CVK6LgLVdt+EcFgfMn501LsZtwCAGX40D31TT8SoOUXCyr5VQQRA5qAWhQAi3hKx7SYnB9HoN383ppq32wMnWUn6tHm5hEyh/8DcGiX6fjBM8+pERHa5z/F18eOgIoo+QLsog= Authentication-Results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) by AM0P190MB0595.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Fri, 8 May 2020 18:13:08 +0000 Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483%5]) with mapi id 15.20.2979.028; Fri, 8 May 2020 18:13:08 +0000 Date: Fri, 8 May 2020 20:13:07 +0200 From: Juergen Schoenwaelder To: Jim Schaad Cc: 'Andy Bierman' , 'Carsten Bormann' , netmod@ietf.org, core@ietf.org Message-ID: <20200508181307.xxx7am5cis6k6asv@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Jim Schaad , 'Andy Bierman' , 'Carsten Bormann' , netmod@ietf.org, core@ietf.org References: <28486.1588785684@localhost> <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> <000701d62560$d681d790$838586b0$@augustcellars.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701d62560$d681d790$838586b0$@augustcellars.com> X-ClientProxiedBy: AM4PR0902CA0004.eurprd09.prod.outlook.com (2603:10a6:200:9b::14) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (2001:638:709:5::7) by AM4PR0902CA0004.eurprd09.prod.outlook.com (2603:10a6:200:9b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Fri, 8 May 2020 18:13:08 +0000 X-Originating-IP: [2001:638:709:5::7] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 091727c5-1648-4421-bfe8-08d7f37b75f5 X-MS-TrafficTypeDiagnostic: AM0P190MB0595: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4125; X-Forefront-PRVS: 039735BC4E X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Gd8oAZ7xsGk60yeVWtUqirLDmqUm8OFbab9U8DnjffSB6OkBPOSftR9pG2DsCODes7EkW0RR7s+NVEh5suRiAgm3q3zXL0IElRPiNm00lvZlYNfwm3AqI4ehGz2fv768z3duLsYw19bJ1jZWv4KN4LFxqrDvLdyHX6aqEBQMr0OeaW1buiGW8zIT+5LI7XiK8e92psoBt/PbIOVtqTo7rrres3RF6QW6k2Rz60ZRqGMha7EH8qF01Z+gH0mRXmgtyxBF4o4nf6yl/n3QDrsIKvi4Apperrcfk9lIXHk/1FMmVmjJqC7X9I2YNXXitiAGPVoKDROXwSyegS0s90yPf6hGfo0i7VR9756O/f5erdM8uEOReUm0di7LqQBFb9bWxRuRpIylNGYCY8QdKChmb5b5wC1XiSbj4bTPbnPN1Yhf76zHtBqcFQC0ydgTtz15VvAv4PWdq+L0oFNoOMyzr71jjlCn5vfWktmvBJsZwFcvyY469ThJFnjcRuV+kucD8J1OeKpsOWpr3mgnxFSrGD/34qTkKf10Cd2oGwGIYB7+6F7mSAAewtXRlnqBNZPgih1FxBpRo4jnL1n2EL+BTx7qgwJ/pypnq2qSTuJRSzA= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(366004)(136003)(346002)(396003)(39850400004)(376002)(33430700001)(2906002)(33440700001)(16526019)(52116002)(66476007)(66556008)(316002)(6496006)(1076003)(83080400001)(5660300002)(54906003)(4744005)(786003)(186003)(6486002)(66946007)(83280400001)(83310400001)(3450700001)(83300400001)(4326008)(83320400001)(6916009)(86362001)(8676002)(478600001)(8936002)(83290400001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: WtfLrzOSp1cfei1tuZgHYpvVf+i6yENAvTrFHyezGcBtu75rEDyIQFtu8Qt/blLRY0ypX3YnQl1Z+xvHNPdzksewl4EA36JAe6muP+cUb6sdDAnQnPmSAQ/myjJB1Z+bclI6SprrRqiPvAw3dg3efibdAtN47+Kmu4FQ5RbVah2xGWWF/IGhiBfakXJewGZ64XROpTt1qAo8KMXbSduYFsk12x+Y4dv9GKcGzv01entlHIp3Fj28lHqKZlyjb6k6K7e1jfVk4LKqlRmzBCu40KA4PMlN8LOkuIeM6mRLQbop3zn3aSNaNJykibTn8bjkuhj/Wpy4jTiZ+Zagu4nDodp1bwYnOsOv9R0kO+Of17CrLJsqxcEMoWDDkFlymd2rKHe+cXvhhiwHObX3bA4l+9+NTXesDlcZ+ih2Lz36NKqUBOfHeBvcKuebJ1Api5yUNSX2JDevUzmQhCWkULLpUZntGJNO59IiC9CSM+sO0UzIcwXho/triXob7sFCfZET X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 091727c5-1648-4421-bfe8-08d7f37b75f5 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2020 18:13:08.4997 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /wBVi+4OSreV2rg2uvL2LvwaX9mRzIRNgenFMXcyvRjuHSbLvGluiCiPxDjEZGsOC8r1XoXXgLSy+cb6CFCcgfYxQFkWVeOQZV3xUsMZifU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0595 Archived-At: Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 18:13:14 -0000 On Fri, May 08, 2020 at 10:48:06AM -0700, Jim Schaad wrote: > Does yang consider that there is a difference between a bit being > present and zero and a bit being absent? In YANG every bit in the bit set is either 0 or 1. The xml / json encodings send the position of the 1 bits (actually the names bound to the position). All other bits default to 0. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri May 8 19:02:16 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D30F3A07A5; Fri, 8 May 2020 19:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phMlqob6Rhte; Fri, 8 May 2020 19:01:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7FF3A07A6; Fri, 8 May 2020 19:01:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04921Tuj021065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 May 2020 22:01:32 -0400 Date: Fri, 8 May 2020 19:01:28 -0700 From: Benjamin Kaduk To: Klaus Hartke Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-stateless@ietf.org, "core@ietf.org WG" Message-ID: <20200509020128.GD27494@kduck.mit.edu> References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> <20200503224625.GF27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 02:01:44 -0000 On Mon, May 04, 2020 at 07:40:39PM +0200, Klaus Hartke wrote: > Benjamin Kaduk wrote: > > Klaus Hartke wrote: > > > Benjamin Kaduk wrote: > > > > Section 3.1 > > > > > > > > o A client SHOULD integrity protect the state information serialized > > > > in a token, unless processing a response does not modify state or > > > > cause any other significant side effects. > > > > > > > > If the intent is that the "does not modify state" clause is the only case > > > > when one would disregard the need for integrity protection, "MUST [...] > > > > unless" seems more appropriate. (I would prefer unconditional MUST and am > > > > not sure I understand the cases where there is a need to skip integrity > > > > protection.) > > > > > > The intent here is that a client must do integrity protection, but > > > there may exist valid reasons in particular circumstances to ignore > > > this requirement. In this case, the full implications must be > > > understood and carefully weighed. > > > > > > All of the circumstances that come to my mind here are those where a > > > modified token doesn't actually hurt. For example, if a client sends a > > > request to some server at regular intervals, it might only be > > > interested in whether the response has an error or success code and > > > not even deserialise the token. > > > > > > What's the best way to capture this? > > > > Before I get into suggested text, I want to check that I understand the > > situation properly -- in such a case where the client is not even > > deserializing the token, why would the client not be able to use a regular > > token and not look at that token's value? It doesn't seem like the client > > is gaining anything from having the serialized state available. > > > > Your description makes it sound like we may have to just do "SHOULD > > integrity protect" without the "unless [...]" clause. > > Hmm... the top-level section is about clients that avoid keeping > per-request state, which a client can be regardless of whether it uses > <=8 byte tokens or >8 byte tokens; but this sub-section talks about > serialized state, from which indeed the client doesn't get anything if > it's never deserialized... > > Maybe the best way forward is indeed to use SHOULD with the "unless > [...]" part... If we change to MUST, then I can already anticipate > people complaining that in their particular use case any integrity > protection is just wasting precious bytes. The SHOULD would take care > of that. And maybe we don't have to go into detail under which > circumstances it might be justified to ignore this SHOULD. > > OLD: > > o A client SHOULD integrity protect the state information serialized > in a token, unless processing a response does not modify state or > cause any other significant side effects. > > NEW: > > o A client SHOULD integrity protect the state information serialized > in a token. > > > > > o Even when the serialized state is integrity protected, an attacker > > > > may still replay a response, making the client believe it sent the > > > > same request twice. For this reason, the client SHOULD implement > > > > > > > > (Basically the same comments about "SHOULD".) > > > > > > See above. > > > > > > This section is about protecting the serialized state, but of course > > > the requests and responses need to be protected as a whole as well > > > (e.g., using DTLS or OSCORE). In some circumstances, receiving a > > > replayed token might not hurt if the client can verify that the > > > response is coming from the right server. > > > > Presumably the same cases where a replayed response from the right server > > would be tolerable? Such cases are ... rare, in my opinion. > > OLD: > > o Even when the serialized state is integrity protected, an attacker > may still replay a response, making the client believe it sent the > same request twice. For this reason, the client SHOULD implement > replay protection (e.g., by using sequence numbers and a replay > window), unless processing a response does not modify state or > cause other any significant side effects. For replay protection, > integrity protection is REQUIRED. > > NEW: > > o Even when the serialized state is integrity protected, an attacker > may still replay a response, making the client believe it sent the > same request twice. For this reason, the client SHOULD implement > replay protection (e.g., by using sequence numbers and a replay > window). > > Does it look OK without the "unless [...]" parts? I think so (for both cases), though some note about it being impossible to implement replay protection without integrity protection (while still avoiding per-request state) would probably still be in order. Thanks, Ben From nobody Mon May 11 04:16:13 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4633A08E1 for ; Mon, 11 May 2020 04:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXCoJgiPauBg for ; Mon, 11 May 2020 04:16:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4276C3A087B for ; Mon, 11 May 2020 04:16:05 -0700 (PDT) Received: from [192.168.217.119] (p548DCD41.dip0.t-ipconnect.de [84.141.205.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49LJJz4Mzhz106l; Mon, 11 May 2020 13:16:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 11 May 2020 13:16:03 +0200 Cc: "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 610888562.55029-b8e43f83922f73a006521e04e47467b9 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marco Tiloca X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 11:16:10 -0000 As I think I said in the interim, I=E2=80=99m not yet fully convinced = that the ns/type approach is the right one, but I support WG adoption of = this draft, in particular with a view to also exploring the approach its = Appendix B. (I also think that the draft might want to come with = batteries included, but I don=E2=80=99t have specific problem details to = suggest just yet.) Oh, the name=E2=80=A6 Please let=E2=80=99s fix that before draft-ietf. Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-27, at 18:33, Marco Tiloca wrote: >=20 > Dear CoRE WG, >=20 > Considering the interest shown during the April virtual meeting, this > mail starts a call for adoption on: >=20 > https://tools.ietf.org/html/draft-fossati-core-coap-problem-02 >=20 > Please, reply to the mailing list with your comments, including but = not > limited to whether or not you support adoption. >=20 > This WG adoption call will end on Tuesday, 12th of May. >=20 > Best, > /Marco >=20 > --=20 > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon May 11 04:21:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B180C3A09F2 for ; Mon, 11 May 2020 04:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAWxmhKr7Rcr for ; Mon, 11 May 2020 04:21:28 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4273E3A09E8 for ; Mon, 11 May 2020 04:21:26 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 16AD540648; Mon, 11 May 2020 13:21:25 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 97B6B173; Mon, 11 May 2020 13:21:23 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:fd03:b3b6:a60b:761b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 51FE810A; Mon, 11 May 2020 13:21:23 +0200 (CEST) Received: (nullmailer pid 2577962 invoked by uid 1000); Mon, 11 May 2020 11:21:23 -0000 Date: Mon, 11 May 2020 13:21:23 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: 'Carsten Bormann' , core@ietf.org Message-ID: <20200511112123.GA2573363@hephaistos.amsuess.com> References: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> <03cc01d623b4$8283a7c0$878af740$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <03cc01d623b4$8283a7c0$878af740$@augustcellars.com> Archived-At: Subject: Re: [core] HREF compression encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 11:21:31 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, > This is an interesting proposal. I like that too. > [JLS] [...] An RD is going to be heavily into absolute paths. Even that depends on how the RD is used. When querying for resources of a specific type across a network, it will largely consist of one full CRI ([COAP, ...]) for the anchor and one relative ([PATH-..., ...]) for the target. Queries that yield multiple records from the same server can make use of CoRAL's base directive. Kind regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --UugvWAfsgieZRqgk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl65NS8ACgkQOY0REtOk veEaFhAAyG8InBuNoc76+YhFJFFJJ0cH6KaCtu1AzKWjP99K5eBHKFRZOxuq5mus v+hMX/D5g27TzI0FInJCaTnWPwCRPjrLyXJe4I1wMBrFr1pRAiDc+Hsuj0cm01mq B85CDmEZaRBp+jrg67m+KRlzq7bDYwnjnY6Da9gkeMBG8XuRsnpPsKvhu3zYCBa4 YBgNmsFnCySMMRh/3KErbohkRzyk7lsRIBXG7j5lKyZ6CruIUAgKUfAIfSgveirl xJZavdzHkvaAHFrTyJ4b6iMGFJ7MbkWSyqqlYIxc0PZSE5aBZNodXqZQTKswIs9q 3tGsaaah14LZgWd/uUeMmMpLOR1da1lgzXBM0bws03T3YpN+DXjRvahKhvZ/Oxqb qAhqK1YSLYK2zD7Ua4xeLWbiqGESXrU4oyMJ9XvPvYdpUExn5qzW5ymysFr69TXF Q2BxwuLcfvYmrvo0eWOKgerBQv+dPA3xw/BvDLyO0NU3lC9ZIIhtKSUuo+ftJVSB CLHyroO+g9qo9cNCYtxnSyQQ4vkZry9cOjPAM18y7t52HN+zxBARKQH6VA3e7RVM 58Bfv1Eew4UQthZiMCcUcQ9gF0CUGcyVnFNBrdyzVPGXpcFGIEwWiSJxBmjDe/Ou WyJiU4TH3eHchTIAlWo8sDmWB5DmVW6a2HLVpQHs/Tg7soW5dO0= =/PgF -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From nobody Mon May 11 05:55:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5A3A0A99 for ; Mon, 11 May 2020 05:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rakcm8g84FsB for ; Mon, 11 May 2020 05:55:46 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5791F3A0A94 for ; Mon, 11 May 2020 05:55:45 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3F7FA40648; Mon, 11 May 2020 14:55:43 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F0D6B173; Mon, 11 May 2020 14:55:41 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:fd03:b3b6:a60b:761b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AC6FD196; Mon, 11 May 2020 14:55:41 +0200 (CEST) Received: (nullmailer pid 2587880 invoked by uid 1000); Mon, 11 May 2020 12:55:41 -0000 Date: Mon, 11 May 2020 14:55:41 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "core@ietf.org" Message-ID: <20200511125541.GA2576239@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline Archived-At: Subject: [core] Review of draft-bosh-core-new-block-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 12:55:52 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello BOSH authors, hello CoRE, I'd like to offer a rough review of the new-block draft. I got interested in it both because I was curious how it would address the original DOTS use case, how it'd be useful to other cases that have been brought up (a-realist comes to mind), and how it'd address other pending issues around block-wise (eg. the need for an extra Request-Tag when access can not guaranteed to be independent per block). As I understand this proposal, it addresses several issues simultaneously: * In Block1, there is no way for the server to indicate missing blocks. * For Block2, a client can not request more than one block in a single request -- especially for observations, and when it would like multiple non-contiguous blocks. My main concern here is the way token values are (re)used, and how that interacts with proxies (intermediaries): The way multiple responses arrive on the same token makes the option inherently proxy-unsafe, which is not something that can entirely be avoided in the context of block-wise transfer where atomic processing is desired (which I personally consider more of a corner case). I am also concerned that the option's implication covering all sub-layers of CoAP (talking about the request body in the same paragraph as about CON/NON details) makes things more complicated than they need to be. (CoAP deliberately has all these sub-layers in a single protocol to allow several optimizations, but solutions that stick to one layer are preferable in my opinion). I don't quite understand how the Block Identifier is interacting with resources that are not updated atomically, and how (in Block4 use) it differs from the ETag. There are several other concerns (down to the code 2.05 of the Figure 4 example which there is already 4.08 for), but they're probably best addressed when the rest is out of the way. My impression is that all of this can be achieved more generally by combining tools we already have, or are in development: * For the server to indicate missing blocks in processing, a response payload for 4.08 Request Entity Incomple would be sufficient; that could be a simple CBOR array indicating the byte offsets of missing slices or a more generic format like [1]. Then, figures 3 and 4 would look like this: CoAP CoAP Client Server | | +--------->| PUT /path B1:0/1/1024 No-Response:2.xx +----X | PUT /path B1:1/1/1024 No-Response:2.xx +----X | PUT /path B1:2/1/1024 No-Response:2.xx +--------->| PUT /path B1:3/1/1024 No-Response:2.xx | | |<---------+ 4.18, payload `missing 1024-3072` +--------->| PUT /path B2:1/1/1024 No-Response:2.xx +----X | PUT /path B2:2/1/1024 No-Response:2.xx | | +--------->| PUT /path B1:4/1/1024 No-Response:2.xx |<---------+ 4.18, payload `missnig 2048-3072` ... Note that this is mentioning no message IDs, tokens or message types; the client would probably pick NON for the No-Response requests as long as it's within its probing rate. It may skip the No-Response and send a CON whenever it feels uncomfortable with the silence. This *does* expose one difference to the B3 behavior described, and I can't tell yet whether that's good or bad: Unlike with B3, whether a "these blocks are missing" message comes depends on the server's implementation. If it requires blocks to arrive sequentially, it'd send a 4.18 immediately at the next block (as is depicted above). If it spools them all up, it'd send a cumulative error to the final request. If it does not do atomic processing, it would just process the request with the resource's last state -- which is a bug in this use case but a feature in others. For cases where this could bite, I trust (hope?) that protocol designers have the wisdom to ensure that this does not happen at application level. * For returning multiple responses to a single request, there is the core-responses draft[2] that would need more work but should eventually be where the specification for sending data on a token that already had its response could be done. Assuming that a later version of it offers a proxy-unsafe Lesiure-For-Responses:uint option that grants the serve a number of additional responses short-term responses on the same token (which may contain a Response-For option, but may also not if other options already clearly make the response incompatible to the original request but suitable for processing anyway), figures 5 and 6 could look like this: CoAP CoAP Client Server | | +--------->| GET /path T:0xf0 O:0 B2:0/0/1024 |<---------+ 2.05 T:0xf0 O:1234 B2:0/1/1024 ETag: 21 |<---------+ 2.05 T:0xf0 O:1234 B2:1/1/1024 ETag: 21 |<---------+ 2.05 T:0xf0 O:1234 B2:2/1/1024 ETag: 21 |<---------+ 2.05 T:0xf0 O:1234 B2:3/0/1024 ETag: 21 ... [[Observe triggered]] |<---------+ 2.05 T:0xf0 O:1235 B2:0/1/1024 ETag: 22 |<---------+ 2.05 T:0xf0 O:1235 B2:1/1/1024 ETag: 22 |<---------+ 2.05 T:0xf0 O:1235 B2:2/1/1024 ETag: 22 |<---------+ 2.05 T:0xf0 O:1235 B2:3/0/1024 ETag: 22 Note that tokens *are* shown here now, as that very option would interfere with token handling, and thus be proxy unsafe. If any of the triggered messages does *not* make it through, the client is at leisure to send a `GET /path T:0xf1 B2:2/0/1024` and reassemble it with the rest of the burst provided the ETag matches, as it always could. That outlined mechanism would not allow specifically requesting what should be in the follow-up blocks. Like in HTTP/2 push, the server would send what it thinks best, which would in the blockwise case be the next n blocks -- so this is where a new option *would* be helpful, but that option could be very much noncommittal, and I'd expect some such options to be specified along along with such a Leisure-For-Responses option (eg. "Send these and those blocks", "if the response is a link just assume I'll send a GET there next", "and send me a current representation after the PATCH I've sent", "and let me know if anything else changed as a result"). Looking forward to more direct discussion on Wednesday. Kind regards, Christian [1]: https://tools.ietf.org/html/draft-bosh-core-new-block-00 [2]: https://tools.ietf.org/html/draft-bormann-core-responses-00 --=20 The detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods. [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979. -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP) --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl65S0oACgkQOY0REtOk veEIBg/+P2DPB1yb5fgfY/sscguha+PHRQJK/1fxGoZmxia9bU3d0ONHdxETZTDQ SG+y0MbnFAz8h9gQvMrN2Z54q9lkX5RWuOFmuJ4KLpnD9HzoVQy9R+p79qGnMdQc Vtzjg4ZpSe43bbF7v2Um0cu0wI+uqMkwQteO3LsFyn+cqu3wdewVolxmio51intN f0Y22dddSG+2n9KlGNRp6UP5LwWneYbsF83/WUv7Ud5wnW3S/wSFkGDMuDcvtFCf ofoyn/2HPEscOoS9LglrxFleJVBlxA0v/AGHlEKqrg+/1DqioSUMWR7LssctYsT9 gM/y1nhXBEjc8j2IuO8nfXQk6ZpjacQEwAoBwKbdlg9Nq5tww2+yvoSVRWYtJdG1 Zgzee+d/XYWeyT36IwfXfT7HLZ/3QVQDZnJe3+GUweUlRAncwJni0UuHHixn7RZN VeHOv7/yI/2a8yRqOZtE6o2+plW8ZjkMfkCOfP1FnzayVG3gDioK61mb7dtPAkl4 +bfyMBq1qIoLQi2hmw8XOITEJUjlr/iyTezKY2okn5cMU40k3D2nyLg8lEhDl6Tx XJjmGKWMRJErpPY7ZfPdvyq9G8DgIkFZU/oSpWUG7/9vDwHgZeXZhTG3V2K/Os/j OUaT7X+MsMUv5SxjJXeH0+cwEZ/JgJHzOPozveT/gs1FMPlOWa0= =ovPi -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From nobody Tue May 12 06:26:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556B93A093B for ; Tue, 12 May 2020 06:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gtWJy4BOMGJ for ; Tue, 12 May 2020 06:26:30 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8391A3A0932 for ; Tue, 12 May 2020 06:26:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oSLQYscV5fJ10saOhwdpZcsk6Ax06i1kY1XudkQ0jldTxx74jjvCP93YDxa3groirvCJnnzFKQyMe9o5Wg0Ems68jHi8yBlaETgKBdskWQh3SDMw+T13sLtMvT/iBBgOxWwFZq8CIWxbk7A8biMXlJYHyuiS5zj91zLHLGDh8bujFnnSA1vreJq8IZKYaDq5MK0SSudLlgG8LQl+KZ2AcSc+tDfoFf0wv5phGUSNs9kEpNaMfkz57mbRx+PXVyWTHFeElnH9M0+VfL3/l5CitpDF/LpusSG1xjq6QlYOE12YZ7NRxMKENKqq8hZTs+xIuGGWM/kxiQ5rNhlWSqASRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Jv4FT/HUMEA6fdwhzl/3WCMNaMCeKdDvHgp47waX2Q=; b=TmooYHwEtNdwwKvvj0SDIilJtP90XDkf89WBjXh3ylrEWVS1zlI2uBw13MXvufVs9KEtKUmtKLiLcoJHT59NfGCLTOFw/SYXVwGzfm+1Dpf9GHogo2H9qgoz7e07+ukIU9SeL5gL7swH/Jz+hCpNLJ/pozhrMX68YO0zwYmclPzvnBkuDjre9NR5iRp1B7mtk52sYSinl6jpa3qzJ6KSFDlWUjQWli57rnYsM35m4hK5h+4bjsxS5dd/8SmLFsU69hUnTpQWKFLiht3sad2IjoaXOZ8R9AMdWqlwd+AC+0hhubkmoUyH9J45gkEr0DydVpL2gQnzW0hKyLkI5kiEYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Jv4FT/HUMEA6fdwhzl/3WCMNaMCeKdDvHgp47waX2Q=; b=h3YpDoal9+yP5Av8ML+g7si+ZNvCD73rh/ayCDO5X0Txv7IBGfRyH6l8+OPmt90nzXsjGoMFp7YWmpsKX0ZpLILK7y8E6T+v2CocJ9AzRz7Mo+moeU5XXSMM74vKn9E8tdyAz7IiAnx4tyefEPWXtL6vC23FMUwGsgHQV3HF2aY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0303.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:33::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Tue, 12 May 2020 13:26:26 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 13:26:26 +0000 From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== To: "core@ietf.org WG (core@ietf.org)" Message-ID: <13eaed17-09f8-3244-b127-8c52c6d1fa36@ri.se> Date: Tue, 12 May 2020 15:26:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CCNnGEONhz7cdI3nnW1hHr8mSBo1lCGTi" X-ClientProxiedBy: HE1PR07CA0034.eurprd07.prod.outlook.com (2603:10a6:7:66::20) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.7] (91.132.138.222) by HE1PR07CA0034.eurprd07.prod.outlook.com (2603:10a6:7:66::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.12 via Frontend Transport; Tue, 12 May 2020 13:26:26 +0000 X-Originating-IP: [91.132.138.222] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d524ab96-3c86-482e-2843-08d7f67812c1 X-MS-TrafficTypeDiagnostic: VI1P189MB0303: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 0401647B7F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TeXy6PowiAr2CnGrd6CTWUP8EvqUxA6PmpOaSxb9+y5hvGWkWmtOgs54iPayC6buNaNhedi34i5E/jqv4AbcDgm8ySVeFbjJEwqDelQ3nBL+TT6rRyO/jKn/gdmwWsA4KUUzTtlv+LSo6uv9ZzxUHM1wkB7QeT+4kHbzLfVci1Du+3/uzw5oaS2jZKMd7M5yEXEFYauR0uqgmgd7nadi/wQqLPmiyy64H6mVQpb45v1Xi150jwgZUK9vitShtJspN8LdmiiNYvIvAZK37vYt6EmwmlT7ItCutir0KVXxpDKW/sKgRfLNINI8WfI/Ft/DZlNFJuGSLvEOM+3rX4pxnC5Vf8QUJOYXAFvRrnGOU1NxOADaLdZizm8sjg/JZPnLpa+NgfdWn9g6hDlnpPW2tJZpMmv65BgYcLMvRwnWoW/ycIPgdTyiWcOkuFulyB6vP2N4IKPVnuYSnegWmrBo6wUAvYC44DQZLwRCCpYZha0pFfivhQDxBphMNPDPHxo6ifZ1k/c8W62ACtlpnxFOvvzNOfrbVWEBnq8KihiIhGrfFWXXRKbnW+ysOOFORtMZHUKc+LMvk8Vyl2uQ+ndZhquqGS+bwutyi8esNioN+0CWsyAPECYSJ7fQZ24wjedQe6bE97WalEwQeXOLJTTwbA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(366004)(346002)(39860400002)(33430700001)(956004)(16799955002)(66556008)(8936002)(33964004)(36756003)(8676002)(31686004)(66946007)(2616005)(44832011)(6916009)(186003)(16576012)(316002)(26005)(16526019)(2906002)(66476007)(31696002)(6486002)(33440700001)(52116002)(478600001)(21480400003)(66574014)(86362001)(235185007)(966005)(5660300002)(6666004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: LEtY8i6uUWXvXraZylwQPxbdzVxz6jyd+5FDMB8qOk8kdzxv8cCxt3IQaNkhX6IxYaE1Zj+ut921hEIlvFbapqYHjMUTUAxE/TaoeAdpMPaiKfOMR76cGsM/9S2Ctb5++w05C1K20aX2UWJlxp5rr0UMuApze7n0MoK3yD3ctUT6aDa+qjui0AtIPHc72KHckQA8O2LsTZ84ZQSxD9cAE+ty/UKdDF+EoojAeO3CGz4nhExYxf9U+polLtPERKPX23q1ZZ2SuhXL8il0dTGBFGc/OVCh1OhKUtrazX4CRY7xbrykRRFwDls0TTJXsoMnZivp+41DS9pnCffDKxYmc6b3td6GEMSa+Ed3cADfw4BCUd14iyi2/8afgJAt3cxx8JHZo05Ku/zcfeaZhJmNkuLI11ZU+2Q4cR+vHjZA1yBZejOdMPNTlzU6a9i1mvP01dZHYWeD6pEf8iFbeIN3OfeEETnOWuHafd1aEkC9jmw= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: d524ab96-3c86-482e-2843-08d7f67812c1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2020 13:26:26.8610 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oAn7zprkAyY4D+C3NzvAL10h+DlyVWaoR70n5TJ6shv4+NAiNin0VSmbAwnEHHyJMAUzalJ1L8kB2Gi2yn0WIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0303 Archived-At: Subject: [core] CoRE virtual interim 13-05-2020 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 13:26:33 -0000 --CCNnGEONhz7cdI3nnW1hHr8mSBo1lCGTi Content-Type: multipart/mixed; boundary="xdgOTvtbhtOfanCGeou0vOeLux61p04Cx" --xdgOTvtbhtOfanCGeou0vOeLux61p04Cx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a kind reminder that tomorrow (Wednesday) we will have our bi-weekly CoRE virtual interim, at 14:00 UTC. Please, find below the information to join. During the meeting, we will discuss a new proposal for blockwise transfer as well as asynchronous non-traditional responses. Best, Marco and Jaime =3D=3D=3D Meeting Information =3D=3D=3D Meeting entry: https://datatracker.ietf.org/meeting/interim-2020-core-04/session/core Agenda: https://datatracker.ietf.org/doc/agenda-interim-2020-core-04-sess= a/ Webex link: https://ietf.webex.com/ietf/j.php?MTID=3Dm94be8bc01b7b3c034a5bf3106d4376a= e Meeting number: 615 945 610 Password: constrained More ways to join Join by video system Dial 615945610@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) 1-877-668-4493 Call-in toll free number (US/Canada) Access code: 615 945 610 --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --xdgOTvtbhtOfanCGeou0vOeLux61p04Cx-- --CCNnGEONhz7cdI3nnW1hHr8mSBo1lCGTi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl66o/wACgkQ7iZktA5Y 2kNvRAgAt31EFITyYLhV5orAJ6avaB+Z8iYJ51bmfBu12FWzatTrsaejn/u1Erfv nQXC6cs674B5sMpc+wZWX3/cU7tZOZaoCURaByR1bhc1vbHFRZX/D8BNoNdGvj3F fPffifwqarbREx0A2poFDqjiTiyAjDhQKawXG0i7uK76gx5pmKW+qo7uFtpDOxp8 YPHq0pp6wz4xkym7FfMWE0n5dUAAOrcs+dAPz9QeazX5iffSgQYzF9s1f0pjI5+L +QL8dk77u3xCVbboEa2rtrrKo4YcCfvEMDvfINTQ+MuUA0cEsRgJJ34MnGJMoMam vW9AQugCichXJFjtcvmlwQZQBr/W9w== =8bOy -----END PGP SIGNATURE----- --CCNnGEONhz7cdI3nnW1hHr8mSBo1lCGTi-- From nobody Wed May 13 01:51:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891083A0FD9; Wed, 13 May 2020 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy8gzwMKkH2n; Wed, 13 May 2020 01:51:38 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38333A0FD7; Wed, 13 May 2020 01:51:33 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D804140631; Wed, 13 May 2020 10:51:28 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0685C186; Wed, 13 May 2020 10:51:27 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:fd03:b3b6:a60b:761b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A7BFD10A; Wed, 13 May 2020 10:51:26 +0200 (CEST) Received: (nullmailer pid 2749230 invoked by uid 1000); Wed, 13 May 2020 08:51:26 -0000 Date: Wed, 13 May 2020 10:51:26 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-bormann-core-responses@ietf.org, Core WG mailing list Message-ID: <20200513085126.GA2724077@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline Archived-At: Subject: [core] Non-traditional responses generalization X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 08:51:41 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, hello Core, for a more solid treatment of the suggestions I've presented at IETF107[1] and in the new-block review[2], I'd like to suggest some text chunks (below) for consideration in future work on non-traditional responses. This generally assumes and extends on I-D.bormann-core-responses-00. Kind regards Christian Terminology =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A *non-traditional response* is a response that is not the single response a server generates when it receives a request but is still responding to the oriinal request (in terms of CoAP transports, this means that it has the same token and is send between the reversed endpoint pair of the request). In particular, observations and responses to responses to multicast requests are non-traditional according to the definition; they already do follow the guidance set out here for new non-traditional responses. (A second different response sent by a non-deduplicating server to a retransmission of a request is not non-traditional because it is sent to a repeated request -- that is probably the last corner case along the distinction line). An *obviously non-matching response* is a response that has properties (typically options) that make it incompatible with the original request, and thus especially unsuitable as a cached response to that request (but possibly suitable as a cached response to a similar request). A response can not be obviously non-matching if it only differs in safe-to-forward options. Preconditions to sending non-traditional responses =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A server may send multiple responses to a request if there is any property in the request that indicates the client's intention to receive them. This is typically indicated by a request option, or (in the multicast case) by a propety of the destination address. Responses are sent after the primary response, but may be reorderered by transports that do not preserve sequence. The responses carry the same token as the original request when there are tokens, or are otherwise bound to the original request by whichever means the transport provides (e.g. by using the same reqest_kid/request_piv pair in OSCORE). A mechanism for eliciting multiple responses must specify the conditions under which a token gets freed, as the traditional arrival of the response is insufficient. It may also specify for which requests the token can be reused immediately for follow-up requests. On unordered transports, or when it's a client's follow-up request and not a response that terminates the token, the client needs to wait until no reordered non-traditional responses can be expected any more. If a non-traditional response answers the original request, no further action is required (this is the case of observation: ordering is added on top of that to ensure that only the freshest response is used). If the response does not answer the original request, it can either be obviously non-matching, or it needs to carry some option that indicates which request would have triggered it, for example the Response-For option. Responses without request =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Endpoints may agree out of band on a token (or other request-matching details). One way to do that is to exchange a "phantom request", which is a request that client and server will agree to have sent and received, respectively, without it actually being sent between those endpoints. As tokens are managed by the client, that request needs to be generated by the client, or in close collaboration with the client (for example by the client allowing a third party to use a subset of its token values in order to set up non-traditional responses). Examples of non-traditional responses =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Observation ----------- This section describes the Observe option {{?RFC7641}} in terms of this document, [ so nothing in here should contradict that document ]. When Observe:0 is present in a request, this sets up non-traditional responses until either of the following conditions is met: * A follow-up request on the same token carries an Observe:1 option. (This is primarily in here because; Observe:1 and No-Response:any could be combined; otherwise, the other conditions suffice). * Any response does not carry an Observe option. * Any response has a non-successful state. Follow-up requests are limited to extending the request ETag set. Responses are obviousy non-matching by their Observe option; each hop discards the Observe option for the purpose of caching and refreshes its cache with the most recent one as per the Observe value. Responses to multicast requests ------------------------------- As with observe, this just phrases the existing mechanism in the context of this generalization. When the destination address of a CoAP request is a multicast address, that token is valid for any member of that group (which, for the purpose of the client, is any server at all) on any port. (Except for that the implications of having received a multicast request still need to be followed, it might be seen as a template for creating a phantom request to any endpoint, if that suits the reader's mental model.) Responses can only be sent for up to the deployment's leisure time plus the application's timeout (in proxy situations, this needs to be communicated explicitly in the Multicast-Signaling option of {{?I-D.tiloca-core-groupcomm-proxy}}). Triangular responses -------------------- The Response-To option can be viewed as a short-hand notation for "Consider this a No-Response:any request, but take a copy of it, make it into a CoAP-over-UDP request with that particular address as a source and any address of yours as a response, and treat that as a phantom request". [ It may make sense to add an explicit return token, and include a No-Response option; that might allow it to be used even across proxies. ] Leisure-For-Responses --------------------- This new option (elective, proxy-unsafe, uint valued) allows the server to send up as many responses as indicated in the option value in addition to the requested response. They are to be sent immediately after the original response. On its own, the option does not indicate which more responses the client would expect (though further elective proxy-safe no-cache-key options can be added on top of that to give better guidance), and the server may choose not to send any at all. Intermediaries may add or remove the option, use incoming responses to populate their cache. They may serve additional responses from their cache, but in most cases the sensible course of action is to forward the additional responses the origin server sends. Use cases for Leisure-For-Responses include sending further blocks in a Block2 transfer (which are obviously non-matching and thus don't need a Response-For), serving follow-up documents (a response containing a single link can be followed by a representation of the linked resource, which needs a Request-For header that indicates the URI) or just provide the ETag of a freshly created resource (which would have a Reqeust-For option for a GET with the given path and an ETag, and be a 2.03 Valid response). Other current documents ----------------------- {{?I-D.tiloca-core-observe-multicast-notifications}} is a straightforward application of the phantom requests (the concept was developed there); Leisure-For-Responses could help it around the topic of joining a multicast group securely through a proxy. {{?I-D.tiloca-core-groupcomm-proxy}} seems to fit well with the concepts here as well, and might be simplified by it both in terminology and by replacing Response-Forwarding with Response-For(Proxy-Scheme, Uri-Host). [1]: https://github.com/core-wg/wg-materials/blob/master/ietf107/slides/dra= ft-bormann-core-responses.pdf [2]: https://mailarchive.ietf.org/arch/msg/core/HW-mYZQsP9BwiASO7ts1lOpwIRg/ --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl67tQsACgkQOY0REtOk veF1Mg/+IPYjS+ZpZ8u7YqqfC7BYlXcD+7N8QyPu5CC69RJOlIRf9MgCVEoXbfH2 3L7FsRd4bRSiq3xYwGJr0IL9Tdv7Q9SJpxBpdvMiu8R+Rb3TMeVKk/JHLci8ADAD HPmtjfSRk+ONBqcyW2I5KvR6CH3LRhCodaXnlYPbiUymF4WKzSb5JEKyPoAasG0k usgErnsKFI48rJB/ho8EX+QTOO43zMfQF2aJO7Uzl6epY9HNvEqAnoRNF5MHQCoj Vvw/g42Al+u+K99WqzFAKBvof2xcbZcQwXEnuJbj9JoAZD1mxpM68aChJlFafKxP T6Wi6Ca1Y/xsZXKGhiTdc4AbWJ4yu0PHDsvrksf0denGgQt67qZpuZjCGZt6yp9Q iILQmh8jULvyba8GHSVtFGvFc2OH9/LksXqVFI8YttSCuJcH2RT9CTGxdGcoqtqD YCYbpq5wWkm0yRlWcrAHpUlp+N7WHE9FZkqLhx4cilg/0h0LQwEK8mp7G9pGATO2 5+Y41JinkKSMg8/zQgi0i0IbAHFLvTUzgchrXTJwAJ4bgl8Ew19dqPlGry3BMOFq JBL8wUE5ABou5wBAgRTmT/8qekU8BssQCwIY2HuzqWguK90wnHhy5cJnwCLsYJ/W wbuQv1p1OppXfCuVM6D8oWrReyc0fRZg69/96i8AUHh/97eVjZA= =D2D2 -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From nobody Wed May 13 03:14:52 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ABA3A0D8C for ; Wed, 13 May 2020 03:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i5ZJDwivoqu for ; Wed, 13 May 2020 03:14:47 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80078.outbound.protection.outlook.com [40.107.8.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2843A0D89 for ; Wed, 13 May 2020 03:14:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m4p8rgNNLVlO94YMFlqe0p6QHsAb3KD7q5OMlxlPTkoqc6vHZePC05q6AzEpjNm+2+4OVb3ICM+xhVdTJFpGB1whVzAq8OWPbc86Lr3fyulj0luyYK8gX8dfqNQigMGPc6S76ttjjp4ZeeSOQ+ETudU49WAWcckX/a8h0V1xyozpSF2KJrffrrlJwGrkTKVAKugEax4YYk9YQDeeFOUCHEt6k8N4byNxhlaHojQn9rJdaNaHFzXZ7dwlVxZ0BkjqQ0lY4B/LfNyV1fjyc5snZw5lBR+bpbHeTUhe9ADy9WbTDeFZF1TFZ1pLlX8YQwIB0TeCNWwX+b/9OkZC5g9YgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PyJCm7KiUU5H7cmMSY9TuC8g/WE+xC+QAv0BLgv00hw=; b=NRMfFHAK8NOyzNQoFspJTljvKp1tIzioh9yHFZGlstXapUnKz+dofNJmEKK97HvkxgTugRUq71hxgUhm4s7T74eH+dyRpaKq/N6S5ZRS2uEn5ppr9KyIpSWmK8YnCzCAxynTzcwzBUKWk8g1G9EGLmRf914+3heBnj8OkHTXNrk7V1iLaTnnKwNKZa9MACp7aWEeHIGY8LHjSaIDxozuZcXZaQsNzl+ONVZr8MwOrQXGZWIeXo/5qy1zJwzFGJMdfc8MMvHt3DQySa2mdXQ6hoeajyuOlmsefYsWp8TD9FkQtOfdFuksFh2HMxRZVMcqJGs+KjX6kFlrhrAjW5sMLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PyJCm7KiUU5H7cmMSY9TuC8g/WE+xC+QAv0BLgv00hw=; b=IaL8tpB1XHaeOm4HqosduU6RVUWbl7WbTc4G5ABgZsN9vnh5iG3GvGvEh9yHkJPrmJFMHUDgpeRVWG8XosE7vSPM3UnTH937vGMXyajAjNXp9zthIWMiSz5Ji8wxyOiIL7NzJtFJWG3OS9CLrOJUGQnDW6N2ei2klvw/1K8L+50= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0541.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:37::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Wed, 13 May 2020 10:14:42 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2979.033; Wed, 13 May 2020 10:14:42 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <20923211-644d-2f39-0783-0c7c200fe3ca@ri.se> Date: Wed, 13 May 2020 12:14:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7clXvPsTLxqlQQeTzyGmJmy4b8QWMu4I7" X-ClientProxiedBy: HE1PR0301CA0024.eurprd03.prod.outlook.com (2603:10a6:3:76::34) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.8.32] (217.138.203.254) by HE1PR0301CA0024.eurprd03.prod.outlook.com (2603:10a6:3:76::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Wed, 13 May 2020 10:14:42 +0000 X-Originating-IP: [217.138.203.254] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 852b1b23-d2a6-4e26-4e5d-08d7f7267423 X-MS-TrafficTypeDiagnostic: VI1P189MB0541: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0402872DA1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jAfqsLIi2gh+roTv3bshx9KDTGya6iFhvsPmSf2we15jzVOj2d6dzFI5ieUZ5m7+p81zMqjyTqqc3DbPiUTaQFU30ofs2z962T+e4mEbjo8Mj/0FYiyT62zdWVeRVQ2jKROT/D7QVcBjF9BexWvbDHJK1GeOpgZePVrFf/cGmnYbvRoseDWb7GOZ1FIPCKkzqeIF5rOcdTeIuTOSbkRLklqqqWxDej+4XAeptGgSvWl7LNb5eMM5pgjzyiBMA4kiuaIUulXK61S/QSigmrzxvg7ucZMd72TpGGwJHvlSJvCH2yxwZvlDKYp3lWO2L98eTyKYsogYTrzpvQoI3Rc9p6OoTfcpnx9uP0mdIM/3fHjNmOXG2H4pgMhyGVXTne3y8zzPOGJRWKRxj2EPdKTu9Gy74FzyS7ZKu457t4kwTdqVsm9BKFxPPZfBgKHQvJT3XQYWjpnS9prrSHUga8UacvsmDaWl5z2FbgCk9eTC/i2Efrwrd9FAjvRsp2uK3iJLbePq+l/7NSuVcYBC5KnpSwwgDiQtRY5OxLuPe/siyltrw4M+s/ASjdeapHgF3l82M9TNjGUDh5ZVAUZZG5yjGaHBjPZtBNSY5fTSpQdDD4UEF/UqOaMp9KRmkTQc5TgkmB38SuNfCZpc+SD19Qbp+A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39850400004)(346002)(376002)(33430700001)(33440700001)(8676002)(26005)(36756003)(66946007)(8936002)(86362001)(66556008)(6486002)(66574014)(5660300002)(186003)(44832011)(16526019)(66476007)(2906002)(2616005)(31696002)(478600001)(16576012)(53546011)(235185007)(6666004)(6916009)(966005)(956004)(21480400003)(52116002)(31686004)(33964004)(316002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: XIqq6k7OH1pFTo3sp2xmZYhL46T7TUWn76YHJT7NEGym8nMSexaBMiV1v+QM/x9QJyo018GP6rxBoLZ/3hjPn+mlaKs4aujxSLRqtxwQZQEhMPf57RWnW3QtDE4HA45JYWuMmdr4kHjLkOUAEHr6Ri7mqF2FqSNutaFtB+ICSx+sFP0Ew+VCpLCneqxlfW86My0ZiloPwrJ/dlAKP+fIcldiUKOid7DeP5gGnc4//cBUxrP2hB3LuJ+IAb/PAthRQLbIf3EwcfNz2sabRzdxDPqv+NySNSRcFb0aWZJHb4hlZUNnWU2d8Gv1CrfKXVVnaMIEZG6cxNYedO0nb2SPsOOyqKXRz/5AfJrAycB7N0MQgWg6n7hHT8uy5pGcZBPEAnYypaZ7U/HRolTDq2J8iiFl9o7TBzE+lGHyU8WiS7Y7W/3r9dfD7JjdljLu9j+sYVV6YOuYjPAhrdZGj8kJvGtX4ypxMH+4ovdSb83z2WI= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 852b1b23-d2a6-4e26-4e5d-08d7f7267423 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 10:14:42.7472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FPKFnusbhfXmYhqh04DxOx2VVXH5BQfkcb6394gsiVC/m71Iqg4zbgevF5ttVSgtz+JrouraJ60yutVjdbMHIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0541 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 10:14:50 -0000 --7clXvPsTLxqlQQeTzyGmJmy4b8QWMu4I7 Content-Type: multipart/mixed; boundary="uBS0B47YwsklykWEhwkTtXNTUsTKdJOBs" --uBS0B47YwsklykWEhwkTtXNTUsTKdJOBs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Since there has been positive feedback and there is interest in the WG, we close this adoption call and adopt this document. Carsten, please resubmit the draft as a WG document. Thanks, Marco and Jaime On 2020-04-27 18:28, Marco Tiloca wrote: > Dear CoRE WG, > > Considering the interest shown during the April virtual meeting, this > mail starts a call for adoption on: > > https://tools.ietf.org/html/draft-bormann-core-senml-versions-01 > > Please, reply to the mailing list with your comments, including but not= > limited to whether or not you support adoption. > > This WG adoption call will end on Tuesday, 12th of May. > > Best, > /Marco > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --uBS0B47YwsklykWEhwkTtXNTUsTKdJOBs-- --7clXvPsTLxqlQQeTzyGmJmy4b8QWMu4I7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl67yHwACgkQ7iZktA5Y 2kMaYwgAgejte6ItMLrN0q53OoD1J1eUjUC/yjNslbowW7gDH7XnI4ZczBxdxKBh G+wyPvcQRaNnK9oBLYlpK6FVf0CqOX9L7z9XnsfnslXTGuIe7k2Z7YXbTwLky+ia +VV/I367jYtA9hu+ku2uSAYbNAhLxpX4iniwyDxL7d4TiE59oDJcNK6MZPUzkTTh d9EahHxU5TDKnDooDw3Flb2YyzJZ2RW8chuI9ydfxLvqxJHZfo5JwdA0Aup6goHI diSM+EuHYOHkLLRx+cN11J5Hyq4Jjsn6XRDyYqw6MkWZ9tH3/dxfUf8YmW+q93W+ w8TG9VddMiuogp88k0NxJRP9ITavwQ== =lYIR -----END PGP SIGNATURE----- --7clXvPsTLxqlQQeTzyGmJmy4b8QWMu4I7-- From nobody Wed May 13 03:17:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6200C3A1007 for ; Wed, 13 May 2020 03:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htcOQJxlqUHl for ; Wed, 13 May 2020 03:17:43 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40082.outbound.protection.outlook.com [40.107.4.82]) (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 08B803A0E03 for ; Wed, 13 May 2020 03:17:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZquH8C4AFhMoLD2ZT/1jEIrNh9s67k8ew+b+KDXZ4Zx7PVV1MkFYIK/BjBGjxBA16Sz53HxHOhPgA4YLQ/ES+nHTAcUM9yLlOqr6SotVBN9bTBsWvJ78JRcUgQbhNYDnw4ejFZ/MaYn/V7ld8krGf1OdAEk89x7g0Es6yS0KdOAMysG8iQCLxtfiwt2Oc3nYVnfDF8A352XF6Sga7vs/PiDgCAGECvDMa5Gt2XhAROAMmGlsVtK+AwrixCro+x+L9ZKScObRweHXUIyQdxYIuoWL38bTsEx25lJmos5jfNgRuEf5CXVxCFSOOXa/XcrPQnwNpIZP1FNzSseoscYcfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=knfmfaU1KEQxTiQaVseNtrzgCrRx18f5iqxTw/GXSQA=; b=FdvoJrOS/1SIOhfixJ+bagYYMx/cPQc5JFnXO3A4cfrMOCHspHG0qaupjwD6MbkLJFI2rFxdjEBYmhaFvV5WEr4xCzDaKMREHd6m/5J7q/Sk6aYPXZqYJikVd668xHZ4SgbevkccmOW++q1hBehwSS+KlQmsQcFqiF8JoPJjF12viNziKRzhqX7rVIAgA5iV2K1opOW+g979TaqntvEY9WLELxWT347NJPOHlnB99o/+2UKjmiHbDnRxzceIYPOp6Vbi2tji2RhKZ/SaXL/USJPvOfSZKXYUimxNLTL0F3HJpsPgCvVkflviTZ92k+UJMstwiLoro8tUJt2OAjKkuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=knfmfaU1KEQxTiQaVseNtrzgCrRx18f5iqxTw/GXSQA=; b=bocVviTE/CrUWYaZd+0qa9V5XhTkfe44KB0t/WgaUAaYrtEvXg8xvuj2TGqWZaPEerjM8vRM7MEybAYhVPJj0zAbEJi5MeChiPUka7RsLX6b4FQYBuO6QiZ2l+f0zZj1RYYG/P3hx5crzmTmUC3nT0KfMbo+lRaJUtT+GcMclzM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0479.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:33::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.35; Wed, 13 May 2020 10:17:40 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2979.033; Wed, 13 May 2020 10:17:40 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <83137462-dfae-7fc6-b691-1973fd01484b@ri.se> Date: Wed, 13 May 2020 12:17:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="14n9jczbDQjF2VCmLmxbSQUsP3ImwumHV" X-ClientProxiedBy: HE1PR0301CA0005.eurprd03.prod.outlook.com (2603:10a6:3:76::15) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.8.32] (217.138.203.254) by HE1PR0301CA0005.eurprd03.prod.outlook.com (2603:10a6:3:76::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30 via Frontend Transport; Wed, 13 May 2020 10:17:39 +0000 X-Originating-IP: [217.138.203.254] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 29cbf04c-a438-4f10-313b-08d7f726ddde X-MS-TrafficTypeDiagnostic: VI1P189MB0479: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0402872DA1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qE2Wrszbh4SChz7ccIJMcwsumhrivnGA2+t3SVcYA0+MH2VIxTC1EAystPnEDuqNKLE5jiXY6TeIpR67LZTjQxWf21cwmTsrw9bwlGAI7Vt3kCVLodUk0tKzTps50f24nvyavFbgYzHkmEGEkEOM5KE1GMKCwQ5fFr5Y27g38G/HCa/ZbJVr3nEaOPBpQb5SRo3/v1SWufSVv2Y5EcKYF1JYThQjzOx9TlFgmIgDvq++D1TSSj1jEcipQEzBM8uZ7PFBYWcwZaKzCmHdtUOsAAXGhkNwZH+PE1OnJZ3g7r2T0GpiqBBXXeqo2hHbOHgFvm+7G2pIy1aKl6DoUvv35d1bg/lkdGW8VePYNZZqPb2cRooo5oGVRMBb/Dy1dkaPk6iOoVvwBie/7w0DuUT14FsT7dD00bc43l1DwiHEKsOyIekmhrNsUGLjiPlYmY6WBn6BTpy/KGeQ+6THTyhfTh0Csuph7qy2dC4dL2CFokjsNOaJBIQaBEOPN7lddo+Urk3JD7gxQNPwjpw3v/iKLH0v/JJ0c9kQivKvBwhjkPhr0HXKsIF/P73G+2MdhQFu9QtdCxVuFjxQ+f7GYKGGcK6XgSDgTXTgPrlKi5DBLUKmMRIXMxnyhrXV6sGiTQk13N11Usut15w9+uyWGmN9Xg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(346002)(396003)(39850400004)(33430700001)(86362001)(66556008)(66476007)(66946007)(478600001)(966005)(2616005)(31686004)(956004)(2906002)(6916009)(31696002)(235185007)(16576012)(21480400003)(8936002)(316002)(53546011)(33964004)(5660300002)(8676002)(33440700001)(52116002)(16526019)(186003)(26005)(36756003)(66574014)(44832011)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: N3egrGyQgSFNc7uuB3soOUqh67xKw3k0bwsJaixnaVJs/RdHc3sYDiNpWB/8JYTftJCYi9O50Dpc9GTc4klCwYlzgBAoHFxbunv2ozSTARoYwctVp+L7D5ZQFGiw7oAFQgiCcL9+27ze1jYYE1NUZXeYN+4UDYp56NlsDO7Xqd23UcpfjLO50zhmvPHuHHe/3ntt1CMrCa8ucHr0h7c09y+eLMQKckE3IhgNXTEAfy9J7BCBcn9Os/osT7FQicXhL47ZxrE5upttEZ3jbozWIEPNAJIv+pXgm+a24rqcKjNFEltsIWwUzX8SLJ2jkjZcW1OsHdAI/ijOKzrwgeQBtRzuyibLtvFqc1zAblnDq5FUFRHV59GiqCpNCV+cEElX36WMfSFBII7L4cGTYHfZ02plzBPvU0FAnRDICp6IiC/K1KgyM8j0sBMNiHHTe1AI1gPkN9C0uxwfS6q2y9KUMv4lcgwgVo87Su7SFS59cdI= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 29cbf04c-a438-4f10-313b-08d7f726ddde X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 10:17:40.0847 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dNNba9di5rKOz1Uz8MysSoLC6c1wEzrN4PkeSUfHwQNKVvtM/T3nYq0RjxNDDIQ009t85zZ2/Ack2kj8MMKaag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0479 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 10:17:45 -0000 --14n9jczbDQjF2VCmLmxbSQUsP3ImwumHV Content-Type: multipart/mixed; boundary="EDIMjJmfAA7wG5gB15GN3SN6M3FwUn4qj" --EDIMjJmfAA7wG5gB15GN3SN6M3FwUn4qj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Since there has been positive feedback and there is interest in the WG, we close this adoption call and adopt this document. Authors, please resubmit the draft as a WG document. As mentioned earlier, please use a different name than coap-problem. Thanks, Marco and Jaime On 2020-04-27 18:33, Marco Tiloca wrote: > Dear CoRE WG, > > Considering the interest shown during the April virtual meeting, this > mail starts a call for adoption on: > > https://tools.ietf.org/html/draft-fossati-core-coap-problem-02 > > Please, reply to the mailing list with your comments, including but not= > limited to whether or not you support adoption. > > This WG adoption call will end on Tuesday, 12th of May. > > Best, > /Marco > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --EDIMjJmfAA7wG5gB15GN3SN6M3FwUn4qj-- --14n9jczbDQjF2VCmLmxbSQUsP3ImwumHV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl67yUEACgkQ7iZktA5Y 2kNJwAf/Y+9qFfGTaS//EvUtHUXoLhbsOfbA0hMU9PEQ4UKb68Q036rvg6CE1LM1 Ovb1HZ34gPhCHgiGSK78sPTtE2KVcHSqkdNb/Aent9ul37v0ALfPRMDJ9Fh1N0sd WkC82V8HnFF/aRqB1G/CLBnuPM1CXuaPEPpGTUEFH6tsaYqarK8jePTLC1r1AML/ /UoDbeJGWYwaDUAQbYplZ7PSEPBvhfjWtZH0w1P9/wAwhPAULXvXPZxPUsOmUeZM WhQL3gffTsOAsMiRCmNoxQ8Yqit01w2zjIPWLc3EMh6asKFuDYUDn70EWFdYUijc gYDrTcs1/fv5XTSt5b5Dc0Ior4TMOw== =y9HQ -----END PGP SIGNATURE----- --14n9jczbDQjF2VCmLmxbSQUsP3ImwumHV-- From nobody Wed May 13 03:55:06 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B393A103B for ; Wed, 13 May 2020 03:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1HqgPHUqfEe for ; Wed, 13 May 2020 03:55:03 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF6D3A1037 for ; Wed, 13 May 2020 03:55:03 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id b71so8628369ilg.8 for ; Wed, 13 May 2020 03:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tkZqDcDV363hi1j0GlXE1G1j3cqXFd2yCIRvo7tOVhQ=; b=Jv+83J/hZGfC2VcsH07CeydZPq0l8lUXEGHx9fID7LxAUXOMsCNHGylmoi3FJ7v3J5 TOpQFV786UKafNqcT8ZYrGPFhTa6TPNHx/cZ7ukyYFp2ih6ZzAVDU4QtxyIn6NL7txOm kB0tWY0LjeU+3HpEg8BcgIblMMxUNneJIvXXXxG0JvYErjGEXxxAc7cxr0HCh4FuwrmK OQAHa/QJaHR7S/eSa2ne4/cT/zOCH1GtXxh/mLfNwNSOcmy/T/q2MNjmGzM4HgbH4lXs IQqdrbCPtCHenOguoR8algg5+o6jk/RW85GjV0D7GjdJbAbqqe0Ectxy3JaVq0hN8fj/ znxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tkZqDcDV363hi1j0GlXE1G1j3cqXFd2yCIRvo7tOVhQ=; b=PupQeCPoFV+qVpdso0SgM9rP8BNR+ZfAxaHOUjrdx0+pGSmlsOVncj0xLSJ9pPXHfh Bx/l7mZm1Ak1rl/bwz3ljcSzaCLZB7LmaEcTVg1vHCx5o8MhrsChckyG5yvRDQr8MmUG /Vkis51gqVAXKtUjiUGn3jK5dWprwcoquVbMw+DtzGuIAEMamjmYqhKT1VPdbMzV0WE7 /c1NZ3FW2yFgJqZsVfaJXyGiUhE0LBNA6NEyVVLmN3QeQPo5Bq6VmyYb7WzGSa4JGnPl 2XPhec8JyTz7lFRtz3VVpuY2Cf/pdmWF8Jw+TaEj9mFu2AMlKVk/kdEixg3UJuf5GxKD ujSw== X-Gm-Message-State: AGi0PuYdOWSmGOADo5mfrNhd5bOE0utj8RJoomHcHGJPV1fs5ezoiNGl nqsf/klCZF4VNoGUSnRF+K+GEwTANoiXVrXcEZY= X-Google-Smtp-Source: APiQypKYLdpji/UOjOwndE6BHBa2e6G5Z8NXhR4J63zpYHTe7xYL6lzdc2z0Sr8kvF+oqi4Bjw9xFDDxlHzSt80Qz7U= X-Received: by 2002:a92:c649:: with SMTP id 9mr26973321ill.265.1589367302418; Wed, 13 May 2020 03:55:02 -0700 (PDT) MIME-Version: 1.0 References: <83137462-dfae-7fc6-b691-1973fd01484b@ri.se> In-Reply-To: <83137462-dfae-7fc6-b691-1973fd01484b@ri.se> From: Thomas Fossati Date: Wed, 13 May 2020 11:54:51 +0100 Message-ID: To: Marco Tiloca Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 10:55:04 -0000 Hi Marco, all, On Wed, May 13, 2020 at 11:18 AM Marco Tiloca wrote: > Dear all, > > Since there has been positive feedback and there is interest in the WG, > we close this adoption call and adopt this document. > > Authors, please resubmit the draft as a WG document. As mentioned > earlier, please use a different name than coap-problem. Would coap-api-problem-details work for you? Also, is it OK to add Klaus as a co-author at this point? Cheers, thanks. From nobody Wed May 13 05:34:22 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350D53A10D9; Wed, 13 May 2020 05:34:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <158937326115.10106.8352121478938531792@ietfa.amsl.com> Date: Wed, 13 May 2020 05:34:21 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-versions-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:34:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : SenML Features and Versions Author : Carsten Bormann Filename : draft-ietf-core-senml-versions-00.txt Pages : 5 Date : 2020-05-13 Abstract: This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-versions-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-versions-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 Wed May 13 06:55:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5616B3A0B64 for ; Wed, 13 May 2020 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUKY_ItlrXeG for ; Wed, 13 May 2020 06:55:27 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20057.outbound.protection.outlook.com [40.107.2.57]) (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 42D5D3A0B5C for ; Wed, 13 May 2020 06:55:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VzK4+KIYVj4ffEzyny6/1YcLdEoMpwfXYOhN3BATSJeboDZIinroGzH5sk3x0LK0CmmmPiNuldyCiF4lbXk2el6hIcp7+T1jbh5RVfYDEOC7pxr0PIpmcXFHov/TkPMm9i1bpBYTRNGJ1KkdtHiiSZ68mRBTt2iYBrbp+yfRTCgEbe+IWie1tPD1X9CwaSsucvjpJraKZVqQHjW0BVhExy+Z+pTW1Mo6r7tgrlfh+BSHsZ1aWJnMvhE+z8kucsVNbvDMK77EI0EOiwVSCToZFHA141TNE6iryYb6Uyr6/1f9+tLG+K9uKB61riRT+IIhsNgGw54CRhlMhMl1/3ZNjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EURH54aFbKLxHEDPSb8gTpBdBvfppXsu1fK7gJtBv/8=; b=bG3AouLo8k+b2fcqBMXh1tjr86AEhVOt/Ms48W8NgwcrWVXoP0MWwRX+vWS147hj94htEkDmdUWQy9My9S+6RocpRHAX13PJDgW9yPx5K4mAJVG5llLakpGN9ORyCvEAl0W9j/MD7itFweWVZQwe5ZS+L15JDa/IQ9Ve/nEPAA57G3G1ymbWz0UC8B4SuN00UzYo/KPliamk7z6lYUvnY8WT2CKy5AW0rXHfe5z0kHmN/lNGHegGaPAvy8fN6JvG0g7a9eR1zOyrzXM7YbGncLIFEDqrogEDtCiZVjywIu1igzjtSMnJfptGOFVQyML74zrj6sKqSzK4y4rYsEw1xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EURH54aFbKLxHEDPSb8gTpBdBvfppXsu1fK7gJtBv/8=; b=j9jD8r4U7Jy8nzE2LOsy7do2OAylZMwz+O5ynm9wHbTpT+4ljnLfFZB/KNBj4TzSH+s2XE85sskvoc3K9zmNi2ULXkfvmbFDbdb8tzEh3ZPZJ5VzYC6sf7W8hgAbaEj/5CAJ5VFnShGdBuYS2hv+T8oqIH45rSIV81E3Sbr7VWA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0573.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:38::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Wed, 13 May 2020 13:55:24 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2979.033; Wed, 13 May 2020 13:55:24 +0000 To: Thomas Fossati Cc: "core@ietf.org WG (core@ietf.org)" References: <83137462-dfae-7fc6-b691-1973fd01484b@ri.se> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <14f045da-91ed-2349-3e79-4ae0f036fcec@ri.se> Date: Wed, 13 May 2020 15:55:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ktjhRXX013j9pvrfncVfDfx5tI5x7GS22" X-ClientProxiedBy: HE1PR05CA0151.eurprd05.prod.outlook.com (2603:10a6:7:28::38) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.8.32] (217.138.203.254) by HE1PR05CA0151.eurprd05.prod.outlook.com (2603:10a6:7:28::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30 via Frontend Transport; Wed, 13 May 2020 13:55:23 +0000 X-Originating-IP: [217.138.203.254] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3d3e0b92-1e97-4ae6-26df-08d7f74548ba X-MS-TrafficTypeDiagnostic: VI1P189MB0573: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 0402872DA1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: X9Pg5C+ukcmwzRUHmEunJvZ9Z9RvLueLvnEIXhW7P7dVfVt7BAcI6VZHQamOtETyMWmbtSmbTyS00byUfJaQrP/u5SWYj1nqQjEUFisldAXmSK1MKXit0Fl9XCOl3mbkzoPLS8Ec1bf+jeLa/XAcdCOFegXAMi2vYAi0InmPh4GpfpmiJzrPBiJqsbEEDM5+g2pvoxRs7HgdKyTiEf6MvwEYnEbZKlcMqG5PHGKI9rvbuZild9jTZy1IdWAKw4D4aXG9dpK4xqIO8Z0XmjvMOm5NplF8gSjH2JDrPpxoIVzVhovuuL5CX6piboT81Gf7YapKeo+EV2yf/2Wb7u84/broHjVs2sWzzFTE0boOvgXKsoMFVeqT7EH+Nn73jDYVpc6YkwJRsFJMZfK+RwqgwtN+eJ0t+30s7LTtNPOXfJBmkEzVFl+LXjphz0JWV6DeiX/WwGk0y/6XeCunYssnxzaulwpamE4oVN1O0l9TY1lZ0SQDQNSBk8mr9KzSSlL+Z6hvDCVVrHCO0kAEbC97Tyfl/XgZFg+hppcl2141qVXdQd4xlaA2vBjUDqTfHjOXq4fFel822RQhjGYulnY65zUHd2LxSC4dCN6R2YolGnPXTbYeGOTxVW5uKfHFRLbtv+AACcjFdFITpgzAMAFokw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(33430700001)(186003)(31686004)(44832011)(16576012)(316002)(66476007)(4326008)(6486002)(36756003)(66946007)(66556008)(6916009)(16526019)(478600001)(8676002)(2616005)(956004)(8936002)(52116002)(235185007)(53546011)(33964004)(26005)(31696002)(2906002)(66574014)(6666004)(33440700001)(86362001)(5660300002)(21480400003)(966005)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 8mZkC4+5Tvg5X9aN/EyUc+vmisEUbqtjPSUaW9e4gai9UztFh9qQSZt7HTuBNTbtVlUge2gcjlCYeuxUDGBAzVylB3jlfMFa2HT3f8T14m4fRWQDJVfcwz7U9GG8hrwMpQ9ra7hfuwEJnq6hpNfhU8mBEPaQfrtLxW3YUmnKkyeFgRy/LOHfDXCtft9PlxzTsyFcTEkvJJMh/5TBlTcoQEu/3zMztYH7El7ToEwlwP6U2fFmjewxWT8xkLVau9tV3cLkVuJxh9lc0VnjRYmSp2g0riIHFzpxxSvsZhpApnQJ+hRvtuVDU6Eyk+mUio1kZl7qWCHuPKAgtrv9Z+WzRaZNIDeF7spEyzxsjM1XZIFiOShIMQ3NTfGpVvWu7OhSsTxhOQEVwYN/JmFaOGkaQqfccFQg2vM/ffVWduYm9WnwBEgJNnzb9tGiHiLX1XDnhT7jz9/j4S77sUBmmLceTnBlcP1lVs0MbBB6+h2u0sjvQtVa/8Tl/bM2GEodKJf8 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 3d3e0b92-1e97-4ae6-26df-08d7f74548ba X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 13:55:24.3326 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kRSpf7MPpWsGG6BUZ9d6SeRQecT00V1Ta5GKDygX1oB0uI5YgNfZQjiStG8FpTF6xTF99pHGDYGIfOTi2GyTzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0573 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 13:55:31 -0000 --ktjhRXX013j9pvrfncVfDfx5tI5x7GS22 Content-Type: multipart/mixed; boundary="KOzXI9sPnXTmTST1J3hWutmtYXIswDob3" --KOzXI9sPnXTmTST1J3hWutmtYXIswDob3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Thomas, Yes, ok to both points. Best, /Marco On 2020-05-13 12:54, Thomas Fossati wrote: > Hi Marco, all, > > On Wed, May 13, 2020 at 11:18 AM Marco Tiloca wrot= e: >> Dear all, >> >> Since there has been positive feedback and there is interest in the WG= , >> we close this adoption call and adopt this document. >> >> Authors, please resubmit the draft as a WG document. As mentioned >> earlier, please use a different name than coap-problem. > Would coap-api-problem-details work for you? > > Also, is it OK to add Klaus as a co-author at this point? > > Cheers, thanks. --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --KOzXI9sPnXTmTST1J3hWutmtYXIswDob3-- --ktjhRXX013j9pvrfncVfDfx5tI5x7GS22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl67/D8ACgkQ7iZktA5Y 2kP5owf/Yg2iyJgYi6GZs7qEZlKB47PXbG/uDFRZ/wevegDxfcV2NsCx1i2vaxjJ OLoqAxc2KjAWHfoa+ZbAjAQVjiBDjeySs+kVNDVVbWSUuQUxk1N0mPaxBsgN+Cq5 Vbezd4EVCM0H0lCCxEJAFYYQthzJN4eZ+KVuuYxI7j1ggibvPho7HfcNqfo+Yi9k ZF28K7kAk9adnwn/IgSiIxEDuvXQy6PfJvs8nLorJ0p9jNP9XHhZKA3mDqz/PASD masQ9nVWDKqL6u3J0GQ2WSSUK7/r/xKftCoALyUbDkvC42+7v4N/cpcfb/mLMzF2 SrrzOwpyNDnUWcFRPR6kJ4vslfbmZw== =QQIM -----END PGP SIGNATURE----- --ktjhRXX013j9pvrfncVfDfx5tI5x7GS22-- From nobody Wed May 13 08:49:27 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 973013A0DBB; Wed, 13 May 2020 08:49:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <158938496555.5003.17457895903813256820@ietfa.amsl.com> Date: Wed, 13 May 2020 08:49:25 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-problem-details-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 15:49:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Problem Details For CoAP APIs Authors : Thomas Fossati Jaime Jimenez Klaus Hartke Filename : draft-ietf-core-problem-details-00.txt Pages : 13 Date : 2020-05-13 Abstract: This document defines a "problem detail" as a way to carry machine- readable details of errors in a CoAP response to avoid the need to define new error response formats for CoAP APIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-problem-details-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-problem-details-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 Wed May 13 15:46:21 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A643A0418 for ; Wed, 13 May 2020 15:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKhsFqVTnyBM for ; Wed, 13 May 2020 15:46:16 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07013A0414 for ; Wed, 13 May 2020 15:46:15 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 133DC40631; Thu, 14 May 2020 00:46:12 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6DE97186; Thu, 14 May 2020 00:46:10 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:fd03:b3b6:a60b:761b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 19C64180; Thu, 14 May 2020 00:46:10 +0200 (CEST) Received: (nullmailer pid 2821187 invoked by uid 1000); Wed, 13 May 2020 22:46:09 -0000 Date: Thu, 14 May 2020 00:46:09 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "core@ietf.org" Message-ID: <20200513224609.GB2724077@hephaistos.amsuess.com> References: <20200511125541.GA2576239@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <20200511125541.GA2576239@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Review of draft-bosh-core-new-block-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 22:46:19 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, following up on the interim discussion, I'm trying to make the examples a bit more plastic and tangible. An example of Block1 flow (the previous one was slightly flawed relative to its description) -- assuming the server is spooling up the complete request, and illustrating it by the client asking for ackowledgements every few blocks to err out early (though in the DOTS use case, everything would probably just be pumped out in NONs with at most a CON or a NON without No-Response at the end): CoAP CoAP Client Server | | +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:1/1/1024 No-Response:2.xx +----X | NON PUT /path B1:2/1/1024 No-Response:2.xx +--------->| CON PUT /path B1:3/1/1024 | | |<---------+ ACK 2.31 +--------->| NON PUT /path B1:4/1/1024 No-Response:2.xx +--------->| CON PUT /path B1:5/0/1024 | | |<---------+ 4.18, payload `missing 0-1024, 2048-3072` +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx +--------->| CON PUT /path B1:2/1/1024 |<---------+ ACK 2.04 Changed Those who are baffled by the 2.04 response to the non-terminal final block: The server is just making ample use of the 7959's license around "whether to handle the request for the entire body atomically, or any mix of the two". It could certainly be discussed whether the block that triggered the initial 4.18 would be acceptable, though, or whether the client would need to retransmit that. The server in this example is going out of its way to ensure all received data is processed. More typical servers would probably start 4.18'ing to the second request already (as their atomic updates need to go from the start), and may require blocks to arrive not too far off, up to the strictest servers that need messages in the right sequence. Except maybe for the corner cases if the initial and the last block, this should all already be within the specified block-wise behavior (the new media type for the 4.18 being the only addition). {Followers of a "updates should never be atomic but always per-block" school of thought might take more liking to an alternative model in which all blocks are accepted, and the client can verify that a full representation has been uploaded by getting a representation of the resoruce in a 4.18-payload equivalent "content sparseness representation". This works best if resources are created by a PUT instead of updated by a PUT, and can be made into an efficient exchange using the Leisure-For-Responses option as in footnote [2]). For the Block2 case, in addition to the generic non-traditional extension proposal[1], let's have one option More-Blocks-Hint, which indicates ranges of content the client would like to receive on the Leisure-For-Responses tickets. Unlike Leisure-For-Responses, while technically still hop-by-hop, this option can be elective and proxy-safe -- sure, proxies work better if they treat it hop by hop, but a proxy's ignorance of it won't break proxying. Then, a similar Block2 exchange could look like this: CoAP CoAP Client Server | | +----------> GET /path B2:0/0/1024 Leisure-For-Responses:3 | | More-Blocks-Hint:1,2,3 (or `1024-end`) | X-----+ 2.05 B1:0/1/1024 <----------+ 2.05 B1:1/1/1024 | X-----+ 2.05 B1:2/1/1024 <----------+ 2.05 B1:3/1/1024 +----------> GET /path B2:0/0/1024 Leisure-For-Responses:3 | | More-Blocks-Hint:2,4,5 (or `2048-3072, 4096-end`) <----------+ 2.05 B1:0/1/1024 <----------+ 2.05 B1:2/1/1024 <----------+ 2.05 B1:3/1/1024 <----------+ 2.05 B1:4/0/1024 I hope this makes the proposal more tangible. Kind regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/KPDCO9mQNzYjAuGwjV6FWWEkAH8/ [2]: CoAP CoAP Client Server | | +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:1/1/1024 No-Response:2.xx +----X | NON PUT /path B1:2/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:3/1/1024 No-Response:2.xx | | Leisure-For-Response:1 |<---------+ NON 2.05 For-Request:(Uri:/path, | | Accept:application/sparseness+cbor), payload | | `missing 0-1024, 2048-3072` +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:2/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:4/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:5/0/1024 Leisure-For-Response:1 |<---------+ NON 2.05 For-Request:(Uri:/path, | | Accept:application/sparseness+cbor), payload | | `all here` --=20 There's always a bigger fish. -- Qui-Gon Jinn --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl68eK4ACgkQOY0REtOk veG3kQ//cMO1aWMZJWxq9wzBTxGiQrO1km7vDhCeGCa55ZYrUTi/vx44iaGWQmN7 odHpgYNO7Cd1/j+bZZrF002sMkdcx5ARUaDCmK98ydGpGIw+nnbkdSUGzP7CAO2v TsbZAemrAHxNxQJvNhV7HV0iUnOy48uPXDcjQUM4iq/qtzZAULIJMwS8vLe67wrG lPZkKX6+wiVlb6YT8CBYI7ZsB9uEYVt/bNWN9DcdslWbNgUs2m+A0gRRb+7REkKD NExBH1zVTumLrOrM24LOcJSwdLR7JHXDMlhQ9QD9QYDyflwySppBIGd7eflmhrLn OM7knbZFJC8Re9abia8ZYxHoDuQk6CgE5Zz86BnjYJa22taQU4xs1bJ14FqveUTw u56RojcxggUU2eUzwlP/JkV/nB0gXAgUPnmaaMv/+ziRLSkNcw6v+BwefFrtAZ5j dFguun+7ef4mTK8Tunyl54e9WZC+19Oem134oTkiAXhUSei1DPeyOiyJSgt/H+O5 DIoIPX6Uo5cvVVjWvSe+oKgZfyBr4e2F5FuFLs6Kc0vLkzKaO3O240dOusxQBTUh HV99HPCtV1GIdu/6pUpLiXS/8E/8TM7lxwUSHD6mrtWhyz45L+Bf8BrWPjy8WEcS sJ7SjWHBErjHpvV7EvzrvtlakidjlgQH0IjJCxJRMSgEM7E0mVw= =L/LK -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From nobody Wed May 13 23:58:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A453A094A for ; Wed, 13 May 2020 23:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_tacWMWeLmD for ; Wed, 13 May 2020 23:58:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB883A0BD4 for ; Wed, 13 May 2020 23:58:41 -0700 (PDT) Received: from [192.168.217.119] (p548DC699.dip0.t-ipconnect.de [84.141.198.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49N2Sb16MDzydJ; Thu, 14 May 2020 08:58:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200513224609.GB2724077@hephaistos.amsuess.com> Date: Thu, 14 May 2020 08:58:38 +0200 Cc: mohamed.boucadair@orange.com, "core@ietf.org" X-Mao-Original-Outgoing-Id: 611132318.136848-c18a3fcf5b59d962bb8c35befd4ff4e9 Content-Transfer-Encoding: quoted-printable Message-Id: <7C0A50A8-352E-4989-B86C-8A5F7352E882@tzi.org> References: <20200511125541.GA2576239@hephaistos.amsuess.com> <20200513224609.GB2724077@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] Review of draft-bosh-core-new-block-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 06:58:44 -0000 Hi Christian, Picking one detail here: > On 2020-05-14, at 00:46, Christian Ams=C3=BCss = wrote: >=20 > |<---------+ ACK 2.31 That is the provisional response that is already defined in RFC 7959. > |<---------+ 4.18, payload `missing 0-1024, 2048-3072` That is not a provisional response; receiving it would stop the client = logic for a block-wise transfer. I think this message needs to be = clearly identified as a provisional response as well.=20 Similarly, but on the level of the individual request, each non-final = response would need to indicate that further responses will be sent on = this request (i.e., with the current token). (And that behavior would need to be solicited by the client; I think = that is your more-blocks-hint.) A completely separate question is how to encode all this information; we = could add options to go along with the basic block1/2 machinery (bonus: = some of these could be elective, which might help in a non-DOTS = incremental deployment situation), or we could simply define a new set = of options like Block3/4. The latter can be made very compact, but it also starts to require some = non-trivial encoding work (with optional/variable length parts and all = that), which would better be covered by the existing Option decoding = logic. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 14 03:13:07 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAB3A0887 for ; Thu, 14 May 2020 03:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENeoPbkChJHz for ; Thu, 14 May 2020 03:13:02 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123843A0771 for ; Thu, 14 May 2020 03:13:01 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 45FDF40644; Thu, 14 May 2020 12:12:58 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2718F186; Thu, 14 May 2020 12:12:55 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a8fb:2e93:817f:6ef4]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B3E8A10A; Thu, 14 May 2020 12:12:54 +0200 (CEST) Received: (nullmailer pid 2852772 invoked by uid 1000); Thu, 14 May 2020 10:12:54 -0000 Date: Thu, 14 May 2020 12:12:54 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: "core@ietf.org" Message-ID: <20200514101254.GA2842448@hephaistos.amsuess.com> References: <20200511125541.GA2576239@hephaistos.amsuess.com> <20200513224609.GB2724077@hephaistos.amsuess.com> <7C0A50A8-352E-4989-B86C-8A5F7352E882@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <7C0A50A8-352E-4989-B86C-8A5F7352E882@tzi.org> Archived-At: Subject: Re: [core] Review of draft-bosh-core-new-block-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 10:13:05 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, CoRE, > > |<---------+ ACK 2.31 >=20 > That is the provisional response that is already defined in RFC 7959. Yes, this was just to illustrate how No-Response and Blockwise interact. > > |<---------+ 4.08, payload `missing 0-1024, 2048-3072` >=20 > That is not a provisional response; receiving it would stop the client > logic for a block-wise transfer. I think this message needs to be > clearly identified as a provisional response as well.=20 Mh, I *was* missing out the M bit value in the response, which indicates whether the server treated as part of an atomic operation. There's ample leeway for the server to treat parts of the transfer as atomic or non-atomic, so if it does respond 4.08 Request Entity Incomplete that doesn't necessarily relate to the *whole* message, but at least the last block needs to acknowledge all the previous ones. Maybe some redesign of block-wise *is* necessary for the Block1 case. > Similarly, but on the level of the individual request, each non-final > response would need to indicate that further responses will be sent on > this request (i.e., with the current token). > > (And that behavior would need to be solicited by the client; I think > that is your more-blocks-hint.) (Assuming this is about the Block2 example), The indication for the additional responses on the same token is given with Leisure-for-Responses; More-Blocks-Hint is just the indication *what* the client would like to have with those (and I've kept it separate from Leisure-For-Responses so a proxy doesn't need to know it). > A completely separate question is how to encode all this information; > we could add options to go along with the basic block1/2 machinery I'd slightly lean toward making More-Blocks-Hint independent of the block options, as this would ease handling them across a non-caching-but-possibly-fragmenting proxy. On the downside, encoding that in CBOR takes 6 byte per hole (2x uin16_t). For best encoding efficiency, the option could sure be merged into a more powerful Block2 option that would be proxy-unsafe. That could then also imply `Leisure-For-Responses` in a single go as well. (In figuring out how to encode this all, it may well be that Leisure-For-Responses never hits the wire, and is always implied by some other options. Then still, a Block-with-Extras option and Response-Forwarding[1], as well as any other longlived-token options, could refer to a single description of how those are done rather than touching the token process each on there own -- and implementers would just flag those options as "having longlived token properties"). KR c [1]: https://mailarchive.ietf.org/arch/msg/core/AwYqnQu703V5RGR43JQxRslkYsw --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl69GaAACgkQOY0REtOk veHbjw//ZJNWDaQWQmrI3hwS/jCjtg6AHGoC3WH01kVJjB908tq9Yp5u54WVzWzj vOmXFMVR5V8RxbVA2qw3eqMnnYxAAO/bZ8YPskLE8anhfCiFd1RhugXbShtQBIKp r+vnhzQNDbZHEBnYt3A+CYkliMg1W3JxVI7Qs6AwPJPWQ2rfvG5iiQ7+aj54jLGV NiF5vIkP+oF5QybrCSXdc62V5+WShCadk6NgXw6IhG7XsW9y075Uae00wY9rdDIc tgY4bREUFeuYfMeqbu5sG9+ccgmTg7hSb+TSztU5Ssex3LPxK9KZd9jUA402/gXj IYlvyp0WBDw2rUxiPBl+rtIDreSAGPK7/fmRShE7NhPM+LOP+H1oiyivJYuwYKQv qrFpkGxnB4rJuegM0NBuz5zraDf3eIR2RBht5MnGe0lBBmJeF7PJI/YkBuIITdwB r9wOH7ipMRO6NgxCC8D4wMVCuc3GfVXOHdu4Rp5jI2K8CAY9xbokLGsap168+ELy GE1fmXBtVb5/MjJWJKmb/9+bs7MXIm62A2wZJtM+ttnbK87cIVuwNxrdDMuM9s6y yVqwcfyUvxxxPv+0HZiLYf4Y3NSdHj76WwqPlclD5h6HUs2mji6SQjimo1gLYDKk Jer6GLqYcHx/Ki0GvdzH89Lon+xG8JtFlVAHd5jHLn+zTchIk4w= =Ebcr -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From nobody Fri May 15 04:40:58 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575463A0945 for ; Fri, 15 May 2020 04:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=RBwk56r9; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=RBwk56r9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx0cuav_kZb8 for ; Fri, 15 May 2020 04:40:54 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60078.outbound.protection.outlook.com [40.107.6.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C269B3A0944 for ; Fri, 15 May 2020 04:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BJ3ukb9Y+a7NLw3lBLfY10gIuyHBNRHH9mg91yXNcD8=; b=RBwk56r90A6x/5hXC67LEVpQoyiyo03WSRId+jQFc/JkRUCFRyQbhZkD+5Ac1kKneuww1XK9uwM+PSKZeq+FoGJjSVduqeH6hMGpLDz7vYL9orv0GZaJ0A8ZEP9mOSGo2dKYw7qifXxy1cywyH4hKaYT15OUI222p2h0yGO6Evo= Received: from DB6PR0601CA0039.eurprd06.prod.outlook.com (2603:10a6:4:17::25) by DB8PR08MB5210.eurprd08.prod.outlook.com (2603:10a6:10:e7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.25; Fri, 15 May 2020 11:40:50 +0000 Received: from DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:17:cafe::e1) by DB6PR0601CA0039.outlook.office365.com (2603:10a6:4:17::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20 via Frontend Transport; Fri, 15 May 2020 11:40:50 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT049.mail.protection.outlook.com (10.152.20.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Fri, 15 May 2020 11:40:50 +0000 Received: ("Tessian outbound e88319d7ccd0:v54"); Fri, 15 May 2020 11:40:50 +0000 X-CR-MTA-TID: 64aa7808 Received: from 0b7da1e70d32.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3B9CACE3-6A8F-4B3F-873E-ED6E62A075D4.1; Fri, 15 May 2020 11:40:45 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0b7da1e70d32.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 15 May 2020 11:40:45 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=isnMvGjpo3/UR6ilhIkWg7n85XvJ3J66aDY1F1k1Zk2z8lTU0QLMcem3jvrJbpJxDNB5HhgoDmH6fpybh+8qEuAul9RuctLtOIxORK6/sU2vM6qP73IrOGrpmERHyzPso/gTftnyhG6Q+KG5jSAtBdQHUMDFNaiApQ08a8cq9miD8kBW/s728I6Yjik8gaVBt5BoZCnI0ePl1+JfvVBDR6xMnGqAbDievg1B6NiB09+eNL1sHdciTMAMNrG0ZLgcTAM0e7TJSzGF7VqPL/MGvy38buA0W6woBxWpArQfMryA3l9tKlEupbAxPof26t69ib7vqW2/2cNrcwrfu44YAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BJ3ukb9Y+a7NLw3lBLfY10gIuyHBNRHH9mg91yXNcD8=; b=K8bjg4N1CweI1vGxQsYmfs2pzNn63P4P1tLKsBohdqjce04vyVjot7Gqc2cOxUWKyD+idlT2dTh5q+9MKRJeu5STSyp/IHC+7/Q1EZhijNHa7z9kx1cdjEj5PNo6fTDRHf3wVkCQElqCpgp5naigaGBUPnY5u3mgsBzwB2rnkoetOxq5aJp3Pqmw/WNY598t3wJ3YR7LOucQwCXGHzZxV3kKVlT42kx434VWvJoCBz9QcWFSnYzyODIF7BZXec3CcP3YrEeecDGLmJGXiwXjPt1a/t/e+Vlqmk3eT+VJ2WJ8vdgZCa7jvOmJmTpZjSpRJhFp2UBLr4afbRhC8HC57g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BJ3ukb9Y+a7NLw3lBLfY10gIuyHBNRHH9mg91yXNcD8=; b=RBwk56r90A6x/5hXC67LEVpQoyiyo03WSRId+jQFc/JkRUCFRyQbhZkD+5Ac1kKneuww1XK9uwM+PSKZeq+FoGJjSVduqeH6hMGpLDz7vYL9orv0GZaJ0A8ZEP9mOSGo2dKYw7qifXxy1cywyH4hKaYT15OUI222p2h0yGO6Evo= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3298.eurprd08.prod.outlook.com (2603:10a6:208:5e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.25; Fri, 15 May 2020 11:40:43 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3000.022; Fri, 15 May 2020 11:40:43 +0000 From: Hannes Tschofenig To: "core@ietf.org WG" Thread-Topic: Adoption call for draft-tschofenig-uta-tls13-profile-04 Thread-Index: AdYqjQwZv8CXusbCTpW9cQ/tE7pxGwAB00oQAAZEeoA= Importance: low X-Priority: 5 Date: Fri, 15 May 2020 11:40:43 +0000 Message-ID: References: <000401d62a8d$e3b9ac80$ab2d0580$@smyslov.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: ad0fe653-00ae-4df4-8287-06b374b59dfc.1 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.122.242] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6683094f-38d5-4dc4-6e3b-08d7f8c4d11c x-ms-traffictypediagnostic: AM0PR08MB3298:|DB8PR08MB5210: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 04041A2886 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: MjtjWdHUjPYf3TqVF60cjA0jay9ftDPun4CZ2gR9MGDlQanYCNGqnZFEFptl1Lyu8Y9IsQ0+sG+wm5CJ9RD3r+t3voY9hARbRRh/dHvdYy8ufWjdu2DIvbrIeWj+fi9qpqG/N8RU0vgbdQ+ZrVwYRyE5z+YGigw9GtpxvhhV3xBNVb9LZaXZeJxL5I3TRr3hrcskWW1QbrSEbugCKRKSrkQjEvH0M1bS8XK3gjRiNynX7f9si20X9wPH2R8qrlGLgFrdiz4vW5K4SsUbqd5Z0rS+8UshLwH+R6ErJLI3GpdFbqivWecXhrT4/ZOeCho88xIqVyhU94Mnab2hxpMGeyoxEvdEwHYZs2dIJrEfatUmDQRyoFOuh/Y0fg41PCEdvFTWvZA+xne3vQ/OIiXYpcRyLA/PYBcNL2aj4CAnUgdQrDEY4qiRWJ7Wv2B4ICMr8QcF2dbyj4T/LN8tlJ63ErNZjjMYK9Uh34HJb8SvrbbDIu9x+eJuw1RyfM4E7biuXNTiwZXLA8BfoWocsINFmw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(366004)(39860400002)(136003)(346002)(5660300002)(66574014)(66946007)(55016002)(33656002)(478600001)(64756008)(9686003)(71200400001)(66476007)(66446008)(66556008)(2940100002)(76116006)(966005)(7696005)(8676002)(8936002)(2906002)(6506007)(316002)(53546011)(52536014)(26005)(86362001)(6916009)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: o2Uq2Kv2aZRppwvijFDU82u7bp21nut+6Td+/5ofPIvGQFtCoCixlJvuHDRE8rpQKeRi7GsVDAgUNey++96iY51jealyLwZ2qPrCZhCBE6W+efG9ES78KexiM9F1BCmqLqpXsUjqZZc/tqBdpJ6Xc8ByTIfzfqjjtFuJKXFIVuNj5R9k1niwXvMkyuz6sc9/bCmk9ai+MMXoPpVm79y9vxv51xCHhN2Q52/xuCWakOnmB4fzQDeSdjMMWQf7lfumRu2IfHgSwV05SC7z4rzMEB3zz492hhLcbSIcfikXTmBUb/ahkFsBUh8SqPvulN+92UA0nZKDUojD1ZYUgLHfSdfgCd5ow5Y70chqZor7tcfAhW1ijxvnI5+kBL2Gk3esIrrOptIAjzLI4PUZkHGheE4334s7wHevpvZBwYgeGDLaojMNywhAcU1AgEKBdEPbN86kdzUEL3iThJIHVxi//kJr8qZJSng2h4fRiE/7ItchFusFgVBnRah5TOYPwzfb x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3298 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(46966005)(6506007)(6916009)(53546011)(478600001)(2906002)(316002)(52536014)(966005)(70586007)(26005)(186003)(336012)(70206006)(2940100002)(9686003)(55016002)(47076004)(66574014)(81166007)(8676002)(5660300002)(356005)(82310400002)(8936002)(33656002)(86362001)(82740400003)(7696005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: eb91a601-fc3b-497f-a7dc-08d7f8c4cd49 X-Forefront-PRVS: 04041A2886 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9/wPfpsN7PXRVhhytHBxf0PJ6HROk7cfG8un3S/5Z6DXJXkte8HnNuzQacD6c57eYrF7q7+MA6yaL+UgYMEqXVSvr/dqFcd1qdrihGMyO9lPcfirKHNxFOzHToyRVD2wZ73BhY9Sx41LT5dpikxKYaDgoleg51sO4qUd3Q41NmHrIP8dcb8aGZk4nWcTjTWQb7Q2qKnivScs8beAN3LELmITcOv1UrT8p8JFbevfHY8JWqeBU/xCNmxz7bYtwFse6TsbqNux9it329ZIpMt0qe2RCRrvP8B7HHEF/glfItZnxFNJ+DiOd/nVps0NDXx6prtGJA9TNV2jqR4EK4xglWU19UJaTa2Dz6kt/Noyj4bTT4BiSs13LA5dwX/WcUiMiulvic1jPYNVBUYeF2q0nzYPUQcUxoUd+QxB6P8tcdUAyAOo3WO9h9v5CZsu5tbM3mOZjEbuqNeqgtDliznPtbZeVORxtWhJyYlaJx/1+qBCcgtVp38RmVHDnpci8xJIootow6ftC+5K5eAhJR18mXNPxEvrBtuckk//K6N0Kz4xQXfjkcwNvPl0cbnRGBwElGME/ymf1Wsugv4CeE9zaQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2020 11:40:50.1729 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6683094f-38d5-4dc4-6e3b-08d7f8c4d11c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5210 Archived-At: Subject: [core] FW: Adoption call for draft-tschofenig-uta-tls13-profile-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 11:40:57 -0000 I believe that the adoption call for the TLS 1.3 profile for IoT is relevan= t to this group. Your support on the UTA list is appreciated! -----Original Message----- From: Hannes Tschofenig Sent: Friday, May 15, 2020 1:39 PM To: Valery Smyslov ; uta@ietf.org Cc: uta-chairs@ietf.org; Thomas Fossati Subject: RE: Adoption call for draft-tschofenig-uta-tls13-profile-04 Thanks, Valery for starting the call for adoption. Let me provide a bit of context for those who weren't able to attend the vi= rtual interim meeting*. RFC 7925 provided profiles for IoT devices concerning the use of TLS and DT= LS 1.2. These profiles are used today in deployments and other SDOs are ref= erencing that RFC for their IoT protocol specifications. While there were many aspects to consider in 1.2 there are far fewer in 1.3= because the TLS 1.3 specification was only finished mid 2018 and the DTLS = 1.3 RFC is about to get finalized now. However, there are two areas were de= finitely need to say something about 1.3 usage in IoT environments, namely * Algorithm recommendations (because those are different than the algorithm= s used on the web), and * the use of 0-RTT in IoT protocols like CoAP and MQTT. In addition to those points there are some recommendations that would be he= lpful to cover in draft-tschofenig-uta-tls13-profile-04, which are relevan= t for 1.2 as well as 1.3, such as the use of alternative certificate format= s (using CBOR encoding). This was a point raised by John. Other aspects inc= lude the use of CIDs and how they relate to CoAP and CoAP Observe, the use = of "unlimited" certificate lifetime for certificates that are part of the r= oot of trust on those devices, and there are more items in the slide deck*. The participants at the call asked for the scope to be restricted to TLS/DT= LS and not to focus on cTLS because it would otherwise take longer to compl= ete this work. I believe this work is useful for the IoT community since TLS/DTLS is used = by all major IoT device management providers. Ciao Hannes (*): Slides presented at the virtual interim meeting are here: https://datatracker.ietf.org/meeting/interim-2020-uta-01/materials/slides-i= nterim-2020-uta-01-sessa-tlsdtls-profiles-for-the-internet-of-things -----Original Message----- From: Valery Smyslov Sent: Friday, May 15, 2020 9:53 AM To: uta@ietf.org Cc: uta-chairs@ietf.org; Hannes Tschofenig ; Tho= mas Fossati Subject: Adoption call for draft-tschofenig-uta-tls13-profile-04 Hi, during the last virtual interim meeting the draft-tschofenig-uta-tls13-profile-04 was discussed. The authors of the draft asked for its adoption by the WG an= d a quick poll during the meeting indicated that participants were in favor= of the adoption. This message starts a two weeks call for adoption of the draft-tschofenig-uta-tls13-profile-04 draft to confirm the results we saw a= t the meeting. The call will end up 30 May 2020. Please send your opinions to the list bef= ore this date. Please if possible include any reasons supporting your opinion. If you supp= ort this adoption, please indicate whether you are ready to review this dra= ft if it becomes a WG document. Regards, Leif & Valery. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri May 15 11:48:16 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7D33A07A8 for ; Fri, 15 May 2020 11:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-iGan7keqGA for ; Fri, 15 May 2020 11:48:10 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F963A07A3 for ; Fri, 15 May 2020 11:48:09 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1jZfNK-0004pl-Kr; Fri, 15 May 2020 19:48:02 +0100 From: "Jon Shallow" To: , , =?iso-8859-1?Q?'Christian_Ams=FCss'?= References: <20200511125541.GA2576239@hephaistos.amsuess.com> <20200513224609.GB2724077@hephaistos.amsuess.com> <787AE7BB302AE849A7480A190F8B9330314BB38E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314BB38E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 15 May 2020 19:47:54 +0100 Message-ID: <147c01d62ae9$58320cf0$089626d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGNJFzfMXxW/x5txFCxzgwGwhhLkQI0lc/PAZ6YK4GpHLv+kA== Archived-At: Subject: Re: [core] Review of draft-bosh-core-new-block-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:48:14 -0000 Hi Christian, Thank you and all the others on the on the Interim Conference Call on Wednesday - I found it very useful. I have been trying to get my mind around everything, including the new potential options and how I can practically implement things in the potentially aggressive DOTS environment. In summary, I am concerned with your proposal as it stands as uses new additional options (one specific to Block2 usage) that modify the = semantics of how Block1 and Block2 are used as defined in RFC7959 along with some potential design / implementation flaws. That said, there are some good ideas that may need to be wrapped into = the Block3/BLock4 alternative. Please see inline comments prefixed with Jon> Regards Jon > -----Message d'origine----- > To : Christian Ams=FCss [mailto:christian@amsuess.com] Sent : Thu 14 = May 2020 00:46 > To : BOUCADAIR Mohamed TGI/OLN Cc : core@ietf.org=20 > Re: [core] Review of draft-bosh-core-new-block-00.txt >=20 > Hello, >=20 > following up on the interim discussion, I'm trying to make the=20 > examples a bit more plastic and tangible. >=20 > An example of Block1 flow (the previous one was slightly flawed=20 > relative to its description) -- assuming the server is spooling up the = > complete request, and illustrating it by the client asking for=20 > ackowledgements every few blocks to err out early (though in the DOTS=20 > use case, everything would probably just be pumped out in NONs with at = > most a CON or a NON without No-Response at the end): Jon> For DOTS, this would be NON without "No-Response". However the = Client may not see the response (DOTS handles this already for the "all fits in = one packet" PUT case). >=20 > CoAP CoAP > Client Server > | | > +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:1/1/1024 No-Response:2.xx > +----X | NON PUT /path B1:2/1/1024 No-Response:2.xx > +--------->| CON PUT /path B1:3/1/1024 > | | > |<---------+ ACK 2.31 > +--------->| NON PUT /path B1:4/1/1024 No-Response:2.xx > +--------->| CON PUT /path B1:5/0/1024 > | | > |<---------+ 4.18, payload `missing 0-1024, 2048-3072` > +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| CON PUT /path B1:2/1/1024 > |<---------+ ACK 2.04 Changed >=20 > Those who are baffled by the 2.04 response to the non-terminal final > block: The server is just making ample use of the 7959's license=20 > around "whether to handle the request for the entire body atomically,=20 > or any mix of the two". It could certainly be discussed whether the=20 > block that triggered the initial 4.18 would be acceptable, though, or=20 > whether the client would need to retransmit that. Jon> There is nothing stopping the 4.18 response not including the triggering block as "missing" if the server otherwise is happy with the block. >=20 > The server in this example is going out of its way to ensure all=20 > received data is processed. More typical servers would probably start=20 > 4.18'ing to the second request already (as their atomic updates need=20 > to go from the start), and may require blocks to arrive not too far=20 > off, up to the strictest servers that need messages in the right = sequence. Jon> DOTS only cares that all of the blocks have been received before atomically processing the entire "body". My suggestion would be that = the potentially multiple 4.18 responses come under Congestion Control. Jon> There is a reasonable chance that the blocks are sent out in = sequence, but may arrive at the server out of sequence as we have moved away from the "Lock Stepped" model of rfc7959 with the 2.31 Continue and need to update the sending of a 4.08 if Block1s are = out of order as per " A server MAY also return a 4.08 error code for any (final or non-final) Block1 transfer that is not in sequence; therefore, clients that do not have specific mechanisms to handle this case SHOULD always start with block zero and send the following blocks in order. " Jon> There is as issue with data corruption with using the above = mechanism. Say there is the following sequence in a DOTS environment CoAP CoAP Client Server | | +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx +--------->| NON PUT /path B1:3/0/1024 | X<----+ 4.18, payload `missing 0-1024` sometime later, new data +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx +----X | NON PUT /path B1:3/0/1024 |<---------+ ACK 2.04 Changed Jon> The server then ends up with Block2-0 from the second data set and Block2-1 from the first. This is why we included the Block-ID in the Block3 option. We could consider using = the Token, keeping it the same Token for each set of blocks that comprise a body, but that breaks the usage of Tokens definition as there may be a non 2.xx response in the case of the first block2-0 transmission in my = example. " A Token is used to match responses to requests independently from the underlying messages (Section 5.3) " Jon> I still believe that we need a Block-ID - whether embedded in a = Block3 option or as a separate option. With Block3, the M (more) bit set is equivalent to No-Response:2.xx. Jon> I am also concerned that we are changing how Block1 usage is = defined in RFC 7959 (change in behaviour with No-Response Option and removal of 2.31 lock-stepping) so the RFC containing the No-Response option will be updating RFC 7959. >=20 > Except maybe for the corner cases if the initial and the last block,=20 > this should all already be within the specified block-wise behavior=20 > (the new media type for the 4.18 being the only addition). >=20 Jon> Not quite - see above >=20 > {Followers of a "updates should never be atomic but always per-block" > school of thought might take more liking to an alternative model in=20 > which all blocks are accepted, and the client can verify that a full=20 > representation has been uploaded by getting a representation of the=20 > resoruce in a 4.18- payload equivalent "content sparseness=20 > representation". This works best if resources are created by a PUT=20 > instead of updated by a PUT, and can be made into an efficient=20 > exchange using the Leisure-For-Responses option as in footnote [2]). Jon> For DOTS, after the initial PUT (of telemetry information), there = will be PUT updates to the same resource as telemetry information gets = updated. Jon> With [2], RFC7252 refers to a 2.01 or 2.04 response for a PUT. = 2.05 is only used in response to a GET. [1] Section for Leisure-For-Responses looks like it is defined for GET = (or FETCH) stating " Leisure-For-Responses --------------------- This new option (elective, proxy-unsafe, uint valued) allows the server = to send up as many responses as indicated in the option value in addition = to the requested response. " Jon> And not PUT. >=20 >=20 > For the Block2 case, in addition to the generic non-traditional=20 > extension proposal[1], let's have one option More-Blocks-Hint, which=20 > indicates ranges of content the client would like to receive on the=20 > Leisure-For-Responses tickets. Unlike Leisure-For-Responses, while=20 > technically still hop-by-hop, this option can be elective and=20 > proxy-safe > -- sure, proxies work better if they treat it hop by hop, but a=20 > proxy's ignorance of it won't break proxying. Then, a similar Block2=20 > exchange could look like this: >=20 > CoAP CoAP > Client Server > | | > +----------> GET /path B2:0/0/1024 = Leisure-For-Responses:3 > | | More-Blocks-Hint:1,2,3 (or `1024-end`) > | X-----+ 2.05 B1:0/1/1024 > <----------+ 2.05 B1:1/1/1024 > | X-----+ 2.05 B1:2/1/1024 > <----------+ 2.05 B1:3/1/1024 > +----------> GET /path B2:0/0/1024 = Leisure-For-Responses:3 > | | More-Blocks-Hint:2,4,5 (or `2048-3072, 4096-end`) > <----------+ 2.05 B1:0/1/1024 > <----------+ 2.05 B1:2/1/1024 > <----------+ 2.05 B1:3/1/1024 > <----------+ 2.05 B1:4/0/1024 >=20 > I hope this makes the proposal more tangible. Jon> As discussed on the Conf call, we need to have a concept of = Block-ID for each "body" of data, which could be the Etag so that the secondary = GET requests are pulling the data for the correct "body". However, I = believe ETag cannot be used, as when used with a GET to get missing blocks, the server (or cache) could respond with a 2.03 as per " A server can issue a 2.03 Valid response (Section 5.9.1.3) in place of a 2.05 Content response if one of the ETags given is the entity- tag for the current representation, i.e., is valid; the 2.03 Valid response then echoes this specific ETag in a response option. " Jon> so believe that we still need a Block-ID here. Jon> The Token for the secondary GET will be different and so the = secondary set of responses will use the secondary token (as does the first set of responses use the initial token). Jon> If Observe:0 is used for the initial GET, then all Observe = responses will need to track and use the initial More-Blocks-Hint and Leisure-For-Responses in the Observe subscription = for the resource on the server. Jon> Again, I am concerned that we are modifying RFC 7959 Block2 Usage = in that the client does not have to request the next block as per " When sending a 2.05 (Content) notification, the server only sends = the first block of the representation. The client retrieves the rest of the representation as if it had caused this first response by a GET request, i.e., by using additional GET requests with Block2 Options containing NUM values greater than zero. " Jon> More-Blocks-Hint would be a new Option that is only relevant to = Block2. If we went down the Block4 route, this could either be embedded in the Block4 option, or the Block4 option can be repeated in the GET request defining in the "missing" blocks. In effect, Block4 request for block0 = is 'give me all of the blocks hint' and a block4 request for block!=3D0 is = 'send me this missing block'. Jon: The benefit of Leisure-For-Responses is that the number of blocks = that can sequentially sent without waiting can be controlled. On the conf = call 10 packets was mentioned as potentially being a good number before = delays should be inserted between packets. Jon> In the DOTS case if the response fits into a single packet and the response is dropped then the client does not care if in an attack = scenario. If there are multiple blocks, the client would elect to either try to recover the missing blocks or just ignore the partial response. ~Jon >=20 > Kind regards > Christian >=20 > [1]: > https://mailarchive.ietf.org/arch/msg/core/KPDCO9mQNzYjAuGwjV6FWWE > kAH8/ >=20 > [2]: >=20 > CoAP CoAP > Client Server > | | > +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:1/1/1024 No-Response:2.xx > +----X | NON PUT /path B1:2/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:3/1/1024 No-Response:2.xx > | | Leisure-For-Response:1 > |<---------+ NON 2.05 For-Request:(Uri:/path, > | | Accept:application/sparseness+cbor), payload > | | `missing 0-1024, 2048-3072` > +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:2/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:4/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:5/0/1024 = Leisure-For-Response:1 > |<---------+ NON 2.05 For-Request:(Uri:/path, > | | Accept:application/sparseness+cbor), payload > | | `all here` >=20 > -- > There's always a bigger fish. > -- Qui-Gon Jinn > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: jeudi 14 mai 2020 00:46 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: core@ietf.org > Objet=A0: Re: [core] Review of draft-bosh-core-new-block-00.txt >=20 > Hello, >=20 > following up on the interim discussion, I'm trying to make the = examples a > bit more plastic and tangible. >=20 > An example of Block1 flow (the previous one was slightly flawed = relative to > its description) -- assuming the server is spooling up the complete request, > and illustrating it by the client asking for ackowledgements every few > blocks to err out early (though in the DOTS use case, everything would > probably just be pumped out in NONs with at most a CON or a NON = without > No-Response at the end): >=20 > CoAP CoAP > Client Server > | | > +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:1/1/1024 No-Response:2.xx > +----X | NON PUT /path B1:2/1/1024 No-Response:2.xx > +--------->| CON PUT /path B1:3/1/1024 > | | > |<---------+ ACK 2.31 > +--------->| NON PUT /path B1:4/1/1024 No-Response:2.xx > +--------->| CON PUT /path B1:5/0/1024 > | | > |<---------+ 4.18, payload `missing 0-1024, 2048-3072` > +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| CON PUT /path B1:2/1/1024 > |<---------+ ACK 2.04 Changed >=20 > Those who are baffled by the 2.04 response to the non-terminal final > block: The server is just making ample use of the 7959's license = around > "whether to handle the request for the entire body atomically, or any = mix of > the two". It could certainly be discussed whether the block that = triggered > the initial 4.18 would be acceptable, though, or whether the client = would > need to retransmit that. >=20 > The server in this example is going out of its way to ensure all = received data > is processed. More typical servers would probably start 4.18'ing to = the > second request already (as their atomic updates need to go from the start), > and may require blocks to arrive not too far off, up to the strictest servers > that need messages in the right sequence. >=20 > Except maybe for the corner cases if the initial and the last block, = this > should all already be within the specified block-wise behavior (the = new > media type for the 4.18 being the only addition). >=20 >=20 > {Followers of a "updates should never be atomic but always per-block" > school of thought might take more liking to an alternative model in = which > all blocks are accepted, and the client can verify that a full representation > has been uploaded by getting a representation of the resoruce in a = 4.18- > payload equivalent "content sparseness representation". This works = best if > resources are created by a PUT instead of updated by a PUT, and can be > made into an efficient exchange using the Leisure-For-Responses option = as > in footnote [2]). >=20 >=20 > For the Block2 case, in addition to the generic non-traditional = extension > proposal[1], let's have one option More-Blocks-Hint, which indicates ranges > of content the client would like to receive on the = Leisure-For-Responses > tickets. Unlike Leisure-For-Responses, while technically still = hop-by-hop, > this option can be elective and proxy-safe > -- sure, proxies work better if they treat it hop by hop, but a = proxy's > ignorance of it won't break proxying. Then, a similar Block2 exchange could > look like this: >=20 > CoAP CoAP > Client Server > | | > +----------> GET /path B2:0/0/1024 = Leisure-For-Responses:3 > | | More-Blocks-Hint:1,2,3 (or `1024-end`) > | X-----+ 2.05 B1:0/1/1024 > <----------+ 2.05 B1:1/1/1024 > | X-----+ 2.05 B1:2/1/1024 > <----------+ 2.05 B1:3/1/1024 > +----------> GET /path B2:0/0/1024 = Leisure-For-Responses:3 > | | More-Blocks-Hint:2,4,5 (or `2048-3072, 4096-end`) > <----------+ 2.05 B1:0/1/1024 > <----------+ 2.05 B1:2/1/1024 > <----------+ 2.05 B1:3/1/1024 > <----------+ 2.05 B1:4/0/1024 >=20 > I hope this makes the proposal more tangible. >=20 > Kind regards > Christian >=20 > [1]: > https://mailarchive.ietf.org/arch/msg/core/KPDCO9mQNzYjAuGwjV6FWWE > kAH8/ >=20 > [2]: >=20 > CoAP CoAP > Client Server > | | > +----X | NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:1/1/1024 No-Response:2.xx > +----X | NON PUT /path B1:2/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:3/1/1024 No-Response:2.xx > | | Leisure-For-Response:1 > |<---------+ NON 2.05 For-Request:(Uri:/path, > | | Accept:application/sparseness+cbor), payload > | | `missing 0-1024, 2048-3072` > +--------->| NON PUT /path B1:0/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:2/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:4/1/1024 No-Response:2.xx > +--------->| NON PUT /path B1:5/0/1024 = Leisure-For-Response:1 > |<---------+ NON 2.05 For-Request:(Uri:/path, > | | Accept:application/sparseness+cbor), payload > | | `all here` >=20 > -- > There's always a bigger fish. > -- Qui-Gon Jinn From nobody Mon May 18 03:35:01 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95E3A0A99 for ; Mon, 18 May 2020 03:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=VssEiYvk; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=VssEiYvk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhErFGxWPZNv for ; Mon, 18 May 2020 03:34:58 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2065.outbound.protection.outlook.com [40.107.21.65]) (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 C36503A0A98 for ; Mon, 18 May 2020 03:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HdXWvkI6GYrbDW72XIq/klVyMkifsnk3DEez7JhG6gw=; b=VssEiYvkRmbhIwm6iQHEUqLRIN3GJAkiGHYazF1F/WLa8e+wHiI3q4P0k49L48Nd16Rt9fiZlX+pcTZD4WMqcqo8wmdHx9m7dMNTjLk/zT2jp3CEgNOjSy3yr+DtWUtj3suqKdpizy2wrYfS8HdR2oCNgTiVwhZzk957wcwTvGU= Received: from AM6P195CA0012.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:81::25) by AM0PR08MB3059.eurprd08.prod.outlook.com (2603:10a6:208:5c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.26; Mon, 18 May 2020 10:34:55 +0000 Received: from AM5EUR03FT015.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:81:cafe::e4) by AM6P195CA0012.outlook.office365.com (2603:10a6:209:81::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20 via Frontend Transport; Mon, 18 May 2020 10:34:55 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT015.mail.protection.outlook.com (10.152.16.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Mon, 18 May 2020 10:34:54 +0000 Received: ("Tessian outbound fb9de21a7e90:v54"); Mon, 18 May 2020 10:34:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8a6526b1ad617192 X-CR-MTA-TID: 64aa7808 Received: from b96086e39526.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4007E8B0-3AAC-4010-A4EE-CE207B701A22.1; Mon, 18 May 2020 10:34:49 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b96086e39526.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 18 May 2020 10:34:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QRfhI2rUwLFcktHRiEExJnkwHdeuSbpUaCESukFMUCZs/heG38jfm3PS2+Bj3u2Iul2C2m4LR/+z6QGZwqFe2F0O07AJQr9OHgWw6Ux/LM+R/VqKVFEqgmt5D+GPHpjD8kRKeba4RmrYw2IL+UXN37F5oRAtly3dEIKHZ2ZQlx6YOJK1rUbVw5MKpesbsXIF5FMKGhttZa8nT3nkvGcYCChSL0TPOtXymhIbu9Az7LjcCzvvmKp3P/kNh+G6md/v28ORidWqx8z5oejZOr77pv42UnD9sd/zLIOfzzT0LJeELvUSLvXkkb6Mjr5yxvimqy+iX7904os79jwJx07hBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HdXWvkI6GYrbDW72XIq/klVyMkifsnk3DEez7JhG6gw=; b=XIOqsdCZKsXKJL/gY4yDFASwevtGZUa6cf+8vlhGfV/Yp+s2cygpdQ1lFi27c8qljQXKQ5443fCXtebm32vqmu1j+cZmUOJCIXIFUsAQzssgUEnM7vqZyN+ZgH5LM0qiGloHwdCE/uYEPkB11iY105RH6Rr4yg8DZRY25xHuW/QzecuSwnWKkppUv1j3mE8SPnH4r1+ZQJTM4vaMA2qYgoM2duMCPvoQGoyUXFZKsaJ2hDbgWHx+yycKVrbClzMzqHiz8ziAmIfax+SuDiCtgtZqMwF4UmdkP6ASP5qDtRl9I9lQr+KHKKH0AKaQmL07aiy65TTcqsdLNW8ITmoFCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HdXWvkI6GYrbDW72XIq/klVyMkifsnk3DEez7JhG6gw=; b=VssEiYvkRmbhIwm6iQHEUqLRIN3GJAkiGHYazF1F/WLa8e+wHiI3q4P0k49L48Nd16Rt9fiZlX+pcTZD4WMqcqo8wmdHx9m7dMNTjLk/zT2jp3CEgNOjSy3yr+DtWUtj3suqKdpizy2wrYfS8HdR2oCNgTiVwhZzk957wcwTvGU= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3014.eurprd08.prod.outlook.com (2603:10a6:209:47::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.27; Mon, 18 May 2020 10:34:48 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.3000.033; Mon, 18 May 2020 10:34:48 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: Anti-forgery limits in OSCORE Thread-Index: AQHWLP/0cQuBLmM7Jk2CInkmhZefIA== Date: Mon, 18 May 2020 10:34:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 291633ed-d1c9-4f3e-bfc9-08d7fb171ae3 x-ms-traffictypediagnostic: AM6PR08MB3014:|AM0PR08MB3059: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:5236;OLM:9508; x-forefront-prvs: 04073E895A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: u2Hyy/if8YDjIGSAGnisLS0WCGhj2VlqcZW/lWEWOUkAp2wRKHQkAjsl5NoFxolC9xOD0klCY45WYRmeHFSMeInqZ0xdoA1+JSri1wcBl3bArfLTzrspazvUOHYfSYgFuN+VbjxHEorJsQ2sIXO9udo5Oxq0MeHW1ixOzPVpJXrToMtIkkktAwM74IfIwPz5RIXAZdQRbbqOAKEgtPef/W9aH9ohTnjbc05jyYDSEwnZ6tIGUjN6+vbMhtqhVWwo7BbEx5g/vK4Oig5L/k573J8x9wMEzz+mFR3khnALcbGGpcfYOcl/qFX1EcpwuqfpPNjxl4Rf8g+0PAuiWgdSsbWMU9A5UdOEgV/1+jgzkAe6FI5u1s6AoUx4Blea4MH6dPtZk184x7gc1HE+WT+uhpSeq7NKZ1LyelM+gYmRu0wQZBQZGsiI7LI2DAa3CAkCXKSYI3kXsPfOfErG4KRtACjZD90LwW22mfO74Osm6HeWqEH3j0+tnXZACq6fBVmJ3INUR/nEp0pPK52VwvH3fQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(376002)(346002)(366004)(66946007)(4744005)(966005)(316002)(186003)(5660300002)(2616005)(71200400001)(478600001)(6512007)(6916009)(3480700007)(26005)(6486002)(2906002)(4326008)(66556008)(64756008)(66476007)(66446008)(8676002)(76116006)(6506007)(91956017)(86362001)(36756003)(33656002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: s+Xtg0gzhpcsx1zagJ8T/8NKKym5qRDDL3iOW2qiM4vlndzUrpIdIdiGmu2NZ4+GdszFtoQ+tfYN4yoVLMXEmCWtBCtjXCZntmtkFO6GRuGWWoIo2o111ysG24P13/mUQgpxBnL4nrpnJWYnSSWIegtDeEv38NyT+s790T13Qya4y+xQjPPN+vrsP3L0trHL0R/zqN5Q5Tjo+u8QLCqU1c1m4gEYGcxscifzUbnfRUQspwnrGGDzvlg6c8yZ8WcUN/RTuZLmwwMeoJ4fXvReW9rYUudo6mbCeTA5M35ORM5iZZRyVj2ATVmSxtx1gsWDMPWNNHIDVOaha7SqXPDeiJh0AMA8lQbVSE7ciPXOWdLPORwFn4laotmEkrWg9XuIftvHnIU0V8XrmwYzCXf4cr23JiE67L8YINc7AcXuLFnHdvDdf69gToXdn2OBmQ1UHNlEY9C/ZjOmNvuXaAWq1AgCqejj+IYv1UC5ztB0/KI= Content-Type: text/plain; charset="utf-8" Content-ID: <4374950A20E55642806DD9E54CD60ACB@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3014 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT015.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(346002)(396003)(46966005)(2616005)(8676002)(82740400003)(33656002)(6506007)(4326008)(336012)(81166007)(356005)(47076004)(82310400002)(6916009)(2906002)(6512007)(6486002)(36756003)(26005)(3480700007)(36906005)(8936002)(5660300002)(478600001)(86362001)(186003)(4744005)(70586007)(70206006)(316002)(966005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 658444ae-362b-462b-1576-08d7fb1716d8 X-Forefront-PRVS: 04073E895A X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LSpW1ARpBXr8xtH6OK553pTCI7Z/Nop9YETTh/CFK7zTWNcdbWQT97V2/a5dKwyegdKseqISiyMrRElQzjGcQeflq/LB4WAwTrxHxFW4UTljRF2RN/fm+y/T/50Q0CKWyMDQsJN3ptDX4hPfLqgzdiwEpfLAzJBC2AIHjWPukB9IYl3pu4ZXngYhMvM+9+V95Sq1y4MSqcV2uXvzgKhcpBEmxuBQXcz/TCCc0RT6+D8PXKQHyefd2RqtcPSqhbdu9dw2KVJ3pU12TZQc4t2/q2oAi3MwpBGs2FFn8xAwZlNL5CB7cJFpzhOg0vZkUor2fteZopqWEESjlS4x4sUd7ys4aTw6BmxsnZpm3WV34v3GxbC2JUTPEN1vLfSHfM7+uOFhJIVlheJB8i3RsmXmD9XJCZhTS/B/FmlZ79LxCEp/RX5NuFLtfTV+SvEquXPoLbNpZCg1yVeY6/KP9COGdLmUYRTE1X81PXfyMNvm9C41vZJVmFnY9hBwyZFKTJTPJRXg8FYlzmNKpa1hB3GB9rnp5iquKEvHsl3qmuUtssj0yuPqyAg5C37Z9IgKklMg251tWybeRyKS/XSZpF8EkA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2020 10:34:54.9568 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 291633ed-d1c9-4f3e-bfc9-08d7fb171ae3 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3059 Archived-At: Subject: [core] Anti-forgery limits in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 10:35:00 -0000 SGksDQoNCkp1c3Qgd2FudGVkIHRvIGZsYWcgdGhpcyBQUiBbMV0gdGhhdCBsb29rcyBsaWtlIGl0 IG1pZ2h0IGFwcGx5IHRvIE9TQ09SRSB0b28/DQoNClRoZXJlIGFyZSB0d28gYXNwZWN0czoNCjEu IFRoZSBnZW5lcmljIGFudGktZm9yZ2VyeSBsaW1pdHMgZm9yIEFFQUQgY2lwaGVycyBhbmQgd2hh dCB0byBkbyB3aGVuIHRoZXNlIGFyZSByZWFjaGVkOw0KMi4gVGhlIGRpc2N1c3Npb24gYXJvdW5k IHRoZSBzcGVjaWZpY3Mgb2YgQ0NNXzggLS0gdGhpcyBpcyBhbHNvIHRvdWNoZXMgb24gQ29BUCBz ZWMgbW9kZS4NCg0KQ2hlZXJzLCB0aGFua3MhDQoNClsxXSBodHRwczovL2dpdGh1Yi5jb20vdGxz d2cvZHRsczEzLXNwZWMvcG5kIHdhdWxsLzE0Nw0K77u/DQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJ Q0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Tue May 19 08:31:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52363A0845 for ; Tue, 19 May 2020 08:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omo_qRYHpEvW for ; Tue, 19 May 2020 08:31:30 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2055.outbound.protection.outlook.com [40.107.21.55]) (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 CA7D43A07EC for ; Tue, 19 May 2020 08:31:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVvZUYCC2euOfThTH5Gae8OaFrunyEm5sLwS27TMA0zoPijJMemYFmJjsNkbXKJ4Cvtf70VaBL8Ww0ImtxnIxk3iUr3x0vmA7Tw+b32sC9xRkgwTfycdeQN+lFBbNV93BBz+lX6JswvNJV0wy7B88qNF/zNelcR1+6Zkv+VZSPoUWxwSRFxz8IyolRQv8EhG0AluR0s2mfjIyiMcNWfrNd9QmMnk/Q0C10F6Jebvx+SJ9gzp2rH3WeQdM+0N1z4pvElmiwY4nSRFZyLO9Mm+fSxfygq24qt/qVobIkXi4eCViNAcVnPVapV2COkPoGmKWb1CSX7VvOjkLPaZMaC5mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wuWTWYuRC5gbMr9b36FbaY/JcVJYapQ3ttLPKM7UY1I=; b=UviO44NqK5kfRLyzGOMsun/9OC8OCrAc+efVabsMMZSWkW0WCG70DvBwbGl46eTWv7vAjZFR5jOIMDB+/NdPujyDVo1sPGrqKR6Rni6dzTeexdXHkXemXtaOGWtNlxoLLL1zwet+5qQnPUik3pWkIwPEFydEgND3eHZdBo6nrGn60nOMdrs5YxldfNOPVKeA63c3HwbdiUgR4JgdQPDpgTRZ86ieYU3Ne014/U9w2ZntUnrQCXvfwJQ/+y7X3OlO9lC2b8Jq7CEBSZlv5R064UlnUmjy540ipstXLBT0k6x6cEDCzLSrAJ8FNumnIV/tmbUV8Bk4A89x9ptSXuQ1Wg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wuWTWYuRC5gbMr9b36FbaY/JcVJYapQ3ttLPKM7UY1I=; b=CXVowgWUcj/eBKTgVQrL57QFD5Fd8w5DemP3rKMd4b3luicVRMsBKzklxgPtcRBhM3vYhR+X5MZOQHRikwb1OaAUa4KK8OmMLzSnS3HFOf6kCR3wxmTMl1Fc4UZbWOT28mColflfULofdcHB8Jpsbo2DP+s1M1ZDaMtbHujCXso= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3723.eurprd07.prod.outlook.com (2603:10a6:7:82::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.19; Tue, 19 May 2020 15:31:27 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.3021.019; Tue, 19 May 2020 15:31:27 +0000 From: Francesca Palombini To: "core@ietf.org" Thread-Topic: Coap Thread-Index: AQHWLfKPFqVYc7VVWEqXuNZ8jcv0Zw== Date: Tue, 19 May 2020 15:31:27 +0000 Message-ID: <2ECDE140-E0F2-4B0C-B47C-E574FFF97154@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8bd40d60-12de-4306-d14d-08d7fc09b24b x-ms-traffictypediagnostic: HE1PR0702MB3723: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 040866B734 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MiTzxlZdid2RQ9FuMKG21u3vf3mTBNzx5qWH8qoiReKCoxut8A50ViE4dOk3HSKYm1Vjtr3+n8H+hzX5ji1NNuHATepGjQdsmQCbItSkRyCyhJ/1kCKhbyHZ/Bj6d0IwWeRTV7RNNCHWvpm2cdrvf0VxmtB7ZwE5Wzk4Rh/k8djFs7FSoqGL+1SBZoui04nW6vhew1I+M9dQeAwQehWC29mCRlZrnLOTMM+TETeKcIFElzIf+kIWo5XdBbA1iC0uS9dF6qb6EwOPDTPMvr4vNEOOIhlIdwjipaQ5PyDk/ykxQRlymtiUKx4WrHNUBoLFKczCaKuDkPrpc5ngycVR7dgtAKsiZIUucc1KvzEUUa+w/c+o15Kg86MXUcHBzfjgxEPdG1ub7o+emAQnhHQNEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(8676002)(4326008)(8936002)(36756003)(3480700007)(6512007)(66476007)(76116006)(66946007)(66446008)(66556008)(64756008)(44832011)(2616005)(186003)(26005)(6506007)(86362001)(966005)(6486002)(5660300002)(71200400001)(7116003)(498600001)(33656002)(6916009)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +lg77U5RUSd4u10dFvKMC2Oitlilp+C72Mm8DzuOXXvvmRQogd7s9rKLCuMHlmkcV4NbAqcqGBu3s6R9vikPkzolR/XqrX/MvTzR+r61wzit5aonYPvKzHzcLL/StuTl4XWbk90EQmlU8qy6AcXP4/xGzFKSSOJM9bX2ZYpeUR3Hw8F0++KJLgysPqw+wV7jKTadSEJapTl39CfRagN6L2l1ckWQadZD6npsF4XnVdMEM/+AMEXDUBtu67HiHKesrHEt2bgMucGJKpeBuE+LyAyoWjxfuk0zI8/D+empvnlIAiVCDAuE2ukoIZ8LF9njMO6FQVCpVuwMUiFpMCApQCleRtd21rdw7AfZawR5UuaPUH0+2vPSKWQFFx5yllHyFEX0xRTNz2rJzvjMLNrj33mOgdrjQvuEObZByaPcbpdvNpnZ3fehxcYIqFwzw/bY88Vw+19tKLGCwFY4vH1VdtCYoL+pliTKzsazjXzwAQ374BgLZXzepjEAH1wZU5e5 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bd40d60-12de-4306-d14d-08d7fc09b24b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2020 15:31:27.1363 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U+fVO+qDc++S55RknIIx2Uuk9UccnIA55QC+WJbtxuel5lp8NGeYPqJmzF033/C4vOW6kKGbkgJu0nL9FNnX195BYJN38OGwLNH0yy3VtmecUChStsXbgyuVNQe0ruJe X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3723 Archived-At: Subject: [core] Coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 15:31:32 -0000 SGksDQoNCkkgYW0gd29ya2luZyBvbiBhIHByb3Bvc2FsIHRvIHVwZGF0ZSB0aGUgaHR0cDovL2Nv YXAudGVjaG5vbG9neS8gd2Vic2l0ZSB0byBhZGQgd29yayBvbiBDb0FQIHNlY3VyaXR5LiBJIGhh dmUgYWRkZWQgYSBTZWN1cml0eSB0YWIsIGFuZCBzb21lIHN1Yi10YWJzIHN1Y2ggYXMgRFRMUywg T1NDT1JFLiBZb3UgY2FuIHNlZSB0aGUgcmVzdWx0IG9mIG15IFBSIGhlcmU6IGh0dHBzOi8vZ2l0 aHViLmNvbS9jb2FwLXRlY2hub2xvZ3kvY29hcC10ZWNobm9sb2d5LmdpdGh1Yi5pby9wdWxsLzMz IA0KDQpJIGluY2x1ZGVkIHNvbWUgdGV4dCByaWdodCBub3csIGJ1dCBJJ2QgbG92ZSB0byBpbmNs dWRlIG1vcmUgaW1wbGVtZW50YXRpb25zLCBmb3IgYm90aCBEVExTIGFuZCBPU0NPUkUhDQpBbHNv IGZlZWRiYWNrIG9uIHRoZSBwcm9wb3NlZCB0ZXh0IGlzIHdlbGNvbWU6IGZvciBleGFtcGxlLCBJ IHB1dCBpbiBEVExTIDEuMiBhbmQgRFRMUyAxLjMsIGFzIHdlbGwgYXMgdGhlIEFDRSBwcm9maWxl cyBvZiBEVExTIGFuZCBPU0NPUkUsIGFuZCBHcm91cCBPU0NPUkUgZXZlbiB0aG91Z2ggdGhlc2Ug YXJlIGRyYWZ0cy4gDQoNClRoZSBlYXNpZXN0IHdheSB0byBjb250cmlidXRlIHRvIHRoaXMgcHJv cG9zYWwgdXBkYXRlIGlzIGJ5IHB1bGwgcmVxdWVzdCBvbiBteSByZXBvOiBodHRwczovL2dpdGh1 Yi5jb20vZnBhbG9tYmluaS9jb2FwLXRlY2hub2xvZ3kuZ2l0aHViLmlvIA0KDQpJZiB5b3UgaGF2 ZSBtb3JlIGNvbW1lbnRzLCB1bnJlbGF0ZWQgdG8gbXkgcHJvcG9zYWwgdXBkYXRlLCB0aGUgd2F5 IHRvIGdvIGFib3V0IGl0IGlzIHRvIGNvbnRhY3QgQ2Fyc3RlbiBvciBvcGVuIGlzc3VlcyBvbiB0 aGUgcGFyZW50IHJlcG9zaXRvcnk6IGh0dHBzOi8vZ2l0aHViLmNvbS9jb2FwLXRlY2hub2xvZ3kv Y29hcC10ZWNobm9sb2d5LmdpdGh1Yi5pbyANCg0KVGhpcyBpcyBub3QgQ29SRSB3b3JrLCBidXQg aXMgQ29SRS10b3BpY3MgcmVsYXRlZCwgc28gZmVlZGJhY2sgZnJvbSBhbnlvbmUgaGVyZSBpcyB3 ZWxjb21lLiANCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCg== From nobody Tue May 19 09:02:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EB23A09EA for ; Tue, 19 May 2020 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_BL=1.979, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zYqnzCEdpss for ; Tue, 19 May 2020 09:02:32 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 013553A09E0 for ; Tue, 19 May 2020 09:02:31 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id s10so15095088iog.7 for ; Tue, 19 May 2020 09:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XsMip5pErZX3Zx38LfcUv107+H/m3whZawdfkNU9EQo=; b=gmS8y6hWfssg9ZVl815KdfFOFVeJbWbp7CLRV43miJf6ZUPRKp+HkX/YGD7hI6sH6i iQmS5JUYoJtr5FRgf7DQjSIxzzqbUNi9kjyl0X/kR0dcQFcLSvQEnX59yjAH1pGck107 IH5UnGeJyY1NC8A0iXN/oRGrEKZXNEprhIgbFc82Weg8T0eBBnvU6Fw3MQdp4VmcQU0h X/JtPHHdVyC6d3Y34cPJxuzNU92PMUzp5i+tp3XakJbKpF69nGVwcbzhHVm4ESKJ1gvF oHUOl69DQGQIAE4kP12fgaxPxt8/yKkmbSAYlxbnqFh61mpigLCi5YPDL1PKFp/YNnuN xYKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XsMip5pErZX3Zx38LfcUv107+H/m3whZawdfkNU9EQo=; b=itWVurEPS1Xn7UR9XB/8Vpj0AXGU3YVhzzaCukyactvOtn6H5aZA6yqkkFlBRL3Tjo clIwm48QkD4DDqQM8XgzPMnGOdpwwR0vPhbd9kbMaaOqwb9XaBKfvilml81lL/LgQ3f6 kJAm+vl/r2Y/8mAsQQ7yNfm/xvcV9duv9bMINiTITsLSRXnbEYA8xyF8yTPdkCM0B/76 c1qvFKjkFYWp7YRq/qt+htasDjz3s/97yWx9AfegGTpScQ8pmqhlxJPK3SP28bkSlIXY NgR6Hd8gxKYn3JMD/vnwFP6+bAFYfCNb0RGjP5arB9jGAgPZP1ZomyEYaF3aMsR5P0/j /3hQ== X-Gm-Message-State: AOAM5329TlN5f0qPV0uvyV1KtdVQLo33jRGE+3b9qx6Psnna5kB09BOW g02z08R3uNnEGwNXCpoFgimRlTJtU0y1HxnykzTzfhhpQDE= X-Google-Smtp-Source: ABdhPJwLoXUUMwOCe0WVHAj/GL0/75h0g8Hw2JeV2DIiBrYuadhoyjHpu8Fxc6gx4iTpEA5Ak6Gguj8cy9z/yM3rldU= X-Received: by 2002:a02:3e06:: with SMTP id s6mr348906jas.57.1589904151190; Tue, 19 May 2020 09:02:31 -0700 (PDT) MIME-Version: 1.0 References: <2ECDE140-E0F2-4B0C-B47C-E574FFF97154@ericsson.com> In-Reply-To: <2ECDE140-E0F2-4B0C-B47C-E574FFF97154@ericsson.com> From: Thomas Fossati Date: Tue, 19 May 2020 17:02:20 +0100 Message-ID: To: Francesca Palombini Cc: "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] Coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 16:02:33 -0000 Hi Francesca, On Tue, May 19, 2020 at 4:31 PM Francesca Palombini wrote: > Hi, > > I am working on a proposal to update the http://coap.technology/ > website to add work on CoAP security. I have added a Security tab, and > some sub-tabs such as DTLS, OSCORE. You can see the result of my PR > here: > https://github.com/coap-technology/coap-technology.github.io/pull/33 > > I included some text right now, but I'd love to include more > implementations, for both DTLS and OSCORE! Also feedback on the > proposed text is welcome: for example, I put in DTLS 1.2 and DTLS 1.3, > as well as the ACE profiles of DTLS and OSCORE, and Group OSCORE even > though these are drafts. > > The easiest way to contribute to this proposal update is by pull > request on my repo: > https://github.com/fpalombini/coap-technology.github.io > > If you have more comments, unrelated to my proposal update, the way to > go about it is to contact Carsten or open issues on the parent > repository: > https://github.com/coap-technology/coap-technology.github.io > > This is not CoRE work, but is CoRE-topics related, so feedback from > anyone here is welcome. This is great! I'll provide text on the TLS and DTLS profiles for IoT - which makes me think that one further piece of (possibly) useful information we could collect regarding implementations is their level of compliance with said profiles. Cheers, thanks! From nobody Sun May 24 22:42:05 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68763A0BC5 for ; Sun, 24 May 2020 22:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 MWe7cHvBYo1C for ; Sun, 24 May 2020 22:42:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BA53A0BC4 for ; Sun, 24 May 2020 22:41:58 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 49VmF108sTzD8NH; Mon, 25 May 2020 07:41:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1590385317; bh=3g8YxpDlJMzh4YbP4LNPsqHNQ/Og1nb/3afWyK3SXaM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=nzT2S/qnEVQBUqzjxhHw10w8KVe6WwwKDZNh6jjDD2jtdi1Xapn0ec2LOUJKNUlri E9lishgjhiLosBU46piTCJH/OBID7gw6EsJiHugQq75WXJjFgjANcBEj8t5LpqPVmD I5txWOT7icoFi7QEaq8CC3BDizZKIujXh5IAey7/1INPpymEXWz1WcM5qNaCKU57xq SuCc873KH2683rNruXgfFKkMx4GAUNJUcJdhXNPdAqF6UO+S9i2WqpQU0jj+Af0CX1 tSYaoQpURRGdCYdWHsebIGWkPya2DMtLvDocQ4LbFAxClR4McE+ctsPghMih2eYtwT qz8rNwjYeQSQg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 49VmF06T1RzDq7T; Mon, 25 May 2020 07:41:56 +0200 (CEST) From: To: "core@ietf.org" CC: Jon Shallow Thread-Topic: New Version Notification for draft-bosh-core-new-block-01.txt Thread-Index: AQHWMlQT57Szs+GLEEGgdIxdpB/eGKi4Q66w Date: Mon, 25 May 2020 05:41:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314C2769@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159038397258.32634.14371058589762732026@ietfa.amsl.com> In-Reply-To: <159038397258.32634.14371058589762732026@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [core] TR: New Version Notification for draft-bosh-core-new-block-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 05:42:03 -0000 SGkgYWxsLCANCg0KV2UgdXBkYXRlZCB0aGUgZHJhZnQgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhl IGNvbW1lbnRzIGRpc2N1c3NlZCBkdXJpbmcgdGhlIGludGVyaW0gbWVldGluZy4gVGhlIG1haW4g Y2hhbmdlcyBhcmUgYXMgZm9sbG93czogDQoNCiogQWRkIGFuIGFwcGxpY2FiaWxpdHkgc2NvcGUg KyBhIG5vdGUgYWJvdXQgY29uZ2VzdGlvbiBjb250cm9sDQoqIExpbWl0IHRoZSBzZXQgb2YgcGF5 bG9hZHMgdGhhdCBjYW4gYmUgc2VudCBieSBhbiBlbmRwb2ludCAoTUFYX1BBWUxPQURTKQ0KKiBE ZWZpbmUgYSBuZXcgY2xpZW50IGVycm9yIHR5cGUgdG8gaW5kaWNhdGUgbWlzc2luZyBibG9ja3Mg b2YgYSByZXF1ZXN0IA0KKiBDbGFyaWZ5IHRoZSB1c2Ugb2YgVG9rZW5zL0VUYWcNCiogQWRkIGEg c3RyZWFtaW5nIGJlaGF2aW9yLiBUaGlzIGlzIG5vdCByZXF1aXJlZCBmb3Igb3VyIGluaXRpYWwg dXNlIGNhc2UsIGJ1dCB3ZSBhZGRlZCBpdCBmb3IgdGhlIGdlbmVyaWMgdXNhZ2UuIA0KDQpXZSBh bHNvIG1hZGUgbWFueSBvdGhlciBlZGl0cyB0byBlbmhhbmNlIHRoZSByZWFkYWJpbGl0eS4gDQoN ClBsZWFzZSByZXZpZXcgdGhpcyB2ZXJzaW9uIGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLiANCg0K VGhhbmsgeW91LiANCg0KQ2hlZXJzLA0KSm9uICYgTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANCkVudm95w6nCoDogbHVuZGkgMjUgbWFpIDIwMjAgMDc6MjANCsOA wqA6IEpvbiBTaGFsbG93OyBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpPYmpldMKgOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDEudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDEu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1vaGFtZWQgQm91Y2FkYWly IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1ib3No LWNvcmUtbmV3LWJsb2NrDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJQ29uc3RyYWluZWQgQXBwbGlj YXRpb24gUHJvdG9jb2wgKENvQVApIEJsb2NrLVdpc2UgVHJhbnNmZXIgT3B0aW9ucyBmb3IgRmFz dGVyIFRyYW5zbWlzc2lvbg0KRG9jdW1lbnQgZGF0ZToJMjAyMC0wNS0yNA0KR3JvdXA6CQlJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjQNClVSTDogICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jay0wMS50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1ib3NoLWNvcmUtbmV3LWJsb2NrLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1ib3NoLWNvcmUtbmV3LWJsb2NrLTAxDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3NoLWNvcmUtbmV3 LWJsb2NrDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3Vt ZW50IHNwZWNpZmllcyBuZXcgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVAp DQogICBCbG9jay1XaXNlIHRyYW5zZmVyIG9wdGlvbnM6IEJsb2NrMyBhbmQgQmxvY2s0IE9wdGlv bnMuDQoNCiAgIFRoZXNlIG9wdGlvbnMgYXJlIHNpbWlsYXIgdG8gdGhlIENvQVAgQmxvY2sxIGFu ZCBCbG9jazIgT3B0aW9ucywgYnV0DQogICBlbmFibGUgZmFzdGVyIHRyYW5zbWlzc2lvbiByYXRl cyBmb3IgbGFyZ2UgYW1vdW50cyBvZiBkYXRhIHdpdGggbGVzcw0KICAgcGFja2V0IGludGVyY2hh bmdlcyBhcyB3ZWxsIGFzIHN1cHBvcnRpbmcgZmFzdGVyIHJlY292ZXJ5IHNob3VsZCBhbnkNCiAg IG9mIHRoZSBibG9ja3MgZ2V0IGxvc3QgaW4gdHJhbnNtaXNzaW9uLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= From nobody Mon May 25 02:02:41 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F25303A0838; Mon, 25 May 2020 02:02:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core-chairs@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159039735129.6431.9602335020216311114@ietfa.amsl.com> Date: Mon, 25 May 2020 02:02:31 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Interim Meeting Cancelled (was 2020-05-27) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 09:02:39 -0000 The Constrained RESTful Environments (core) virtual interim meeting for 2020-05-27 from 16:00 to 17:30 Europe/Stockholm has been cancelled. From nobody Mon May 25 09:34:06 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257333A0AD6 for ; Mon, 25 May 2020 09:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yVD5btBdBfF for ; Mon, 25 May 2020 09:34:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968FF3A0ADA for ; Mon, 25 May 2020 09:33:59 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 May 2020 09:33:34 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , 'Klaus Hartke' CC: References: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> <03cc01d623b4$8283a7c0$878af740$@augustcellars.com> <20200511112123.GA2573363@hephaistos.amsuess.com> In-Reply-To: <20200511112123.GA2573363@hephaistos.amsuess.com> Date: Mon, 25 May 2020 09:33:32 -0700 Message-ID: <02fb01d632b2$3cac7170$b6055450$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQF3IyvGSPj7FWkIh2hLJEkWXqN4kAM3xeaGAg7FgjkBLObeFKlCsllA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] HREF compression encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 16:34:04 -0000 For some reason I was thinking about the issue of what should be the = default marker value. While doing so I realized that I had been stuck in a = train of thought guided by the text version of decomposing URIs and it does not really apply for this encoding. Consider the URI "coap://localhost/a/b/c", in text one could decompose = this as "coap://localhost" and "/a/b/c" representing this as [ "coap", "localhost"] [ABSOLUTE, "a", "b", "c"] However, this could just as easily be represented as ["coap", "localhost"] [APPEND, "a", "b", "c"] I therefore propose the following as a list of usual things: 1. Absolute URIs with and without having a predefined scheme: The = former needs no leading marker and the latter would need a marker that it is a schema. =20 2. Base URI of authority and relative URI of absolute path: As noted = above this can use the append marker or absolute path marker. 3. Base URI of authority + path and relative URI of absolute path: = Needs an absolute path maker. 4. Base URI of authority + path with implicit end path segment and relative URI: ("http://localhost/a/" and "b/c") Can use the append = marker 5. Base URI ending in a "file name" path segment and relative URI: ("http://localhost/a/home.html" and "./b/c") This needs to use the Up = One marker. 6. Base URI ending in a path segment where there is no difference = between last and intermediate names and a relative URI: ("coap://localhost/a" = and "./a/b/c") Can use the append marker while omitting the first path = segment of the relative path ([APPEND, "b", "c"]) I think that if we combine group 2 and group 6, this will be far more prevalent than group 5 would be for the IoT world and potentially in general. I have used both 3 and 5 for html but don't ever use 5 for = coap. The use of 2 and 6 are going to be the most common for both = .well-known/core and a resource directory (which is allowed to control both the base URI = and the relative URI). Jim -----Original Message----- From: Christian Ams=FCss =20 Sent: Monday, May 11, 2020 4:21 AM To: Jim Schaad Cc: 'Carsten Bormann' ; core@ietf.org Subject: Re: [core] HREF compression encoding Hello, > This is an interesting proposal. I like that too. > [JLS] [...] An RD is going to be heavily into absolute paths. Even that depends on how the RD is used. When querying for resources of = a specific type across a network, it will largely consist of one full CRI ([COAP, ...]) for the anchor and one relative ([PATH-..., ...]) for the target. Queries that yield multiple records from the same server can = make use of CoRAL's base directive. Kind regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom From nobody Tue May 26 06:42:43 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2F3A0F5B for ; Tue, 26 May 2020 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdjedJdNQ_as for ; Tue, 26 May 2020 06:42:39 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2057.outbound.protection.outlook.com [40.107.20.57]) (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 9BDE63A1075 for ; Tue, 26 May 2020 06:42:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UaJ4UgbdG9SG6HZ3egMkyeHA61g/RSPYkBzR6LQDfdhNrtSLH4d2Lsdp1GlO6/qpddw72t6wGoNVU2S9FoBuggy19WbJjuggLq52uZNN5iL4GJMnXvBYKxCVL9pE1tAb07XRXQ2hzKPb0eYBZij73hw6/lQiwcLvVcbsO/rR+znhmLOUFRLrASw3zXEPT5mtE7wC55PnV3KvrpU1tb7YdjlMlElbEcPx0g9Fldk9aTGzw/3rUXH3NRIEVCsTAmBAxHFpEWquNJkLMUfNEtrdEXBCaq4oIf2Uo8CJQCD+xzzwsACJPCColIH+oij+tCgUFiSVaLjCz3c119ariPWfAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZwsSQWhVBNHbr1B0E3vDmq1HnAl2HIxbhk+WPDmS5OA=; b=aThaCq3/xJ5JxQGpK0/uZbXATsSU39WCwi2rOC+RzeFwIXUfgD/eRNAJcJ2M75Cfm1KFkeEdVCIkUPLu5QPDrHXa0l+DfI2ABFduvs8VDQWMSK53ZaSlmwftj9dm9Yb66Pu3QupB1FqCv49bXx54cRefaqRFkbqFBmRxB/5kumaB4C4s+HNI7b1GXM0QYwHQ2LSDBnRL3+twl80LhaQENkKkdZhKHd48CMj6QQppkgkq6nsZ0SK3DtspM5sJsjcUbbeGXYSH+lgCJcfLqZ8jZlWdHNOFqZwnZfy5XJQC+Mk4eFutd+gw/TERkrtccL8wKknPw5sd6jY+Jn0po113iA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZwsSQWhVBNHbr1B0E3vDmq1HnAl2HIxbhk+WPDmS5OA=; b=NiPzu7SnoAfmmQOaV8y/TphcrP+pv3qJ5pcwt2ZqnTBtEhECq/DLCtlnbThsDacryGJn5ol6A7L7yaGtKdAQIQ8MkHBDwugdAZwTXhC/ETcRyXxdCI8223CUcuPhxn0CRVRfgpzPNdd3c4UIyNurVME+yw55tk+M4cVPhQ2HdHU= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3803.eurprd07.prod.outlook.com (2603:10a6:7:84::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Tue, 26 May 2020 13:42:20 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.3045.015; Tue, 26 May 2020 13:42:20 +0000 From: Francesca Palombini To: Thomas Fossati CC: "core@ietf.org" Thread-Topic: [core] Coap Thread-Index: AQHWLfKPFqVYc7VVWEqXuNZ8jcv0Z6ivkdsAgAr6uoA= Date: Tue, 26 May 2020 13:42:20 +0000 Message-ID: <875D046D-AC2B-4D9F-BA77-650C5AA82F14@ericsson.com> References: <2ECDE140-E0F2-4B0C-B47C-E574FFF97154@ericsson.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5046d81-38c5-459b-5d87-08d8017a9ce6 x-ms-traffictypediagnostic: HE1PR0702MB3803: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 041517DFAB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IK7adYxwksddSZbRRNfHCdshVigwx7lWNUsVqvmuxkvms739NW/k2u10U1zMNn76WyA1rkTk+criHfQ6OUVbB7bI8Ln4wZ7tQARB+M/0Zv6ROWWj8c22a9pK+gB0YHWkTKZ+GuUPRhYVZRSLZmZNChDUpa10JqAq9jkZ9irzI8MPyCMRpl9QCY9VvIUSa78M9uqvER8aWVjqBCbiQhnhndPEvuwMbjOeN7ALGqZzuo07XBhG1lrBHIt//EkDQvS3jmsW3RbvwIURyMxPwDEdafQr1YWEkkhlGvlBHnjg+zENp17/iCbPu9Td9fsz1Cw7 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(346002)(396003)(366004)(66946007)(26005)(44832011)(6512007)(4744005)(76116006)(6916009)(64756008)(66446008)(8676002)(66556008)(8936002)(5660300002)(2616005)(33656002)(66476007)(478600001)(71200400001)(2906002)(86362001)(6486002)(4326008)(6506007)(36756003)(53546011)(186003)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xMoecCBN8FWQENmMh1z86KSa0XLIkWgMWTtsPXrj7S4rgnMc98lUWs/LCKmg2Fq/w5x6Z3/oQl5qU74ytP7beL004d4JQNrq9jXnZTSiAqGR52aq4+bxxmWrM91c7DJNp5CxL4KXeZSVR0wNaX5eq2xlbe6mOxFlJ04J/Zs/tbsIj6RP5Cy+pcMk3w7QQmKcNbwicICLh7eEXaCqXBC3pwTSioHTkFF7yVKyROeeFs4Vx8+LbEBCfRYsHY7W9jBFcWnPxNtRTGX5y6Ja11bJn3G7DqzXMtqGl6PhP62/iAYKAAfQUuNPfUQ5aDbhm/79i2xz+strVFMHb+k0/0a/yJfgGpguu4u0/WXSgfQ5tPz2ry48u0gLFO2gZ+mcK1ra23j0EXTxwQf6HjbvKrV/UpJvqjQdmJS5W83UBOtP7VkifTQmk+ovfMrixViXkQlljlM7TPK3IXFlIaSVihjr1ph6yotvKr0oOBeH4q619qFOkl+mWa7Bry3y3meOrfAs x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5046d81-38c5-459b-5d87-08d8017a9ce6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 13:42:20.1976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qkkmHkO8QKr6xxdl5iorGX8wxPYcN7zUXSBE+k3wsEeaIbrRJuFJZYUMoslxO+YhVPYgqQ15urpuHqMGZrTq4wcZbpIFOIOfKhQCeN5u44kUBm/qg7/vEGTM0zDuMXXu X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3803 Archived-At: Subject: Re: [core] Coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 13:42:41 -0000 SGkgVGhvbWFzIQ0KDQpUaGFuayB5b3UsIHRoYXQgd291bGQgYmUgdmVyeSBoZWxwZnVsISEgQW5k IHllcywgaWRlYWxseSB3ZSB3b3VsZCBhZGQgc29tZXRoaW5nIGFib3V0IGltcGxlbWVudGF0aW9u IGZlYXR1cmVzIGluIHRoZXJlIGFzIHdlbGwuLi4gRmVlbCBmcmVlIHRvIFBSIHRvIG15IGJyYW5j aCBkaXJlY3RseSEgKG9yIHNlbmQgdGV4dCBhbmQgSSB3aWxsIGluY2x1ZGUgaXQpDQoNCk9oIGFu ZCBvYnZpb3VzbHkgdGhlIHN1YmplY3Qgd2FzIGN1dCBzaG9ydCwgSSB3YXMgdHJ5aW5nIHRvIHdy aXRlIGNvYXAudGVjaG5vbG9neSA6KQ0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMTkv MDUvMjAyMCwgMTg6MDIsICJUaG9tYXMgRm9zc2F0aSIgPHRoby5pZXRmQGdtYWlsLmNvbT4gd3Jv dGU6DQoNCiAgICBIaSBGcmFuY2VzY2EsDQoNCiAgICBPbiBUdWUsIE1heSAxOSwgMjAyMCBhdCA0 OjMxIFBNIEZyYW5jZXNjYSBQYWxvbWJpbmkNCiAgICA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmlj c3Nvbi5jb20+IHdyb3RlOg0KICAgID4gSGksDQogICAgW2NsaXBwZWQuLi5dDQogICAgPiBUaGlz IGlzIG5vdCBDb1JFIHdvcmssIGJ1dCBpcyBDb1JFLXRvcGljcyByZWxhdGVkLCBzbyBmZWVkYmFj ayBmcm9tDQogICAgPiBhbnlvbmUgaGVyZSBpcyB3ZWxjb21lLg0KDQogICAgVGhpcyBpcyBncmVh dCEgIEknbGwgcHJvdmlkZSB0ZXh0IG9uIHRoZSBUTFMgYW5kIERUTFMgcHJvZmlsZXMgZm9yIElv VCAtDQogICAgd2hpY2ggbWFrZXMgbWUgdGhpbmsgdGhhdCBvbmUgZnVydGhlciBwaWVjZSBvZiAo cG9zc2libHkpIHVzZWZ1bA0KICAgIGluZm9ybWF0aW9uIHdlIGNvdWxkIGNvbGxlY3QgcmVnYXJk aW5nIGltcGxlbWVudGF0aW9ucyBpcyB0aGVpciBsZXZlbCBvZg0KICAgIGNvbXBsaWFuY2Ugd2l0 aCBzYWlkIHByb2ZpbGVzLg0KDQogICAgQ2hlZXJzLCB0aGFua3MhDQoNCg== From nobody Wed May 27 02:28:09 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F2C3A0BFD for ; Wed, 27 May 2020 02:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-s-97HLwFF7 for ; Wed, 27 May 2020 02:28:06 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9555D3A0BF9 for ; Wed, 27 May 2020 02:28:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.73,440,1583190000"; d="scan'208,217";a="451575265" Received: from unknown (HELO [192.168.1.103]) ([79.143.111.131]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2020 11:27:22 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: multipart/alternative; boundary="Apple-Mail=_F1679CC5-CC5E-4F2A-97F3-B7A357F56ED0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <78686082-66C4-4150-BDBB-D2F97C2AEEC7@inria.fr> Date: Wed, 27 May 2020 11:27:19 +0200 To: core X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [core] OSCORE Wireshark dissector updated X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 09:28:08 -0000 --Apple-Mail=_F1679CC5-CC5E-4F2A-97F3-B7A357F56ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, This is just a quick note to let you know that the Wireshark dissector = of OSCORE has been updated for compliance with RFC8613 and merged with = upstream Wireshark [1] . The dissector will become available in nightly = development builds [2] starting from tomorrow and in upcoming scheduled = Wireshark releases. Mali=C5=A1a [1] https://code.wireshark.org/review/#/c/37314/ = [2] https://www.wireshark.org/download/automated/ = = --Apple-Mail=_F1679CC5-CC5E-4F2A-97F3-B7A357F56ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

This is just a = quick note to let you know that the Wireshark dissector of OSCORE has = been updated for compliance with RFC8613 and merged with upstream = Wireshark [1] . The dissector will become available in nightly = development builds [2] starting from tomorrow and in upcoming = scheduled Wireshark releases.

Mali=C5=A1a

[1] https://code.wireshark.org/review/#/c/37314/
[2] https://www.wireshark.org/download/automated/
<= /html>= --Apple-Mail=_F1679CC5-CC5E-4F2A-97F3-B7A357F56ED0-- From nobody Thu May 28 00:10:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C283A0834 for ; Thu, 28 May 2020 00:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DleZ_D9j-Ne1 for ; Thu, 28 May 2020 00:10:27 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2081.outbound.protection.outlook.com [40.107.21.81]) (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 4E76F3A07E6 for ; Thu, 28 May 2020 00:10:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=casHfBTj5liINfX7xlG5GhdfbJUGSjQ+I5J2nY4ijRUE8M5t3y2nTW2fh7VADaUbikRjq1nuFHBIFG3xMdNm7+jyYwoH225fBxcDZUgoUBJiAuw3KcMdmgF1OGOMny/ClihvPP/RdNFog22Usp2B1dYNVEUQFBo9qOPJUI5A7QKLJsJa51OaVKqdKSwMyAZiuXYZRni18SRSM0UoryEWMu4WYXrj4VGJ2bJBTMmIC7hc8gLl8Hs7MN8LkSpV3filsKlngofcNTuNeIX7nTIckpg6q0rgTcT0dESjlRhGSN+4mEoLy80Vo2Ke+CLArwiZD5tvXPqDIDhbP1BDg7/pNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MSHnY39wecYO5zbxVwZXiNpUhyuchTG4YP6+P1v0bpw=; b=S6Uz4dJu+JJ+iRILajI2G1HTG8lPKAY8h/sjJB8pm8icaW0C9o/wIbt+Zf3X1iofrNvtnnBmYa3rF8KccjF+5iV+VrpPkd8UL8Y3n1y2N2V2dECmAxQiSb2gBaF6vvsAXMgFZmZuxQtjz1b/McMJWxgPZC4sgIHZNut23GiOY1cNccrMW+aK9LLV1wB4P+BxROPfgcoZa2gob5home5wl3eZhChLIheYgUg6rZ21mvQnzKFqj7HPIdLXJnsSh4dRMxjSs4l9qtNO93pZ9TqUaqCQIlCLEKkDkHndr2lnCM1wNIAboMgoRX6eD+tiwTlRUuVCxgxChlNKLQHlFzV/ng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MSHnY39wecYO5zbxVwZXiNpUhyuchTG4YP6+P1v0bpw=; b=DosOBOm+nih7gadGBdj4hhGb53XEj/yph+A/iEeN/YPakxhiMVNWXl4ONfJ6fQ6bbUJXjv0+z28JWyH4yV54wFIAGTaHe8J0Rzep1u53qqSQzpIYG+q4bHvkOqpqlRFvejAUUbP0W7JT6stm5AyfE9Vs1lA79YC/42uvhvLDDNA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0318.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Thu, 28 May 2020 07:10:23 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.3021.029; Thu, 28 May 2020 07:10:23 +0000 References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <159062833754.6110.5826748635235943562@ietfa.amsl.com> Message-ID: <66fa7edd-f929-0ddc-3d6c-cd715f4eae8c@ri.se> Date: Thu, 28 May 2020 09:10:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <159062833754.6110.5826748635235943562@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3hLChAAckIULsuOpq7H1GmXrAmbFVOHwU" X-ClientProxiedBy: AM6P191CA0022.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::35) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.17] (37.120.194.236) by AM6P191CA0022.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17 via Frontend Transport; Thu, 28 May 2020 07:10:23 +0000 X-Forwarded-Message-Id: <159062833754.6110.5826748635235943562@ietfa.amsl.com> X-Originating-IP: [37.120.194.236] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f8d7c4cd-e9c5-4d56-4419-08d802d63085 X-MS-TrafficTypeDiagnostic: VI1P189MB0318: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0417A3FFD2 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uVrUaEU7gAn5yLTLhU3nP8pBwOcJf3Zah6TctjmMv+FfJffjdncXzCg8dV717z3oxEPojlKBSXtXergVJy2RAICrJbi+zHcVsaZBvsMjmkOyq1/WG65NDqDaOfy4qH/+VtlefNtE/q+GzVaGcVQ5G0BqZWBIOIBjDh1Hhzs3y2eqIz2P15V7BXxbEDmJOkjLFnWVmvc1+Yig8FOFif7rgUyFcboWSD2ZYRClIccjI5LIWpx04KAo/hDNerT6U7eUg8kJixF6BQJdYZbvxK+Va+9a1iWfKDJqpw7PRPwcGo4c1o9nLx5X2BXzr3TLiHTuHtgHBJGyI0v97m0jqZO8RKCIoR7gjPbImOV6svTtneZnOBTip0vhqZ4U30sjL/+/VodEdETAclXdePCYD7Kt5KHOuvZ+OybzS1CgZpMSgrWPgoGSefSGBPuc4cV+IH4JS6rlmYRhM1TcL3ujDI54lw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(31696002)(235185007)(5660300002)(21480400003)(2906002)(66946007)(66476007)(66556008)(316002)(16576012)(2616005)(956004)(44832011)(8936002)(6916009)(478600001)(966005)(86362001)(36756003)(166002)(6666004)(31686004)(186003)(26005)(16526019)(52116002)(83380400001)(8676002)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: M/Nh6WmMxU5G6Q03Vt8QJ8yimAW/I6s+Usv/VGXUC5cEvo2arkr9BYTRWvCoNt/89ntLW2j1kKJ7Bb7UTyRPRNMDvieEOabosJVXiqup7YhjPk9+OiXFSpwtXo9MCdV7fS5UP3Ureg1TJ90iulmddBM+d4e6R2vQbAG4gLnlPfd7OvBLs9OIBuBMSsFb47JKKtwiT6jsV5uNcsQAGWJ8SGC3S5I2tVaU4qFVYI2AjlO+HVv2YQBn4Q+hmZhoO+vN1Qd3Vg1x/bnB5ssdTQJocYOQaAqJ+82w9toIpXgrZtrHtbgucv7B0IJvG7xmSxY+EKVWWdnKDaQrlH3LjCyKElO30nzbAuiAyJT8sEjUI1gV3LZplFXU8dlGFE0JBrAk016LHHCqbJTJygmG6jnAtKBNytOpKCjf/ucET7v2D5XFpi5rfucaGItmCeEAyJ5Agrfym0OROJjf8H0r1abKvKgCeFZ7W8AbJ2kHUfFAjmU= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f8d7c4cd-e9c5-4d56-4419-08d802d63085 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2020 07:10:23.5720 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tHhzr2o7L2PZcCoOjxbdNlClTiV9/aglhuJcoh2QwrVYvtC/WAfN1C8/eZzmw+z8rKvmgTSJRAA2oSjRWMYpVg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0318 Archived-At: Subject: [core] Fwd: Registration details for IETF 108 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 07:10:32 -0000 --3hLChAAckIULsuOpq7H1GmXrAmbFVOHwU Content-Type: multipart/mixed; boundary="Ass8FqscUAjbyBtooyqolOTVQ9ZqmH9C3" --Ass8FqscUAjbyBtooyqolOTVQ9ZqmH9C3 Content-Type: multipart/alternative; boundary="------------CE071CF8C3036D8737972686" Content-Language: en-US This is a multi-part message in MIME format. --------------CE071CF8C3036D8737972686 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI, just in case you don't follow the Announce mailing list. Best, /Marco -------- Forwarded Message -------- Subject: Registration details for IETF 108 Date: Wed, 27 May 2020 18:12:17 -0700 From: IETF Executive Director Reply-To: ietf108planning@ietf.org To: IETF Announcement List As previously announced [1], IETF 108 is switching to a fully online meeting over 5 days, 25-31 July, with an agenda structure similar to that of an in-person meeting [2]. Registrations will open on 8 June 2020 and the registration fees will be as follows: Early-Bird: USD 230, until 26 June 2020 Standard: USD 280, until 20 July 2020 Late: USD 330, after 20 July 2020 Full-time Student: USD 50 One Day Pass: USD 125 This meeting will have a substantial agenda but as the cost of an online meeting is lower, the registration fees have been set at approximately one-third of those for an in-person meeting. A detailed explanation of why we charge a fee for meetings and how the fee reduction was set for IETF 108 is provided in a separate blog post [3]. As online participants have until now not had to pay a fee, it is recognised that there may be some for whom the fee presents a barrier to participation and so we will provide up to 100 early bird fee waivers for IETF 108. If the number of waiver requests exceeds the number we can offer, waiver recipients will be chosen at random using a process similar to the one specified in RFC 3797. Details of how to apply for a waiver will be provided when registration opens. No decision has been made on whether or not a fee for online participation is needed when we return to in-person meetings. As this is a fully online meeting, there are two key changes in the meeting process for you to be aware of: 1. When you register you will be able to choose if you want to receive an IETF 108 t-shirt delivered to you at no additional expense. Numbers will be limited to 1000 t-shirts on a first-come-first-served basis with 900 for Early Birds and 100 for Students. 2. All participants will need a Datatracker account in order to authenticate with Meetecho. If you do not already have an account then one will be created for you during registration and you will receive a password setup link by email. As with in-person meetings, a video recording of each scheduled session will be posted after the session concludes and the proceedings will be posted in the normal timeframe following the meeting. Finally, we are still in the process of securing sponsors with some generous contributions already agreed and more under discussion. Full details and thanks will follow later. Please feel free to contact me directly if you have any questions or comments. [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/kzC7M48oKrAwdh9uyOvse= eKFW3A/ [2] https://www.ietf.org/blog/ietf108-survey-results-informed-planning/ [3] https://www.ietf.org/blog/ietf108-registration-fees --=20 Jay Daley IETF Executive Director exec-director@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------CE071CF8C3036D8737972686 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI, just in case you don't follow the Announce mailing list.

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: Registration details for IETF 108
Dat= e: Wed, 27 May 2020 18:12:17 -0700
Fro= m: IETF Executive Director <exec-director@ietf.org>
Rep= ly-To: ietf108planning@ietf.org
To:= IETF Announcement List <ietf-announce@ietf.org>


As previously announced [1], IETF 108 is switching to a fully online meeting over 5 days, 25-31 July, with an agenda structure similar to that of an in-person meeting [2].
Registrations will open on 8 June 2020 and the registration fees will be as follows:

Early-Bird: USD 230, until 26 June 2020
Standard: USD 280, until 20 July 2020
Late: USD 330, after 20 July 2020
Full-time Student: USD 50
One Day Pass: USD 125

This meeting will have a substantial agenda but as the cost of an online meeting is lower, the registration fees have been set at approximately one-third of those for an in-person meeting. A detailed explanation of why we charge a fee for meetings and how the fee reduction was set for IETF 108 is provided in a separate blog post [3].

As online participants have until now not had to pay a fee, it is recognised that there may be some for whom the fee presents a barrier to participation and so we will provide up to 100 early bird fee waivers for IETF 108. If the number of waiver requests exceeds the number we can offer, waiver recipients will be chosen at random using a process similar to the one specified in RFC 3797. Details of how to apply for a waiver will be provided when registration opens.

No decision has been made on whether or not a fee for online participation is needed when we return to in-person meetings.

As this is a fully online meeting, there are two key changes in the meeting process for you to be aware of:

1. When you register you will be able to choose if you want to receive an IETF 108 t-shirt delivered to you at no additional expense. Numbers will be limited to 1000 t-shirts on a first-come-first-served basis with 900 for Early Birds and 100 for Students.

2. All participants will need a Datatracker account in order to authenticate with Meetecho. If you do not already have an account then one will be created for you during registration and you will receive a password setup link by email.
As with in-person meetings, a video recording of each scheduled session will be posted after the session concludes and the proceedings will be posted in the normal timeframe following the meeting.

Finally, we are still in the process of securing sponsors with some generous contributions already agreed and more under discussion. Full details and thanks will follow later.

Please feel free to contact me directly if you have any questions or comments.

[1] https://mailarchive.i= etf.org/arch/msg/ietf-announce/kzC7M48oKrAwdh9uyOvseeKFW3A/
[2] https://www.ietf.org/blog/ie= tf108-survey-results-informed-planning/
[3] https://www.ietf.org/blog/ietf108-regist= ration-fees

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

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announc=
e
--------------CE071CF8C3036D8737972686-- --Ass8FqscUAjbyBtooyqolOTVQ9ZqmH9C3-- --3hLChAAckIULsuOpq7H1GmXrAmbFVOHwU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl7PY90ACgkQ7iZktA5Y 2kP5bwf8DjJ/JDLXmCeMUvhlnAdqwrzZPMWEKL3Gh8fiZKSRhbx8i1ptbTNFEuyB Sp1wpwCZHcpI/6VGpDP+jOV3Z9PqFjSCVeBSa2DsBKshxntfTWSgM7NQ5Z7Zc+by MYxryBn7tk1CsptrrJ1le/nKmQ535Z1HYz4+psGYKg6emTp4k+alh3y+s15mfS5H 5KgZ86jX9xjoOvPccNvLN8pF/q9s9dc/sjW5Wf9y5Jh43M/J2pg9qWUvPwwPKmCK 2Cc1OlTnsEZRrOKEmi+ZZ4jeEskHqP2J6JO3t2PiWpnYScKJiYR8HcGhQqoS8r6w s5/6KCa8vBM8WzNqKtRxz/CCHHCq2A== =xat9 -----END PGP SIGNATURE----- --3hLChAAckIULsuOpq7H1GmXrAmbFVOHwU-- From nobody Sun May 31 01:30:30 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC263A1337 for ; Sun, 31 May 2020 01:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVaNvThzSGcg for ; Sun, 31 May 2020 01:30:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87793A12DE for ; Sun, 31 May 2020 01:30:25 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49ZWhc2978zywK; Sun, 31 May 2020 10:30:24 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_BCD5C799-02EC-43E9-AACE-AF039793FB64" X-Mao-Original-Outgoing-Id: 612606623.784261-ac2bc5efe042c0a1246476afa33d350a Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 31 May 2020 10:30:23 +0200 Message-Id: <9DF0DB19-CF59-4D6B-888B-5D864C4E5877@tzi.org> References: <20200531061343.2C772F4071C@rfc-editor.org> To: core@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [core] Fwd: RFC 8782 on Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2020 08:30:29 -0000 --Apple-Mail=_BCD5C799-02EC-43E9-AACE-AF039793FB64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Congratulations to all that have helped make this happen! Gr=C3=BC=C3=9Fe, Carsten > From: rfc-editor@rfc-editor.org > Subject: RFC 8782 on Distributed Denial-of-Service Open Threat = Signaling (DOTS) Signal Channel Specification > Date: 2020-05-31 at 08:13:43 CEST > Archived-At: = >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 8782 >=20 > Title: Distributed Denial-of-Service Open Threat Signaling=20= > (DOTS) Signal Channel Specification=20 > Author: T. Reddy.K, Ed., > M. Boucadair, Ed., > P. Patil, > A. Mortensen, > N. Teague > Status: Standards Track > Stream: IETF > Date: May 2020 > Mailbox: kondtir@gmail.com,=20 > mohamed.boucadair@orange.com,=20 > praspati@cisco.com, > andrew@moretension.com,=20 > nteague@ironmountain.co.uk > Pages: 100 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-dots-signal-channel-41.txt >=20 > URL: https://www.rfc-editor.org/info/rfc8782 >=20 > DOI: 10.17487/RFC8782 >=20 > This document specifies the Distributed Denial-of-Service = =20 > Open Threat Signaling (DOTS) signal channel, a protocol for = =20 > signaling the need for protection against Distributed = Denial-of-Service =20 > (DDoS) attacks to a server capable of enabling network traffic = =20 > mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate = =20 > reliable communication layer for DOTS management and configuration = =20 > purposes. >=20 > This document is a product of the DDoS Open Threat Signaling Working = Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_BCD5C799-02EC-43E9-AACE-AF039793FB64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Congratulations to all that have helped make this happen!

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

From: = rfc-editor@rfc-editor.org
Subject: = RFC 8782 on = Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal = Channel Specification
Date: = 2020-05-31 at 08:13:43 CEST
Archived-At: = <https://mailarchive.ietf.org/arch/msg/ietf-announce/wWqXtIn6g7h= 3SugIlOaQCFOuE9w>

A new Request for Comments is now available in online RFC = libraries.


=        RFC 8782

       Title: =      Distributed Denial-of-Service Open Threat = Signaling
=             &n= bsp;      (DOTS) Signal Channel = Specification
=        Author: =     T. Reddy.K, Ed.,
=             &n= bsp;      M. Boucadair, Ed.,
=             &n= bsp;      P. Patil,
=             &n= bsp;      A. Mortensen,
=             &n= bsp;      N. Teague
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       May 2020
=        Mailbox:    kondtir@gmail.com,
=             &n= bsp;      mohamed.boucadair@orange.com,
=             &n= bsp;      praspati@cisco.com,
=             &n= bsp;      andrew@moretension.com,
=             &n= bsp;      nteague@ironmountain.co.uk
=        Pages: =      100
=        Updates/Obsoletes/SeeAlso: =   None

=        I-D Tag: =    draft-ietf-dots-signal-channel-41.txt

       URL: =        https://www.rfc-editor.org/info/rfc8782

       DOI: =        10.17487/RFC8782

This document specifies the Distributed = Denial-of-Service =             &n= bsp;           &nbs= p;   
Open Threat Signaling (DOTS) signal = channel, a protocol for =             &n= bsp;           &nbs= p;      
signaling the need = for protection against Distributed Denial-of-Service =             &n= bsp;    
(DDoS) attacks to a server = capable of enabling network traffic =             &n= bsp;           &nbs= p; 
mitigation on behalf of the requesting client.

A companion document defines the DOTS data = channel, a separate =             &n= bsp;          
reliable communication layer for DOTS management and = configuration =             &n= bsp;         
purposes.

This document is a = product of the DDoS Open Threat Signaling Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an = Internet Standards Track
protocol for the Internet = community, and requests discussion and suggestions
for = improvements.  Please refer to the current edition of the = Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. =  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce = and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail=_BCD5C799-02EC-43E9-AACE-AF039793FB64--