From nobody Thu Oct 1 11:05: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 B6DE73A11EA for ; Thu, 1 Oct 2020 11:05:33 -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 3_JPhCbEnCMT for ; Thu, 1 Oct 2020 11:05:32 -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 248F33A11E8 for ; Thu, 1 Oct 2020 11:05:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1685A38A19; Thu, 1 Oct 2020 14:10:31 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mGkSfu7A2USc; Thu, 1 Oct 2020 14:10:27 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EE6F38A18; Thu, 1 Oct 2020 14:10:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4F4C7CF4; Thu, 1 Oct 2020 14:05:26 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , core@ietf.org In-Reply-To: References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> <29736.1601491640@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] issues for stateless AD review 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, 01 Oct 2020 18:05:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-09-30, at 20:47, Michael Richardson wrote: >> >> I have created pull request #11 for this. Please comment > A couple typos (pushed to the PR branch already) and two comments: > https://github.com/core-wg/stateless/pull/11/files On the topic of "MAY" being BCP14 abuse, I was matching it to the RECOMMEND= ED above. based upon that, then I think that RECOMMENDED->recommended. (Do you know about the "suggestion" part in github?) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl92GmYACgkQgItw+93Q 3WXFXggAq9iKaE/wO0MKK3jcQ5G30/9O9hG1nYYXnXznadyGpt4ti0eBpnn0CWHJ WFVULodkgo6wQiUZOvx3siwKrnNDH7op9jaHVImYL6XotlYc+t7oyEyyJgLMB418 zFngij7qYJDAduF41ctnO5q1PdR3b9xm2dOvCoIclArFyA55mE+TmXfO0738nzuA pTgCRgtLOdr7RUqyPwPebupir3He5qZWr0jLwKET8kFT9j1cikP2kO2jw2v7wOS0 59oMGrtkfLZaFT3OafUx6PZqKeue1ZfgFanErgPLZQYvVRt9B/rYX9wfU+I4Ru2v yj+c0gYaK1YgMo4T+qkYGxAayceQ6g== =Zlfz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 1 11:23: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 4ACDB3A0A1E for ; Thu, 1 Oct 2020 11:23: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 6gxR6M1SaJKQ for ; Thu, 1 Oct 2020 11:23:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5363A0A1D for ; Thu, 1 Oct 2020 11:23:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 16386389F7 for ; Thu, 1 Oct 2020 14:28:06 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qw2XjJDCUomy for ; Thu, 1 Oct 2020 14:28:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 02C8E389B3 for ; Thu, 1 Oct 2020 14:28:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CBFBDCF4 for ; Thu, 1 Oct 2020 14:23:03 -0400 (EDT) From: Michael Richardson to: core@ietf.org In-Reply-To: <30317.1601403281@localhost> References: <30317.1601403281@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] stateless issue #10 -- 60 minutes 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, 01 Oct 2020 18:23:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >#10 60 minutes for address change > https://github.com/core-wg/stateless/issues/10 In this issue, Carsten wrote: > The number indeed sounds arbitrary. We could make use of the parameter > mechanics that RFC 7252 has (ACK_TIMEOUT and friends) and set the default > to 1800 s. and I spent an hour pondering through RFC7252's timer section (which I was intentionally ignorant of..) to try and figure out how to leverage ACK_TIMEOUT. My understanding of the concern it that the mapping of IPaddress -> maximum token length might become invalid because the IPaddress might no longer be associated with that host. So we have to recheck things periodically, and the question is, what is a useful period. 60 minutes seems arbitrary. I don't see how ACK_TIMEOUT re= lates. What I think would relate would be DHCPv[46] or Router Advertisement lifeti= mes. I think that a node can assume that most *local* hosts will have a lifetime similar to their own, so if one has a 7200s DHCP leases, then another host = in the same subnet will probably have a similar affity to an address. Of course, this does *NOTHING* to help with hosts elsewhere. So for non-local hosts, a default, as Carsten suggested of 1800s (30min) seems as appropriate as 60 minute. What we are looking for is a way to intelligently increase the value as high as possible so as to reduce traffic. DNS TTLs seem to fit here as a hint. That fails if the connection is configured with raw IPs, but then back to t= he defaults. Pull request: https://github.com/core-wg/stateless/pull/12 diff --git a/draft-ietf-core-stateless.xml b/draft-ietf-core-stateless.xml index aa44479..1999971 100644 =2D-- a/draft-ietf-core-stateless.xml +++ b/draft-ietf-core-stateless.xml @@ -417,10 +417,13 @@ =2D Since network addresses may change, =2D a client SHOULD NOT assume that extended token lengths are s= upported =2D by a server later than 60 minutes after receiving the most-r= ecent response with an extended =2D token length. + Since network addresses may change, a client SHOULD NOT assume= that extended token + lengths are supported by a server for an unlimited duration. + Unless additional information is available, the client should = assume that addresses (and therefore extended token lengths) are valid for = a minimum of 1800s, and for a maximum of 86400s (1 day). + A client may use additional forms of input into this determina= tion. + For instance a client may assume a server which is in the same= subnet as the client has a similiar address lifetime as the client. + The client may use DHCP lease times or Router Advertisements t= o set the limits. + For servers which is not local, if the server was looked up us= ing DNS, then the DNS resource record will have a Time To Live, and the ext= ended token length should be kept for only that amount of time. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl92HocACgkQgItw+93Q 3WVp8Af/dmEr74qmY3RtP00UqZj+Bl3oLu62SQ5EpIn42EbAsmrQeffRYIwwbDPD 3SdE9XQPuaqJuFztPtCPhR/AHvISVTcHAtLq7U/AKL650GYD7aPHjmpUtzD7DhBF qaJe2qEr1EORi730H0eZNqqWBZco8VU8Ib3PHNj5CNeg4RYrG1do3XTjnUf8D0lH iBcp5k6VchtNYR3XTqnP8n8uK/2tvasPZHwZsR89tJ5Tyh/hq/jiKjF7tkEjxgt1 SbfLognrJODWsqP3iv7QCz8WEbadDmJoihYBTk3fxsZm3HkfpSewgys4fjQtBTNO BPmRACs9i9S1wK3nTKN1EEDo85beyA== =iRAF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 1 11:36:14 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 66AB23A0D86 for ; Thu, 1 Oct 2020 11:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKgQd2AlKOlc for ; Thu, 1 Oct 2020 11:36:10 -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 0FA443A0A90 for ; Thu, 1 Oct 2020 11:36:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C58FC389FA for ; Thu, 1 Oct 2020 14:41:09 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cKnca8M-wNJe for ; Thu, 1 Oct 2020 14:41:09 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C665389F9 for ; Thu, 1 Oct 2020 14:41:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1B2D4CF4 for ; Thu, 1 Oct 2020 14:36:08 -0400 (EDT) From: Michael Richardson To: core@ietf.org In-Reply-To: <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] integrity protection for trial-and-error determine of token length 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, 01 Oct 2020 18:36:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > #5 lack of integrity protection results in spoofed responses > https://github.com/core-wg/stateless/issues/5 bk> With no integrity protection on the rejection of trial-and-error (secti= on bk> 2.2.2) it's susceptible to downgrade, IIUC even by an off-path bk> attacker. (I did not think too hard about whether OSCORE could protect bk> the Resets in question or not, though.) It seems like such forced bk> downgrade would have second-order effects in causing clients to use more bk> local state and thus be more readily susceptible to other DoS vecros. My understanding is that the Reset will have to echo the MID. While they are probably incrementally assigned, and so not a lot of protection, off path attackers do not see them. RFC7252 section 5.3.1 says that they can be: (Note that the Message ID adds little in protection as it is usually sequentially assigned, i.e., guessable, and can be circumvented by spoofing a separate response. but, I don't think the separate response is substitutable for the Reset. The Reset includes the message ID, so I think that we have some minimal defense against an off-path attacker that just sprays Resets. It also seems that such an attack breaks many other things already. My second observation, as a user of stateless in 6tisch-minimal-security. We can not function when the token length is smaller than some amount. We don't resort to keep state, we failover to another server, or we just br= eak. So, while this might be a DoS attack, this is not a downgrade attack. Also, we assume L2 security across the wireless portion, but the attack cou= ld originate on some wired segment from some infected "desktop" plant control system. I'm not too sure what text I can add, but I can include the above discussio= n. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl92IZcACgkQgItw+93Q 3WUeiwf9EEH5ucUX4wS2+pbkkwIFBLBE6ozjYQ+rGpwsi4prxHLAXLzVHNbtf9vy pYO0cTEjgt2yRTefc/AjWJkj3ry6e/i2KQY5m8qZzpJw+9FmdNaKTlK26uQcv0oe d/iR8eYqHZ0nlPE+dPjAnPxz6BkebaRoM1TZ3z1p1UcYw3hpoxh45pqkDZL12NkK ZPJEWMQwutbxyiS1VymC8JOopJ1Fs5grsf8nLf3d3VfMbJSPBa33gmi/5Kw/rpDV ZNoQLypWguJsTHxFpn6hxUGO+xYR4PIylWrKu9hedJzzGLWSX+6LQzQG8bGZsss0 aTbSPA6PDztRNkyhBzSCz/13BXBZhA== =0PLk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 1 12:17:18 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 1D2DA3A0E60 for ; Thu, 1 Oct 2020 12:17:16 -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 CFYoOgd5EHOP for ; Thu, 1 Oct 2020 12:17:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0364E3A0E5E for ; Thu, 1 Oct 2020 12:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0B74238A13 for ; Thu, 1 Oct 2020 15:22:14 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UpfJCy7llKUH for ; Thu, 1 Oct 2020 15:22:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 00F4C38A0E for ; Thu, 1 Oct 2020 15:22:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A9E26CF4 for ; Thu, 1 Oct 2020 15:17:08 -0400 (EDT) From: Michael Richardson to: core@ietf.org In-Reply-To: <17803.1601577368@localhost> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> <17803.1601577368@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] integrity protection for trial-and-error determine of token length 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, 01 Oct 2020 19:17:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > #5 lack of integrity protection results in spoofed responses > https://github.com/core-wg/stateless/issues/5 bk> Also, when integrity protection is not in use, the client is susceptible bk> to spoofed responses that had no corresponding request -- only a very bk> limited subset of request/response pairs are safe to convert to bk> "unauthenticated server push", as that would effectivley do, and we bk> should probably mention that explicitly. This is, I think, not about the responses to the trial-and-error, but about fake/spoofed replies to queries that the client makes that have a token. I'm not sure how stateless is intended to interact with OBSERVE, which I think that this is about. Have I understood this part? bk> I'd also suggest noting that a self-encrypted state token bears bk> significant resemblance to a TLS self-encrypted session ticket, and bk> reference the RFC 5077 security considerations. (Yes, I know that RFC bk> 8446 Obsoletes RFC 5077; it would be an informational reference only.) It's certainly similar in that it is a self-encrypted thing in which state = is placed. I don't think that a reference to RFC5077 will be helpful here, but I can look for a good place to insert this if desired. bk> This could also lead to some discussion about having in general an bk> appropriate amount of sanity checks on the returned token that may or m= ay bk> not reflect serialized state, to limit the scope of various attacks even bk> in the absence of cryptographic protections. I think that an appropriate thing is to caution against using state tokens that do not have integrity protection. I think that we try to do this in 5.2, but maybe we do in text too cryptic: 5.2. Stateless Clients and Intermediaries ... It is generally expected that the use of encryption, integrity protection, and replay protection for serialized state is appropriate. In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client. 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. https://github.com/core-wg/stateless/pull/13 diff --git a/draft-ietf-core-stateless.xml b/draft-ietf-core-stateless.xml index aa44479..748ef21 100644 =2D-- a/draft-ietf-core-stateless.xml +++ b/draft-ietf-core-stateless.xml @@ -856,10 +856,15 @@ in a reply, or an unsolicited one) that could alter the internal= state of the client. =2D However, a careful analysis of any potential attacks to the se= curity =2D and privacy properties of the system might reveal that there a= re cases =2D where such cryptographic protections do not add value in a spe= cific =2D case. + It is this reason that at least the use of integrity protection = on + the token is always recommended. + + + + It maybe that in some very specific case, as a result of a caref= ul + and detailed analysis of any potential attacks, that there may = be cases + where such cryptographic protections do not add value. The auth= ors + of this document have not found such a use case as yet. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl92KzQACgkQgItw+93Q 3WXUtAgAui/K6gNWkly1a97/XpVsGSpFx5wK1TEBorq4+k9QTwe1qt6za2O4Pqbf jT2DfbN3ysMJJcf5PKFl0OiwMiUG+uaVSaCL6+8SpD15PNrqpcUcmlfGXcvCyvR9 iPj41WTfG/G5n8J6BEDRDe2X2AdnIFxaH+DNo8zRoY2Bf8AGFukEDYpzVtkZNYQx 1ZV2dvrXpuNrgde2R6e0oAaHX14ft6mdz9C2E+266o5YhDlDScTwSaMEHSZEh8gp uF8M1KIVcD8FoC2gwH/0vuhieC/TRyfO5suXKcSX/9aFl2vgyiOKJ/376PWVUiCR yjynWHZ0dZpgi0eYooe0y/hnmrmUFA== =a+OU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 1 12:18: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 ACFA73A0E60 for ; Thu, 1 Oct 2020 12:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iQsYmlY_qmo for ; Thu, 1 Oct 2020 12:18:01 -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 3DA7B3A0E5E for ; Thu, 1 Oct 2020 12:18:00 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4C2NF31gLjzySy; Thu, 1 Oct 2020 21:17:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <14916.1601576583@localhost> Date: Thu, 1 Oct 2020 21:17:58 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 623272678.663955-2fa702d8f418abeefa2ba0d6db69da56 Content-Transfer-Encoding: quoted-printable Message-Id: <1183A55C-B2E5-4B73-9A90-B5E19F9F4B80@tzi.org> References: <30317.1601403281@localhost> <14916.1601576583@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] stateless issue #10 -- 60 minutes 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, 01 Oct 2020 19:18:04 -0000 On 2020-10-01, at 20:23, Michael Richardson = wrote: >=20 > I don't see how ACK_TIMEOUT relates. It doesn=E2=80=99t. The way that RFC 7252 manages (not-so) constants like that does. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 1 12:21: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 DA6323A0E65 for ; Thu, 1 Oct 2020 12:21: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 AMaLjQvyXN61 for ; Thu, 1 Oct 2020 12:21:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206EA3A0E5E for ; Thu, 1 Oct 2020 12:21:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 962DC38A13 for ; Thu, 1 Oct 2020 15:26:03 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6b1O-7JFssOa for ; Thu, 1 Oct 2020 15:25:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5719A38A0E for ; Thu, 1 Oct 2020 15:25:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0935CCF4 for ; Thu, 1 Oct 2020 15:20:58 -0400 (EDT) From: Michael Richardson To: core@ietf.org In-Reply-To: <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] issues for stateless AD review 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, 01 Oct 2020 19:21:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable At this point, I will stop, and hope that the WG will comments on the threa= ds and github. Carsten Bormann wrote: >> With Klaus' blessing, I have turned the remaining DISCUSS points into >> issues. > (And I sent some comments.) > Overall, I think we should generate I-D text for: > #10 60 minutes for address change > https://github.com/core-wg/stateless/issues/10 > #5 lack of integrity protection results in spoofed responses > https://github.com/core-wg/stateless/issues/5 done. > We should replace confusing I-D text here: > #8 use automated key management due to AES-CCM/BCP107 > https://github.com/core-wg/stateless/issues/8 done. > #4 how does freshness window of client/intermediate interact? > https://github.com/core-wg/stateless/issues/4 I can see some text added for this, commented. > I think we can simply explain a wontfix on: > #3 is stateless updating 7252 on distinguishing unrecognized vs inval= id > extension? https://github.com/core-wg/stateless/issues/3 > #6 can larger tokens fill responder memory? > https://github.com/core-wg/stateless/issues/6 > #7 how to size the replay window? > https://github.com/core-wg/stateless/issues/7 > #9 look ma, no state! https://github.com/core-wg/stateless/issues/9 =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl92LBkACgkQgItw+93Q 3WUnpwf/RFWzsSMn9p1a6w0z0RXyV4Irpc87XxUMfLQurgyrjzHSibSiP6j9WZPL 1r1OClhdH9TRbdHWi2LsC3mZkRJXhkPwJD5pHSgyxRVhu8OLnizU0YAUQU3I0cbK MOk5LF+SxzlnBgAzpENm5LQpAGBaylYYYZWSmzZDHDgxWGVYoB597z0+mOKaJYMS vMfqBb+RqbKLL/np1w+uhaTmQGB2uaa2g3QdAnlcMfZi9/7d5z78YXZpaS+mp4wC SACygyeQNPQFlJM1v+08LDHhrjSPc4V41+Sa6bTmREYlU00hQxyUQ+Npqp+rgMmv cNpbmj6f4+1qANU0rcUM6jM61qKbsg== =ZOxe -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 1 13:22: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 284AA3A084B for ; Thu, 1 Oct 2020 13:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6b2qckLNcnx for ; Thu, 1 Oct 2020 13:22:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706073A010A for ; Thu, 1 Oct 2020 13:22:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DE0538A13; Thu, 1 Oct 2020 16:27:17 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JQbs_Ye8YIjj; Thu, 1 Oct 2020 16:27:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5995938A05; Thu, 1 Oct 2020 16:27:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA5E318B; Thu, 1 Oct 2020 16:22:11 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , core@ietf.org In-Reply-To: <1183A55C-B2E5-4B73-9A90-B5E19F9F4B80@tzi.org> References: <30317.1601403281@localhost> <14916.1601576583@localhost> <1183A55C-B2E5-4B73-9A90-B5E19F9F4B80@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] stateless issue #10 -- 60 minutes 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, 01 Oct 2020 20:22:20 -0000 Carsten Bormann wrote: > On 2020-10-01, at 20:23, Michael Richardson > wrote: >> >> I don't see how ACK_TIMEOUT relates. > It doesn=E2=80=99t. > The way that RFC 7252 manages (not-so) constants like that does. I thought that the suggestion was to have the value somehow be some function of ACK_TIMEOUT. I guess you mean, that it would be specified in the same fashion? -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Thu Oct 1 14:09: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 5C5233A0937 for ; Thu, 1 Oct 2020 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8HzxslGXkDI for ; Thu, 1 Oct 2020 14:09:01 -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 DA0823A0925 for ; Thu, 1 Oct 2020 14:09:00 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4C2Qj70w4WzyTT; Thu, 1 Oct 2020 23:08:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <10453.1601583731@localhost> Date: Thu, 1 Oct 2020 23:08:58 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 623279338.638893-721e3c3b3d040f965358c4feca025d2f Content-Transfer-Encoding: quoted-printable Message-Id: <75C3FE62-EDC9-47FD-8C91-30D36EBA8ABA@tzi.org> References: <30317.1601403281@localhost> <14916.1601576583@localhost> <1183A55C-B2E5-4B73-9A90-B5E19F9F4B80@tzi.org> <10453.1601583731@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] stateless issue #10 -- 60 minutes 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, 01 Oct 2020 21:09:03 -0000 On 2020-10-01, at 22:22, Michael Richardson wrote: >=20 >=20 > Carsten Bormann wrote: >> On 2020-10-01, at 20:23, Michael Richardson >> wrote: >>>=20 >>> I don't see how ACK_TIMEOUT relates. >=20 >> It doesn=E2=80=99t. >> The way that RFC 7252 manages (not-so) constants like that does. >=20 > I thought that the suggestion was to have the value somehow be some = function > of ACK_TIMEOUT. No, I don=E2=80=99t see how they are related. > I guess you mean, that it would be specified in the same fashion? Yes, the transmission parameters in Section 4.8 are a good way to = contain the =E2=80=9Cneed to pick out of thin air=E2=80=9D values we = rely on=E2=80=A6=20 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 2 17:18: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 CDC993A1765; Fri, 2 Oct 2020 17:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3GfCOp6-S0s; Fri, 2 Oct 2020 17:18:33 -0700 (PDT) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (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 08A5D3A175D; Fri, 2 Oct 2020 17:18:33 -0700 (PDT) Received: by mail-ed1-f45.google.com with SMTP id dn5so3515962edb.10; Fri, 02 Oct 2020 17:18:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jBBm/j318PyosLTsGlKjVZheDcfC0aTcHr+A8LMOgTI=; b=hhAZyabF6Lwo5qwrACVdWk5IOYgzy0Y9gmgsOXvkCz7wkr8Wwq6VBebY/a/Af5GoQ3 9psvR/UPmSYwgWi68QW1v//5ST7vN1iqyRvXskbgJ8FN9fRJ1A1qxT5U0HFqJGMdzdeb BBo+JM+SofsVd6jmgf7HyUkcRkHGsP2k2HE4pRKm2WS0bcmaYt8RqUJer/MI4MOQbxyc 6pum+iFlDYIS2H0DopO15GNRX358Zn0uU+t9/j3MDVdaccgM4+unRE7avY9KySQJxOv5 IKl4kVN01gghOPnru1cLnjAym2nFM+Gu3ns03bngJ2/fL8P+7TROjM1PdmCCls/IDaNF SkYQ== X-Gm-Message-State: AOAM531BEnLQm5mlWirqkrLQwM+JXXTrkaBXhCL7weX+U6fNe7IysOZp ZfLhbZvpBThxU0wH1poqIfEvgdGeSlzpY0QPEuI= X-Google-Smtp-Source: ABdhPJzh07mA8hSGQghdy33IsL/WbLlB1g5RDX7IyYRtvrDNyiWpl4qNMzHo5jnBPhnDIFtaXpq9hQyitpCe4VnufA4= X-Received: by 2002:aa7:dd0d:: with SMTP id i13mr5413435edv.314.1601684311349; Fri, 02 Oct 2020 17:18:31 -0700 (PDT) MIME-Version: 1.0 References: <159730632066.12379.5174560093789503034@ietfa.amsl.com> In-Reply-To: <159730632066.12379.5174560093789503034@ietfa.amsl.com> From: Barry Leiba Date: Fri, 2 Oct 2020 20:18:20 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , core@ietf.org, core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com Content-Type: multipart/alternative; boundary="0000000000006b9df605b0b93001" Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 03 Oct 2020 00:18:38 -0000 --0000000000006b9df605b0b93001 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authors and WGCs, We have four DISCUSS ballots on this and a number of other IESG comments, and I haven=E2=80=99t seen responses to the ADs. When can we get some enga= gement on these issues? Barry On Thu, Aug 13, 2020 at 4:12 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-core-resource-directory-25: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I agree with Roman that the authorization model seems under-developed. > > While I recognize that there is need for flexibility across various > > deployments, I think that we should be providing a default model (and > > procedures for it) that will apply in many cases, and let > > deployments specify alternate models if needed. This stuff is hard > > enough to get right that we should have a secure option that people can > > use if they don't need to have customized details. (To be clear, I > > agree with the change of focus from -24 to -25 on the properties that a > > security policy needs to provide and/or consider, as that is > > fundamentally the important thing. I just want a fallback/default > > option that "does something reasonable in most cases" in addition. > > Doing that by reference to some other existing thing would be fine, if > > such a thing exists.) > > > > In particular, the current text seems to rely on the authorization > > model including: > > > > (1) the RD knowing how clients will be using it (and thus what > > properties the RD needs to enforce), which in the general case cannot be > > known (though for static networks it could be), yet I don't see any > > discussion that indicates this as a prerequisite; and > > > > (2) the client either knowing out-of-band that an entity is authorized > > to act as a RD or just blindly trusting any of the unauthenticated (*) > > advertisement mechanisms. (* Yes, there may be some protection in the > > network on subscribing to the relevant multicast address, DNS-SD, etc., > > but the client cannot a priori know that such protections are in place.) > > > > Relatedly, the naming model and naming authority should have some > > clearer discussion. We do mention in Section 7 the possibility for a > > weak naming model where the RD is responsible for enforcing uniqueness > > of names but otherwise link attributes are the primary authorization > > criteria (vs. a traditional scheme with a naming authority and naming > > hierarchy), but with naming as a fundamental prerequisite of any > > authentication/authorization scheme, I think clearer discussion of how a > > naming model is to be selected (and, perhaps more importantly, that it > > must be fixed as part of a given deployment) for a given network is > > needed. > > > > If I understand correctly, we have some codepoint squatting going on in > > the examples (e.g., for resource types). > > > > We should talk about the security properties of the various RD discovery > > mechanisms that are defined. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > My apologies for where these comments diverge off into rambling > > incoherency, or where I'm misunderstanding something that's clearly laid > > out; this document had the misfortune of being the last one I got to > > this week. > > > > Section 1 > > > > [RFC6690] only describes how to discover resources from the web > > server that hosts them by querying "/.well-known/core". In many > > constrained scenarios, direct discovery of resources is not practical > > due to sleeping nodes, disperse networks, or networks where multicast > > traffic is inefficient. These problems can be solved by employing an > > entity called a Resource Directory (RD), which contains information > > about resources held on other servers, allowing lookups to be > > performed for those resources. > > > > nit(?): I'd consider specifying that the RD is "a trusted entity". > > (Even when the resources themselves are authenticated, a hostile RD can > > still deny existence of a given resource, so by choosing to use an RD > > there is some level of trust involved.) > > > > Section 2 > > > > Resource Directory (RD) > > A web entity that stores information about web resources and > > implements the REST interfaces defined in this specification for > > discovery, for the creation, the maintenance and the removal of > > registrations, and for lookup of the registered resources. > > > > nit: the list structure is not parallel here. Maybe "for discovery, > > creation, maintenance, and removal of registrations, and for lookup of > > the registered resources"? > > > > Commissioning Tool > > Commissioning Tool (CT) is a device that assists during the > > installation of the network by assigning values to parameters, > > naming endpoints and groups, or adapting the installation to the > > needs of the applications. > > > > Is "the installation of the network" a one-time event? (Might a CT be > > involved when adding a new device to a network at a later time?) > > > > Section 3.1 > > > > Information SHOULD only be stored in the RD if it can be obtained by > > querying the described device's /.well-known/core resource directly. > > > > When might that not be the case? > > > > Section 3.2 > > > > The RD architecture is illustrated in Figure 1. An RD is used as a > > repository of registrations describing resources hosted on other web > > servers, also called endpoints (EP). An endpoint is a web server > > associated with a scheme, IP address and port. A physical node may > > > > (side note) hmm, I feel like in the HTTP world an endpoint is more > > likely to be associated with a DNS name than an IP address, in common > > usage. Also, we later go on to assert that the endpoint's name has > > primacy and that the IP address/port can be ephemeral. > > > > An endpoint uses specific interfaces to register, update and remove a > > registration. It is also possible for an RD to fetch Web Links from > > endpoints and add their contents to its registrations. > > > > At the first registration of an endpoint, a "registration resource" > > is created, the location of which is returned to the registering > > endpoint. The registering endpoint uses this registration resource > > to manage the contents of registrations. > > > > Does the "RD fetches links unilaterally" case count as a "first > > registration of an endpoint"? I'm having a hard time seeing how these > > two statements are consistent with each other, and a naive reading > > admits the possibility that a given endpoint could be "locked out" of > > the ability to manage the contents of its registrations. > > > > Section 4 > > > > REST clients (registrant-EPs and CTs during registration and > > maintenance, lookup clients, RD servers during simple registrations) > > MUST be prepared to receive any unsuccessful code and act upon it > > according to its definition, options and/or payload to the best of > > their capabilities, falling back to failing the operation if recovery > > is not possible. In particular, they should retry the request upon > > > > "MUST be prepared [...] to the best of their abilities" seems > > non-actionable. The stuff after "In particular", on the other hand, is > > actual concrete guidance that could be mandated using normative > > language. > > > > Section 4.1 > > > > 1. In a 6LoWPAN, just assume the Border Router (6LBR) can act as an > > RD (using the ABRO option to find that [RFC6775]). Confirmation > > can be obtained by sending a Unicast to "coap://[6LBR]/.well- > > known/core?rt=3Dcore.rd*". > > > > nit(?): I was unaware that "Unicast" was a proper noun. > > > > Section 4.3 > > > > "core.rd" in the query string. Likewise, a Resource Type parameter > > value of "core.rd-lookup*" is used to discover the URIs for RD Lookup > > operations, core.rd* is used to discover all URI paths for RD > > operations. [...] > > > > Is the distinction between URIs (for RD Lookup) and URI paths (for RD) > > important here? > > > > While the link targets in this discovery step are often expressed in > > path-absolute form, this is not a requirement. Clients of the RD > > SHOULD therefore accept URIs of all schemes they support, both as > > URIs and relative references, and not limit the set of discovered > > URIs to those hosted at the address used for URI discovery. > > > > I'm not sure I see how the "not limit [...] to those hosted at the > > address used for URI discovery" follows from the non-requirement for > > expression of the link-targets from discovery in path-absolute form. > > (Given the ability to send the discovery query to a multicast address, > > the guidance seems okay; it's just the "therefore" that is puzzling me.) > > > > It would typically be stored in an implementation information link > > (as described in [I-D.bormann-t2trg-rel-impl]): > > > > Req: GET /.well-known/core?rel=3Dimpl-info > > > > This seems to be depicting a link-relation type that is not registered > > at https://www.iana.org/assignments/link-relations/link-relations.xhtml > > , i.e., codepoint squatting. Please put in a stronger disclaimer that > > this is an example link relation type, not just an example exchange. > > > > Section 5 > > > > These first few paragraphs give the impression that this is > > first-come-first-served with minimal authentication or authorization > > checking. Mentioning that there are authorization checks, with a > > forward-reference, might be helpful. > > > > further parameters (see Section 9.3). The RD then creates a new > > registration resource in the RD and returns its location. The > > > > Is this returned "registration resource" expected to function as a > > "capability URL" (https://www.w3.org/TR/capability-urls/) that would > > need to contain an appropriate amount of entropy to be reasonably > > unguessable by parties other than the registrant-ep/CT responsible for > > it? > > > > The registration request interface is specified as follows: > > > > Interaction: EP -> RD > > > > I thought that the CT could be a requestor as well as the EP. > > > > well. The endpoint name and sector name are not set when one > > or both are set in an accompanying authorization token. > > > > What should the RD do if they are set but also present in the > > accompanying authorization token? > > > > Req: POST coap://rd.example.com/rd?ep=3Dnode1 > > Content-Format: 40 > > Payload: > > ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", > > > > (side note) XML for the sensors, not SenML? With Carsten as an author, > > even? ;) > > > > An RD may optionally support HTTP. Here is an example of almost the > > same registration operation above, when done using HTTP. > > > > Req: > > POST /rd?ep=3Dnode1&base=3Dhttp://[2001:db8:1::1] HTTP/1.1 > > Host: example.com > > > > Wouldn't "Host: rd.example.com" be closer to "almost the same > > registration"? > > > > Section 5.1 > > > > I'm a little uneasy about specifying new behavior for POST to the > > existin /.well-known/core that was defined by RFC 6690 for other uses. > > What factors go into using the same well-known URI vs. defining a new > > one for this usage? > > > > The sequence of fetching the registration content before sending a > > successful response was chosen to make responses reliable, and the > > caching item was chosen to still allow very constrained registrants. > > > > I'm not sure what "the caching item" is supposed to be (if it's not a > > typo/misordering of words). > > > > Section 5.3 > > > > queries concerning this endpoint. The RD SHOULD continue to provide > > access to the Registration Resource after a registration time-out > > occurs in order to enable the registering endpoint to eventually > > refresh the registration. The RD MAY eventually remove the > > registration resource for the purpose of garbage collection. If the > > Registration Resource is removed, the corresponding endpoint will > > need to be re-registered. > > > > (This MAY is actually a MUST for the simple registration case, per =C2=A7= 5.1, > > right?) > > > > Section 5.3.1 > > > > An update MAY update the lifetime or the base URI registration > > parameters "lt", "base" as in Section 5. Parameters that are not > > > > What about the "extra-attrs"; are they inherently forbidden from > > updates? > > > > base :=3D Base URI (optional). This > > parameter updates the Base URI established in the original > > registration to a new value. If the parameter is set in an > > update, it is stored by the RD as the new Base URI under which > > to interpret the relative links present in the payload of the > > original registration, following the same restrictions as in > > the registration. If the parameter is not set in the request > > > > nit: is it the interpretation of relative links that is following the > > same restrictions as in the registration, or the new value of the > > parameter being supplied in the update? > > > > The following example shows how the registering endpoint updates its > > registration resource at an RD using this interface with the example > > location value: /rd/4521. > > > > The path component "4521" contains a worryingly small amount of > > unpredictableness; I would prefer examples that used longer random > > locations, as for capability URLs. (Throughout the document, of > > course.) See also draft-gont-numeric-ids-sec-considerations, that I'm > > AD sponsoring, though I do not see any clear issues on first glance. > > > > (Also, it might be worth another sentence that this update is serving > > just to reset the lifetime, making no other changes, since this might be > > expected to be a common usage.) > > > > Section 6 > > > > With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level > > siblings, would it make sense to put 6.2, or at least 6.3, as > > subsections under 6.1? > > > > Section 6.1 > > > > Resource lookup results in links that are semantically equivalent to > > the links submitted to the RD. The links and link parameters > > returned by the lookup are equal to the submitted ones, except that > > the target and anchor references are fully resolved. > > > > Are the "submitted ones" the submissions at registration time, or during > > the lookup query itself? (I assume registration-time, but being > > explicit costs little.) > > > > If the base URI of a registration contains a link-local address, the > > RD MUST NOT show its links unless the lookup was made from the same > > link. The RD MUST NOT include zone identifiers in the resolved URIs. > > > > Same link as what? > > > > Section 6.2 > > > > The page and count parameters are used to obtain lookup results in > > specified increments using pagination, where count specifies how many > > > > (We haven't introduced the page and count parameters yet.) > > > > operator as in Section 4.1 of [RFC6690]. Attributes that are defined > > as "link-type" match if the search value matches any of their values > > > > Where is it specified how an attribute might be "defined as > > 'link-type'"? This is the only instance of the string "link-type" in > > this document, and it does not appear in RFC 6690 at all... > > > > references) and are matched against a resolved link target. Queries > > for endpoints SHOULD be expressed in path-absolute form if possible > > and MUST be expressed in URI form otherwise; the RD SHOULD recognize > > either. The "anchor" attribute is usable for resource lookups, and, > > if queried, MUST be for in URI form as well. > > > > I don't see how it can be only a SHOULD to recognize either given these > > generation criteria. > > > > Section 6.3 > > > > The following example shows a client performing a lookup of all > > resources of all endpoints of a given endpoint type. It assumes that > > two endpoints (with endpoint names "sensor1" and "sensor2") have > > previously registered with their respective addresses > > "coap://sensor1.example.com" and "coap://sensor2.example.com", and > > posted the very payload of the 6th request of section 5 of [RFC6690]. > > > > Er, the 6th request is a GET; do we mean to say the response to the 6th > > request? > > > > Section 6.4 > > > > The endpoint lookup returns registration resources which can only be > > manipulated by the registering endpoint. > > > > This seems to leave it unclear whether the endpoint lookup is expected > > to return resources that the requestor will not have permission to > > manipulate (in addition to those it does have permission for). > > > > While Endpoint Lookup does expose the registration resources, the RD > > does not need to make them accessible to clients. Clients SHOULD NOT > > attempt to dereference or manipulate them. > > > > But why expose them at all if they're not going to be accessible? > > > > An RD can report endpoints in lookup that are not hosted at the same > > address. [...] > > > > The "same address" as what? > > > > Section 7.1 > > > > Whenever an RD needs to provide trustworthy results to clients doing > > endpoint lookup, or resource lookup with filtering on the endpoint > > > > How will the RD know whether the client is expecting trustworthy > > results? (When would a client *not* expect trustworthy results?) > > > > name, the RD must ensure that the registrant is authorized to use the > > given endpoint name. This applies both to registration and later to > > operations on the registration resource. It is immaterial there > > whether the client is the registrant-ep itself or a CT is doing the > > registration: The RD can not tell the difference, and CTs may use > > > > I suppose there might be plausible authorization models where a > > return-routability check to a given address constitutes authorization to > > use that address as an endpoint name, in which case the RD can tell the > > difference between a registrant-ep and a CT attempting to act on its > > behalf. > > > > When certificates are used as authorization credentials, the > > sector(s) and endpoint name(s) can be transported in the subject. In > > an ACE context, those are typically transported in a scope claim. > > > > As Russ noted in the Gen-ART review, "transported in the subject" is > > sufficiently vague to not really be actionable. It might be better to > > say that the holder of the private key corresponding to the public key > > certified in the certificate is generally considered authorized to act > > on behalf of any identities (including endpoint names) contained in the > > certificate's subject name. > > > > Section 7.1.1 > > > > Conversely, in applications where the RD does not check the endpoint > > name, the authorized registering endpoint can generate a random > > number (or string) that identifies the endpoint. The RD should then > > > > How much entropy/randomness in the random name? Does a CSPRNG need to > > be used? (I do see the follow-up about doubling the length in case of > > failure or starting with a UUID if that's not possible, but some > > guidance on where to start still seems appropriate.) > > > > Section 7.2 > > > > When lookup clients expect that certain types of links can only > > originate from certain endpoints, then the RD needs to apply > > filtering to the links an endpoint may register. > > > > As before, how will the RD know what behavior clients are relying on? > > > > An RD may also require that only links are registered on whose anchor > > (or even target) the RD recognizes as authoritative of. One way to > > > > I don't think I can parse this sentence (especially "the RD recognizes > > as authoritative of"). > > > > Section 8 > > > > In contexts where we discuss DTLS and TLS as being generally comparable, > > we typically will state that DTLS replay protection is required in order > > to provide equivalent levels of protection. > > > > We might also want to reiterate or refer back to the previous discussion > > of the potential for attributes or resource/endpoint names, link > > relations, etc. that may need to be confidential, the relevant access > > control/filtering, and the avenues by which disclosure of resource names > > can occur even when access to those resources will not be permitted. (I > > think some of this overlaps with 8288 and 6690, but don't mind repeating > > it.) > > > > Section 8.1 > > > > It's probably worth reiterating that all name comparisons must be done > > at sector scope (since failing to do so can lead to attacks). > > > > Endpoint authentication needs to be checked independently of whether > > there are configured requirements on the credentials for a given > > endpoint name (Section 7.1) or whether arbitrary names are accepted > > (Section 7.1.1). > > > > I think this is more properly authorization than authentication. > > > > Section 8.3 > > > > attacks. There is also a danger that NTP Servers could become > > implicated in denial-of-service (DoS) attacks since they run on > > unprotected UDP, there is no return routability check, and they can > > have a large amplification factor. The responses from the NTP server > > were found to be 19 times larger than the request. An RD which > > > > (It's not clear to me why the specific discussion of NTP numbers is > > relevant here, since RD is not NTP.) > > > > Section 9.3 > > > > Should we also include "rt" in the initial entries? I see it is used as > > a query parameter for resource lookup in the examples in Section 6.3. > > > > * indication of whether it can be passed as a query parameter at > > registration of endpoints, as a query parameter in lookups, or be > > expressed as a target attribute, > > > > (Since this text does not clarify about lookup of endpoints vs. > > resources... > > > > Review" as described in [RFC8126]. The evaluation should consider > > formal criteria, duplication of functionality (Is the new entry > > redundant with an existing one?), topical suitability (E.g. is the > > described property actually a property of the endpoint and not a > > property of a particular resource, in which case it should go into > > the payload of the registration and need not be registered?), and the > > > > .... and this text suggests that query parameters for *resource* lookups > > need not be registered.) > > > > potential for conflict with commonly used target attributes (For > > example, "if" could be used as a parameter for conditional > > registration if it were not to be used in lookup or attributes, but > > would make a bad parameter for lookup, because a resource lookup with > > an "if" query parameter could ambiguously filter by the registered > > endpoint property or the [RFC6690] target attribute). > > > > Then why do we use it as an example of lookup filtering in Section 6.2? > > > > Section 10.1.2 > > > > Should we really be using unregistered resource types (i.e., codepoint > > squatting) in the examples? > > > > After the filling of the RD by the CT, the application in the > > luminaries can learn to which groups they belong, and enable their > > interface for the multicast address. > > > > Just to check: the luminaries are learning their own group membership by > > querying the resource directory? > > > > Section 10.2.2 > > > > Please expand MSISDN. > > > > Section 13.2 > > > > I think RFC 7252 should probably be normative. > > > > Likewise for RFC 8288 ("the query parameter MUST be [...] a token as > > used in [RFC8288]"). > > > > > > > > --0000000000006b9df605b0b93001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors and WGCs,
We have fou= r DISCUSS ballots on this and a number of other IESG comments, and I haven= =E2=80=99t seen responses to the ADs.=C2=A0 When can we get some engagement= on these issues?

Barry

On Thu, Aug 13, 2020 at 4:12 AM Benjamin Kaduk via Datatrac= ker <noreply@ietf.= org> wrote:
Benjamin Kaduk h= as entered the following ballot position for

draft-ietf-core-resourc= e-directory-25: Discuss



When responding, please keep the sub= ject line intact and reply to all

email addresses included in the To= and CC lines. (Feel free to cut this

introductory paragraph, howeve= r.)





Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html

for mo= re information about IESG DISCUSS and COMMENT positions.




The document, along with other ballot positions, can be found here:
https://datatracker.ietf.or= g/doc/draft-ietf-core-resource-directory/






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

------------------------------------------------------= ----------------



I agree with Roman that the authorization m= odel seems under-developed.

While I recognize that there is need for= flexibility across various

deployments, I think that we should be p= roviding a default model (and

procedures for it) that will apply in = many cases, and let

deployments specify alternate models if needed.= =C2=A0 This stuff is hard

enough to get right that we should have a = secure option that people can

use if they don't need to have cus= tomized details.=C2=A0 (To be clear, I

agree with the change of focu= s from -24 to -25 on the properties that a

security policy needs to = provide and/or consider, as that is

fundamentally the important thin= g.=C2=A0 I just want a fallback/default

option that "does somet= hing reasonable in most cases" in addition.

Doing that by refer= ence to some other existing thing would be fine, if

such a thing exi= sts.)



In particular, the current text seems to rely on the a= uthorization

model including:



(1) the RD knowing how = clients will be using it (and thus what

properties the RD needs to e= nforce), which in the general case cannot be

known (though for stati= c networks it could be), yet I don't see any

discussion that ind= icates this as a prerequisite; and



(2) the client either kno= wing out-of-band that an entity is authorized

to act as a RD or just= blindly trusting any of the unauthenticated (*)

advertisement mecha= nisms.=C2=A0 (* Yes, there may be some protection in the

network on = subscribing to the relevant multicast address, DNS-SD, etc.,

but the= client cannot a priori know that such protections are in place.)


Relatedly, the naming model and naming authority should have some
=
clearer discussion.=C2=A0 We do mention in Section 7 the possibility fo= r a

weak naming model where the RD is responsible for enforcing uniq= ueness

of names but otherwise link attributes are the primary author= ization

criteria (vs. a traditional scheme with a naming authority a= nd naming

hierarchy), but with naming as a fundamental prerequisite = of any

authentication/authorization scheme, I think clearer discussi= on of how a

naming model is to be selected (and, perhaps more import= antly, that it

must be fixed as part of a given deployment) for a gi= ven network is

needed.



If I understand correctly, we = have some codepoint squatting going on in

the examples (e.g., for re= source types).



We should talk about the security properties = of the various RD discovery

mechanisms that are defined.


=


---------------------------------------------------------------= -------

COMMENT:

--------------------------------------------= --------------------------



My apologies for where these comm= ents diverge off into rambling

incoherency, or where I'm misunde= rstanding something that's clearly laid

out; this document had t= he misfortune of being the last one I got to

this week.


<= br>Section 1



=C2=A0 =C2=A0[RFC6690] only describes how to di= scover resources from the web

=C2=A0 =C2=A0server that hosts them by= querying "/.well-known/core".=C2=A0 In many

=C2=A0 =C2=A0= constrained scenarios, direct discovery of resources is not practical
=C2=A0 =C2=A0due to sleeping nodes, disperse networks, or networks where = multicast

=C2=A0 =C2=A0traffic is inefficient.=C2=A0 These problems = can be solved by employing an

=C2=A0 =C2=A0entity called a Resource = Directory (RD), which contains information

=C2=A0 =C2=A0about resour= ces held on other servers, allowing lookups to be

=C2=A0 =C2=A0perfo= rmed for those resources.



nit(?): I'd consider specifyin= g that the RD is "a trusted entity".

(Even when the resour= ces themselves are authenticated, a hostile RD can

still deny existe= nce of a given resource, so by choosing to use an RD

there is some l= evel of trust involved.)



Section 2



=C2=A0 =C2= =A0Resource Directory (RD)

=C2=A0 =C2=A0 =C2=A0 A web entity that st= ores information about web resources and

=C2=A0 =C2=A0 =C2=A0 implem= ents the REST interfaces defined in this specification for

=C2=A0 = =C2=A0 =C2=A0 discovery, for the creation, the maintenance and the removal = of

=C2=A0 =C2=A0 =C2=A0 registrations, and for lookup of the registe= red resources.



nit: the list structure is not parallel here.= =C2=A0 Maybe "for discovery,

creation, maintenance, and removal= of registrations, and for lookup of

the registered resources"?=



=C2=A0 =C2=A0Commissioning Tool

=C2=A0 =C2=A0 =C2=A0= Commissioning Tool (CT) is a device that assists during the

=C2=A0 = =C2=A0 =C2=A0 installation of the network by assigning values to parameters= ,

=C2=A0 =C2=A0 =C2=A0 naming endpoints and groups, or adapting the = installation to the

=C2=A0 =C2=A0 =C2=A0 needs of the applications.<= br>


Is "the installation of the network" a one-time ev= ent?=C2=A0 =C2=A0(Might a CT be

involved when adding a new device to= a network at a later time?)



Section 3.1



=C2= =A0 =C2=A0Information SHOULD only be stored in the RD if it can be obtained= by

=C2=A0 =C2=A0querying the described device's /.well-known/co= re resource directly.



When might that not be the case?


Section 3.2



=C2=A0 =C2=A0The RD architecture is il= lustrated in Figure 1.=C2=A0 An RD is used as a

=C2=A0 =C2=A0reposit= ory of registrations describing resources hosted on other web

=C2=A0= =C2=A0servers, also called endpoints (EP).=C2=A0 An endpoint is a web serv= er

=C2=A0 =C2=A0associated with a scheme, IP address and port.=C2=A0= A physical node may



(side note) hmm, I feel like in the HTT= P world an endpoint is more

likely to be associated with a DNS name = than an IP address, in common

usage.=C2=A0 Also, we later go on to a= ssert that the endpoint's name has

primacy and that the IP addre= ss/port can be ephemeral.



=C2=A0 =C2=A0An endpoint uses spec= ific interfaces to register, update and remove a

=C2=A0 =C2=A0regist= ration.=C2=A0 It is also possible for an RD to fetch Web Links from

= =C2=A0 =C2=A0endpoints and add their contents to its registrations.

=

=C2=A0 =C2=A0At the first registration of an endpoint, a "regi= stration resource"

=C2=A0 =C2=A0is created, the location of whi= ch is returned to the registering

=C2=A0 =C2=A0endpoint.=C2=A0 The r= egistering endpoint uses this registration resource

=C2=A0 =C2=A0to = manage the contents of registrations.



Does the "RD fetc= hes links unilaterally" case count as a "first

registratio= n of an endpoint"?=C2=A0 I'm having a hard time seeing how these
two statements are consistent with each other, and a naive reading
admits the possibility that a given endpoint could be "locked out= " of

the ability to manage the contents of its registrations.


Section 4



=C2=A0 =C2=A0REST clients (registran= t-EPs and CTs during registration and

=C2=A0 =C2=A0maintenance, look= up clients, RD servers during simple registrations)

=C2=A0 =C2=A0MUS= T be prepared to receive any unsuccessful code and act upon it

=C2= =A0 =C2=A0according to its definition, options and/or payload to the best o= f

=C2=A0 =C2=A0their capabilities, falling back to failing the opera= tion if recovery

=C2=A0 =C2=A0is not possible.=C2=A0 In particular, = they should retry the request upon



"MUST be prepared [.= ..] to the best of their abilities" seems

non-actionable.=C2=A0= The stuff after "In particular", on the other hand, is

ac= tual concrete guidance that could be mandated using normative

langua= ge.



Section 4.1



=C2=A0 =C2=A01.=C2=A0 In a 6L= oWPAN, just assume the Border Router (6LBR) can act as an

=C2=A0 =C2= =A0 =C2=A0 =C2=A0RD (using the ABRO option to find that [RFC6775]).=C2=A0 C= onfirmation

=C2=A0 =C2=A0 =C2=A0 =C2=A0can be obtained by sending a = Unicast to "coap://[6LBR]/.well-

=C2=A0 =C2=A0 =C2=A0 =C2=A0kno= wn/core?rt=3Dcore.rd*".



nit(?): I was unaware that &quo= t;Unicast" was a proper noun.



Section 4.3


=C2=A0 =C2=A0"core.rd" in the query string.=C2=A0 Likewise, a R= esource Type parameter

=C2=A0 =C2=A0value of "core.rd-lookup*&q= uot; is used to discover the URIs for RD Lookup

=C2=A0 =C2=A0operati= ons, core.rd* is used to discover all URI paths for RD

=C2=A0 =C2=A0= operations.=C2=A0 [...]



Is the distinction between URIs (for= RD Lookup) and URI paths (for RD)

important here?



= =C2=A0 =C2=A0While the link targets in this discovery step are often expres= sed in

=C2=A0 =C2=A0path-absolute form, this is not a requirement.= =C2=A0 Clients of the RD

=C2=A0 =C2=A0SHOULD therefore accept URIs o= f all schemes they support, both as

=C2=A0 =C2=A0URIs and relative r= eferences, and not limit the set of discovered

=C2=A0 =C2=A0URIs to = those hosted at the address used for URI discovery.



I'm = not sure I see how the "not limit [...] to those hosted at the

= address used for URI discovery" follows from the non-requirement for
expression of the link-targets from discovery in path-absolute form.<= br>
(Given the ability to send the discovery query to a multicast addres= s,

the guidance seems okay; it's just the "therefore" = that is puzzling me.)



=C2=A0 =C2=A0It would typically be sto= red in an implementation information link

=C2=A0 =C2=A0(as described= in [I-D.bormann-t2trg-rel-impl]):



=C2=A0 =C2=A0Req: GET /.w= ell-known/core?rel=3Dimpl-info



This seems to be depicting a = link-relation type that is not registered

at https://www.iana.org/assignments/link-relations/link-re= lations.xhtml

, i.e., codepoint squatting.=C2=A0 Please put in a= stronger disclaimer that

this is an example link relation type, not= just an example exchange.



Section 5



These fi= rst few paragraphs give the impression that this is

first-come-first= -served with minimal authentication or authorization

checking.=C2=A0= Mentioning that there are authorization checks, with a

forward-refe= rence, might be helpful.



=C2=A0 =C2=A0further parameters (se= e Section 9.3).=C2=A0 The RD then creates a new

=C2=A0 =C2=A0registr= ation resource in the RD and returns its location.=C2=A0 The


Is this returned "registration resource" expected to function as= a

"capability URL" (https://www.w3.org/TR/ca= pability-urls/) that would

need to contain an appropriate amount= of entropy to be reasonably

unguessable by parties other than the r= egistrant-ep/CT responsible for

it?



=C2=A0 =C2=A0The = registration request interface is specified as follows:



=C2= =A0 =C2=A0Interaction:=C2=A0 EP -> RD



I thought that the = CT could be a requestor as well as the EP.



=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0well.=C2=A0 The endpoint name and sector name are not set = when one

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or both are set in an acc= ompanying authorization token.



What should the RD do if they= are set but also present in the

accompanying authorization token?


=C2=A0 =C2=A0Req: POST coap://rd.example.com/rd?ep= =3Dnode1

=C2=A0 =C2=A0Content-Format: 40

=C2=A0 =C2=A0Pay= load:

=C2=A0 =C2=A0</sensors/temp>;ct=3D41;rt=3D"temperat= ure-c";if=3D"sensor",



(side note) XML for the= sensors, not SenML?=C2=A0 With Carsten as an author,

even? ;)


=C2=A0 =C2=A0An RD may optionally support HTTP.=C2=A0 Here is an = example of almost the

=C2=A0 =C2=A0same registration operation above= , when done using HTTP.



=C2=A0 =C2=A0Req:

=C2=A0 =C2= =A0POST /rd?ep=3Dnode1&base=3Dhttp://[2001:db8:1::1] HTTP/1.1

= =C2=A0 =C2=A0Host: example.com



Wouldn't "Host: rd.example.= com" be closer to "almost the same

registration"?=



Section 5.1



I'm a little uneasy about sp= ecifying new behavior for POST to the

existin /.well-known/core that= was defined by RFC 6690 for other uses.

What factors go into using = the same well-known URI vs. defining a new

one for this usage?


=C2=A0 =C2=A0The sequence of fetching the registration content be= fore sending a

=C2=A0 =C2=A0successful response was chosen to make r= esponses reliable, and the

=C2=A0 =C2=A0caching item was chosen to s= till allow very constrained registrants.



I'm not sure wh= at "the caching item" is supposed to be (if it's not a
typo/misordering of words).



Section 5.3



=C2= =A0 =C2=A0queries concerning this endpoint.=C2=A0 The RD SHOULD continue to= provide

=C2=A0 =C2=A0access to the Registration Resource after a re= gistration time-out

=C2=A0 =C2=A0occurs in order to enable the regis= tering endpoint to eventually

=C2=A0 =C2=A0refresh the registration.= =C2=A0 The RD MAY eventually remove the

=C2=A0 =C2=A0registration re= source for the purpose of garbage collection.=C2=A0 If the

=C2=A0 = =C2=A0Registration Resource is removed, the corresponding endpoint will
=
=C2=A0 =C2=A0need to be re-registered.



(This MAY is actu= ally a MUST for the simple registration case, per =C2=A75.1,

right?)=



Section 5.3.1



=C2=A0 =C2=A0An update MAY upd= ate the lifetime or the base URI registration

=C2=A0 =C2=A0parameter= s "lt", "base" as in Section 5.=C2=A0 Parameters that a= re not



What about the "extra-attrs"; are they inhe= rently forbidden from

updates?



=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 base :=3D=C2=A0 Base URI (optional).=C2=A0 This

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0parameter updates the Base URI established in the origi= nal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registration to a new value.= =C2=A0 If the parameter is set in an

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0update, it is stored by the RD as the new Base URI under which

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to interpret the relative links present i= n the payload of the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0original regi= stration, following the same restrictions as in

=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0the registration.=C2=A0 If the parameter is not set in the re= quest



nit: is it the interpretation of relative links that i= s following the

same restrictions as in the registration, or the new= value of the

parameter being supplied in the update?


=C2=A0 =C2=A0The following example shows how the registering endpoint upda= tes its

=C2=A0 =C2=A0registration resource at an RD using this inter= face with the example

=C2=A0 =C2=A0location value: /rd/4521.

=

The path component "4521" contains a worryingly small amo= unt of

unpredictableness; I would prefer examples that used longer r= andom

locations, as for capability URLs.=C2=A0 (Throughout the docum= ent, of

course.)=C2=A0 See also draft-gont-numeric-ids-sec-considera= tions, that I'm

AD sponsoring, though I do not see any clear iss= ues on first glance.



(Also, it might be worth another senten= ce that this update is serving

just to reset the lifetime, making no= other changes, since this might be

expected to be a common usage.)<= br>


Section 6



With "Resource Lookup" an= d "Endpoint Lookup" as (apparent) top-level

siblings, woul= d it make sense to put 6.2, or at least 6.3, as

subsections under 6.= 1?



Section 6.1



=C2=A0 =C2=A0Resource lookup r= esults in links that are semantically equivalent to

=C2=A0 =C2=A0the= links submitted to the RD.=C2=A0 The links and link parameters

=C2= =A0 =C2=A0returned by the lookup are equal to the submitted ones, except th= at

=C2=A0 =C2=A0the target and anchor references are fully resolved.=



Are the "submitted ones" the submissions at regis= tration time, or during

the lookup query itself?=C2=A0 (I assume reg= istration-time, but being

explicit costs little.)



=C2= =A0 =C2=A0If the base URI of a registration contains a link-local address, = the

=C2=A0 =C2=A0RD MUST NOT show its links unless the lookup was ma= de from the same

=C2=A0 =C2=A0link.=C2=A0 The RD MUST NOT include zo= ne identifiers in the resolved URIs.



Same link as what?
<= br>

Section 6.2



=C2=A0 =C2=A0The page and count param= eters are used to obtain lookup results in

=C2=A0 =C2=A0specified in= crements using pagination, where count specifies how many



(W= e haven't introduced the page and count parameters yet.)


=C2=A0 =C2=A0operator as in Section 4.1 of [RFC6690].=C2=A0 Attributes tha= t are defined

=C2=A0 =C2=A0as "link-type" match if the sea= rch value matches any of their values



Where is it specified = how an attribute might be "defined as

'link-type'"= ?=C2=A0 This is the only instance of the string "link-type" in
this document, and it does not appear in RFC 6690 at all...


=C2=A0 =C2=A0references) and are matched against a resolved link targe= t.=C2=A0 Queries

=C2=A0 =C2=A0for endpoints SHOULD be expressed in p= ath-absolute form if possible

=C2=A0 =C2=A0and MUST be expressed in = URI form otherwise; the RD SHOULD recognize

=C2=A0 =C2=A0either.=C2= =A0 The "anchor" attribute is usable for resource lookups, and,
=C2=A0 =C2=A0if queried, MUST be for in URI form as well.


=
I don't see how it can be only a SHOULD to recognize either given t= hese

generation criteria.



Section 6.3



= =C2=A0 =C2=A0The following example shows a client performing a lookup of al= l

=C2=A0 =C2=A0resources of all endpoints of a given endpoint type.= =C2=A0 It assumes that

=C2=A0 =C2=A0two endpoints (with endpoint nam= es "sensor1" and "sensor2") have

=C2=A0 =C2=A0pr= eviously registered with their respective addresses

=C2=A0 =C2=A0&qu= ot;coap://sensor1.example.com" and "coap://sensor2.example= .com", and

=C2=A0 =C2=A0posted the very payload of the 6th = request of section 5 of [RFC6690].



Er, the 6th request is a = GET; do we mean to say the response to the 6th

request?


<= br>Section 6.4



=C2=A0 =C2=A0The endpoint lookup returns regi= stration resources which can only be

=C2=A0 =C2=A0manipulated by the= registering endpoint.



This seems to leave it unclear whethe= r the endpoint lookup is expected

to return resources that the reque= stor will not have permission to

manipulate (in addition to those it= does have permission for).



=C2=A0 =C2=A0While Endpoint Look= up does expose the registration resources, the RD

=C2=A0 =C2=A0does = not need to make them accessible to clients.=C2=A0 Clients SHOULD NOT
=C2=A0 =C2=A0attempt to dereference or manipulate them.



Bu= t why expose them at all if they're not going to be accessible?

=

=C2=A0 =C2=A0An RD can report endpoints in lookup that are not host= ed at the same

=C2=A0 =C2=A0address.=C2=A0 [...]



The = "same address" as what?



Section 7.1


=C2=A0 =C2=A0Whenever an RD needs to provide trustworthy results to client= s doing

=C2=A0 =C2=A0endpoint lookup, or resource lookup with filter= ing on the endpoint



How will the RD know whether the client = is expecting trustworthy

results?=C2=A0 (When would a client *not* e= xpect trustworthy results?)



=C2=A0 =C2=A0name, the RD must e= nsure that the registrant is authorized to use the

=C2=A0 =C2=A0give= n endpoint name.=C2=A0 This applies both to registration and later to
=C2=A0 =C2=A0operations on the registration resource.=C2=A0 It is immater= ial there

=C2=A0 =C2=A0whether the client is the registrant-ep itsel= f or a CT is doing the

=C2=A0 =C2=A0registration: The RD can not tel= l the difference, and CTs may use



I suppose there might be p= lausible authorization models where a

return-routability check to a = given address constitutes authorization to

use that address as an en= dpoint name, in which case the RD can tell the

difference between a = registrant-ep and a CT attempting to act on its

behalf.


<= br>=C2=A0 =C2=A0When certificates are used as authorization credentials, th= e

=C2=A0 =C2=A0sector(s) and endpoint name(s) can be transported in = the subject.=C2=A0 In

=C2=A0 =C2=A0an ACE context, those are typical= ly transported in a scope claim.



As Russ noted in the Gen-AR= T review, "transported in the subject" is

sufficiently vag= ue to not really be actionable.=C2=A0 It might be better to

say that= the holder of the private key corresponding to the public key

certi= fied in the certificate is generally considered authorized to act

on= behalf of any identities (including endpoint names) contained in the
certificate's subject name.



Section 7.1.1


<= br>=C2=A0 =C2=A0Conversely, in applications where the RD does not check the= endpoint

=C2=A0 =C2=A0name, the authorized registering endpoint can= generate a random

=C2=A0 =C2=A0number (or string) that identifies t= he endpoint.=C2=A0 The RD should then



How much entropy/rando= mness in the random name?=C2=A0 Does a CSPRNG need to

be used?=C2=A0= (I do see the follow-up about doubling the length in case of

failur= e or starting with a UUID if that's not possible, but some

guida= nce on where to start still seems appropriate.)



Section 7.2<= br>


=C2=A0 =C2=A0When lookup clients expect that certain types o= f links can only

=C2=A0 =C2=A0originate from certain endpoints, then= the RD needs to apply

=C2=A0 =C2=A0filtering to the links an endpoi= nt may register.



As before, how will the RD know what behavi= or clients are relying on?



=C2=A0 =C2=A0An RD may also requi= re that only links are registered on whose anchor

=C2=A0 =C2=A0(or e= ven target) the RD recognizes as authoritative of.=C2=A0 One way to

=

I don't think I can parse this sentence (especially "the R= D recognizes

as authoritative of").



Section 8


In contexts where we discuss DTLS and TLS as being generally c= omparable,

we typically will state that DTLS replay protection is re= quired in order

to provide equivalent levels of protection.

<= br>
We might also want to reiterate or refer back to the previous discus= sion

of the potential for attributes or resource/endpoint names, lin= k

relations, etc. that may need to be confidential, the relevant acc= ess

control/filtering, and the avenues by which disclosure of resour= ce names

can occur even when access to those resources will not be p= ermitted.=C2=A0 (I

think some of this overlaps with 8288 and 6690, b= ut don't mind repeating

it.)



Section 8.1

<= br>
It's probably worth reiterating that all name comparisons must b= e done

at sector scope (since failing to do so can lead to attacks).=



=C2=A0 =C2=A0Endpoint authentication needs to be checked in= dependently of whether

=C2=A0 =C2=A0there are configured requirement= s on the credentials for a given

=C2=A0 =C2=A0endpoint name (Section= 7.1) or whether arbitrary names are accepted

=C2=A0 =C2=A0(Section = 7.1.1).



I think this is more properly authorization than aut= hentication.



Section 8.3



=C2=A0 =C2=A0attacks= .=C2=A0 There is also a danger that NTP Servers could become

=C2=A0 = =C2=A0implicated in denial-of-service (DoS) attacks since they run on
=C2=A0 =C2=A0unprotected UDP, there is no return routability check, and t= hey can

=C2=A0 =C2=A0have a large amplification factor.=C2=A0 The re= sponses from the NTP server

=C2=A0 =C2=A0were found to be 19 times l= arger than the request.=C2=A0 An RD which



(It's not clea= r to me why the specific discussion of NTP numbers is

relevant here,= since RD is not NTP.)



Section 9.3



Should we = also include "rt" in the initial entries?=C2=A0 I see it is used = as

a query parameter for resource lookup in the examples in Section = 6.3.



=C2=A0 =C2=A0*=C2=A0 indication of whether it can be pa= ssed as a query parameter at

=C2=A0 =C2=A0 =C2=A0 registration of en= dpoints, as a query parameter in lookups, or be

=C2=A0 =C2=A0 =C2=A0= expressed as a target attribute,



(Since this text does not = clarify about lookup of endpoints vs.

resources...



= =C2=A0 =C2=A0Review" as described in [RFC8126].=C2=A0 The evaluation s= hould consider

=C2=A0 =C2=A0formal criteria, duplication of function= ality (Is the new entry

=C2=A0 =C2=A0redundant with an existing one?= ), topical suitability (E.g. is the

=C2=A0 =C2=A0described property = actually a property of the endpoint and not a

=C2=A0 =C2=A0property = of a particular resource, in which case it should go into

=C2=A0 =C2= =A0the payload of the registration and need not be registered?), and the


.... and this text suggests that query parameters for *resourc= e* lookups

need not be registered.)



=C2=A0 =C2=A0pote= ntial for conflict with commonly used target attributes (For

=C2=A0 = =C2=A0example, "if" could be used as a parameter for conditional<= br>
=C2=A0 =C2=A0registration if it were not to be used in lookup or att= ributes, but

=C2=A0 =C2=A0would make a bad parameter for lookup, bec= ause a resource lookup with

=C2=A0 =C2=A0an "if" query par= ameter could ambiguously filter by the registered

=C2=A0 =C2=A0endpo= int property or the [RFC6690] target attribute).



Then why do= we use it as an example of lookup filtering in Section 6.2?


Section 10.1.2



Should we really be using unregistered resou= rce types (i.e., codepoint

squatting) in the examples?


=C2=A0 =C2=A0After the filling of the RD by the CT, the application in th= e

=C2=A0 =C2=A0luminaries can learn to which groups they belong, and= enable their

=C2=A0 =C2=A0interface for the multicast address.
<= br>

Just to check: the luminaries are learning their own group membe= rship by

querying the resource directory?



Section 10.= 2.2



Please expand MSISDN.



Section 13.2


I think RFC 7252 should probably be normative.



Like= wise for RFC 8288 ("the query parameter MUST be [...] a token as
used in [RFC8288]").









--0000000000006b9df605b0b93001-- From nobody Sat Oct 3 02:24: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 359213A0954; Sat, 3 Oct 2020 02:24:42 -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 k6ueB-uIlnvi; Sat, 3 Oct 2020 02:24:39 -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 C31D83A0953; Sat, 3 Oct 2020 02:24:36 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0735140810; Sat, 3 Oct 2020 11:24:33 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F364174; Sat, 3 Oct 2020 11:24:31 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:5432:1f22:b46:4d37]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A5F6E121; Sat, 3 Oct 2020 11:24:31 +0200 (CEST) Received: (nullmailer pid 1553469 invoked by uid 1000); Sat, 03 Oct 2020 09:24:31 -0000 Date: Sat, 3 Oct 2020 11:24:31 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Barry Leiba Cc: Benjamin Kaduk , The IESG , core@ietf.org, core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com Message-ID: <20201003092431.GE1315898@hephaistos.amsuess.com> References: <159730632066.12379.5174560093789503034@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/unnNtmY43mpUSKx" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 03 Oct 2020 09:24:42 -0000 --/unnNtmY43mpUSKx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Barry, > We have four DISCUSS ballots on this and a number of other IESG comments, > and I haven=E2=80=99t seen responses to the ADs. When can we get some en= gagement > on these issues? we've come to rough agreement on how to respond to the harder points on an interim meeting, and will go through the worked-out version for the next document revision on the next one (scheduled for 2020-10-08). I expect to submit an updated version together with point-to-point responses on the weekend following that. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --/unnNtmY43mpUSKx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl94Q08ACgkQOY0REtOk veEn6RAAr6p1eqppyACsOqS5PPg4o08U5s4CbBWEtaklf/SIAIG10mUVrucrnw3Y Vv/ebS9/hWQ9GvBSzsJqyQhNz86JvaC2Qovou5Bei0KYvU4+Lthr4p7Et33Ogmt1 b9QYWNyZzWFYRhz0UFu83AZ+GctHdQ4w8hRpDe0rd5nLCndLvhk0sOsoAenzoKe/ RqrgUwwUEV5RcaMRiISNkiLeogUftqT20n99ECPKSdawOQpO+e6UbY67+TtVATCJ iWyrITw1/1tfwD4rPcEbYw/IFPBV5V1e9H1dBYchR/oHCcl/7diSOTBlhNLTmbyI DhQgBX7rCjQXh+LznlxdS2gUe+FbI8HBrVJUdh7WMAFb+cidX7ZBNsyiSdL774PQ CqxDQy1vw87DGm9MdPK1cuJ6kezvMFJbRerRDDxUpK307T02WkIrDAQiHHwK4p9x ox54EqQiHGjts8HdPqJUrEpIJEXV3gFsGExPGk3QWWI9q28vAIeXteudLF7vtieQ jKrNdr1r0Kc00uwhthe+Z4/sSLeyKinfF3S4qJWoS8B9I5NHFP8bAfOrkJBs3GdM T93KcapDAeJT95sW2WZJBGUwxkWvor0q2FBgpKf49a0K3FKa+4G/qjeB+2bAV3OC OdH86DP8vtpEPHtNy9JiJMsZZ2W+He5SlHfUzG0UnikCTFKx6H0= =/Fzv -----END PGP SIGNATURE----- --/unnNtmY43mpUSKx-- From nobody Mon Oct 5 01:12: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 18B963A0E26 for ; Mon, 5 Oct 2020 01:12:20 -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 qj6kIqrcswrr for ; Mon, 5 Oct 2020 01:12:16 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (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 80EF53A0E25 for ; Mon, 5 Oct 2020 01:12:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GihNpTWjEQRij0I4oRQHZncF3eK484MDNuQTcCE/sz6p0obf8MjVhH2kApfg/51Adm008aho0K7RCZF2xus3102DI0HLjCNxhh5jOy8GAq+ntC8W6vntcgMWvdmU6A6Y9flOvIVjedcR4tl4Nwb3GSgSnKdqz8U76REIAZEyaVIPepFrANerVOfUEIS6aFpkOUJQsirowTkZkajbRizeYBiJ/QrV/IcpAMCs7InLLumjy986P5FwuFDO5WNM8mvJwBf9P8OqjflMM0u1ABn6p0hKtYG13YN+KXwshI6LpVOO99Rjn9hjaPalFHcRk5ZNTjaF5V/bTZ7Z+lKNJg9DKA== 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=0r0NiM1TjV4w57+Xi102y9+VlB+BFdh1neuP+k/ZCUQ=; b=Sfjz/eKMgW11LgQBAmRJ8yjJkWyaMpijLBmFH/eGr62EIuu56ixarI7Y9bT1Se1alXzMF8pH8po0NCZ/REzQ2nAYH0h2r12FV24WifpUZIm1W4PN2WoAAwulBH9UWNGeoI5oqd3iQzuuKfhlzq0ogLQFDdob6wquU3HkMtdJqqtMdxfkd1ww6pKrk84Jgzmo172AQeQ6afVotyNdPdt4ocCZTe6I+LdCmkXypoKLa1EMoK4dTTMPy3XkyI5dTH+TLTZQXvxMUI4QNq8fLX01SjACzvAa5CH1qM+BG4u8bp4dV/iCsm5s2uYirom/x1+EiFEmeagSjDrtaBCGdIxR8Q== 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=0r0NiM1TjV4w57+Xi102y9+VlB+BFdh1neuP+k/ZCUQ=; b=clRVti1qYZZyRMC1zyWeh3GD0Y1NCS2enslAZi5g6gal/rQNrWGmyFNUuJ47QqMGtixESMgX080VMwGOi309GrAHNRaot9NTfRGuYH9BfQl9OI7XzVElScNXt5bTYdpLg+6wrPA8Nmp+q3zROjtHIo8lH7fc8cMMo+is/2I0KIo= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0840.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.35; Mon, 5 Oct 2020 08:12:13 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%9]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 08:12:13 +0000 References: <8F00E4E0-29F4-4C5E-8293-D7AB5F16E2FA@ietf.org> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <8F00E4E0-29F4-4C5E-8293-D7AB5F16E2FA@ietf.org> Message-ID: <52cdc2b5-f743-8148-de27-2dc4d7c78666@ri.se> Date: Mon, 5 Oct 2020 10:12:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <8F00E4E0-29F4-4C5E-8293-D7AB5F16E2FA@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UHyBxWSVQkiWhVFEMqHbNWUy9pHr1A8fG" X-Originating-IP: [185.236.42.17] X-ClientProxiedBy: HE1PR05CA0203.eurprd05.prod.outlook.com (2603:10a6:3:f9::27) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.8] (185.236.42.17) by HE1PR05CA0203.eurprd05.prod.outlook.com (2603:10a6:3:f9::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.35 via Frontend Transport; Mon, 5 Oct 2020 08:12:12 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 435344ca-6c1c-43af-01d9-08d869065d25 X-MS-TrafficTypeDiagnostic: DB8P189MB0840: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3173; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3/kqLzGRlf2sVMJoXs+KwypssbpOyszbMQ0YpdFv2vtPixVUCD4pzPt5oYmYQFBKojJ+97TPtnQeWF3AWV8Hn1ZKwzFcR38F2uj54AMW76W2ubqR7jANscb83RdiG9bQUiZHPu1lsTtiZ5fKwLD3NfhcbeS7Ps7gzNaG2LV0PPXG+i5HgJfAr6RopCf0lDXQMgsX7REm/SIVtRTMWQokwTsHLRohRx0i5Cy5kp/1ZMz8aYMJnRsuRY2uK8QFPtr4RJ1mSmhicnShAF3+FF9dOGNP4rkf5Gqfx/cvf4Zr7uqcIfoO0+5zfXHX/Q7aoSwqTiNp2Jzxu+gTMk5cUjteGhw87/3yACOKqvc2vPKvei6AKMGuwZcH/QTmZoVUQkqq X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(39850400004)(396003)(136003)(6666004)(8936002)(316002)(16576012)(31696002)(478600001)(86362001)(83380400001)(8676002)(31686004)(956004)(52116002)(66476007)(2616005)(2906002)(26005)(66556008)(21480400003)(6916009)(186003)(36756003)(16526019)(44832011)(6486002)(5660300002)(235185007)(66946007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: +cstvGT9D5x6LcsCknPJC4MbGCCr0wiU5UiOrpolTHuqG22oI3i1TJjLmRcLaTMN54guHlSxTZTNprmoIbxS6u19PVbk7/roj/BPKN0WcGbWSPzJ5/EnSEjOkyi7Mbbvhi/sPclbBzzCEFtjTxIN5335xLEXLiCpu0JliIiMExaUJHTMyF1UZfQx4oGCsxzgy6WJz/chL8vpw5Fl+pk0bKF6zPbm46NNZFaKChvYJgREB0KVKtBLi+9PAkNkUdvPDmKlak/E6YHNaF1suKx4DE/5lZHogv6ezIERRod3WDFYHCm/JGUpsJHN6FzCae8oK9THLWRAAx9R9849NhVQOcP8zutalHM/bqrU5ITQb4ah8IiW7GvY64YCbEQUts/a2Mstmn94s8mBlVgQUn2jUKvwbZoh0pO8Q13RfLCnRdiLrfaZ/IBIz9ct+XNkzLh/evj6am3VpoK7QbbVJYLJVxE9jGoIRrgtrD7AoxdW1TgpgNDA8o8ZGDe9bQrL+blCo2Rqfll1ve9QwGP2aBYn/yeLu5QNwwZkABgUJuBBETUhlyhmcpjBNVw8UiSRw/CJCOg+c4hhW1RExZiGG/RYcTgqpLGffVb99qKmoMog5bmYEMAMbXtQ5yJcS/RhQYE7ivtZEdWbJGobFYqRvU0vAQ== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 435344ca-6c1c-43af-01d9-08d869065d25 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2020 08:12:13.0334 (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: iITSzSw+7+4vZ4RkC5T6ccA6D9YBM2HFLJZoXmnF2RVfOVg8tHehOvwUgYmIwoTgqdUMF5jkOve9hc5klZxPzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0840 Archived-At: Subject: [core] Fwd: Fwd: Jim Schaad 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, 05 Oct 2020 08:12:20 -0000 --UHyBxWSVQkiWhVFEMqHbNWUy9pHr1A8fG Content-Type: multipart/mixed; boundary="sbatWFUjd0SaySH6cx6cyMmgTqUdAur5n" --sbatWFUjd0SaySH6cx6cyMmgTqUdAur5n Content-Type: multipart/alternative; boundary="------------D384E682A712DE7256A55055" Content-Language: en-US This is a multi-part message in MIME format. --------------D384E682A712DE7256A55055 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Very sad news. Best, Marco and Jaime -------- Forwarded Message -------- Subject: Fwd: Jim Schaad Date: Mon, 5 Oct 2020 09:18:54 +1300 From: Jay Daley To: IESG , IETF WG Chairs I have some sad news to pass on. =A0I have let his co-chairs in ace and cbor know directly. > Begin forwarded message: > > *From: *> > *Subject: **Jim Schaad* > *Date: *4 October 2020 at 8:51:43 AM NZDT > *To: *> > > I am not sure whom to contact.=A0 My brother, Jim Schaad, was an active= > member of the IETF.=A0 I need to let the groups he was working with tha= t > he has died. =A0 > =A0 > =A0 > Tom Schaad > August Cellars > Newberg, OR, USA > tom@augustcellars.com > 503.554.6766 x102 desk > 503.789.7404 cell --=A0 Jay Daley IETF Executive Director jay@ietf.org --------------D384E682A712DE7256A55055 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Very sad news.

Best,
Marco and Jaime


-------- Forwarded Message --------
Sub= ject: Fwd: Jim Schaad
Dat= e: Mon, 5 Oct 2020 09:18:54 +1300
Fro= m: Jay Daley <jay@ietf.org>
To:= IESG <iesg@ietf.org>, IETF WG Chairs <wgchairs@ietf.org>


I have some sad news to pass on. =A0I have let his co-chairs in ace and cbor know directly.

Begin forwarded message:

From: <tom@augustcellars.com>
Subject: Jim Schaad
Date: 4 October 2020 at 8:51:43 AM NZDT
To: <exec-director@ietf.org>

I am not sure whom to contact.=A0 My brother, Jim Schaad, was an active member of the IETF.=A0 I need to let the groups he was working with that he has died. =A0
=A0
=A0
Tom Schaad
August Cellars
Newberg, OR, USA
tom@augustcellars.com
503.554.6766 x102 desk
503.789.7404 cell

--=A0
Jay Daley
IETF Executive Director
jay@ietf.org

--------------D384E682A712DE7256A55055-- --sbatWFUjd0SaySH6cx6cyMmgTqUdAur5n-- --UHyBxWSVQkiWhVFEMqHbNWUy9pHr1A8fG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl961VoACgkQ7iZktA5Y 2kO6YggAsJFsTaR74RBj+te8yTTsgYDpoOE1yM3UaJS9QDRU15FC+Zx9a/OVU4ds mKqSMhvQGFxBVts41UkrOKVtT1elawmB1T7aotG4ugnqLdyQRMsTPuI5zz5PdORH xkMQYI6e8MZvztPt6cDD0SfXBKiT5xMm2lJf9COZf+6RvBTax1OQ+J7PDmSPP5vI UuGYqJkovz/4MHdqZFb57QyihAa1MxCjlSeCaUhm5wmFpEvdvDO4EwCvf65Y7UBJ +/o4MensVHxTvyunKJkTt7P81axxaNw7+kaHQo/WXiV+jstnhDSLnWbc0yiIA9jz S/B19c9Cb42YrvmEN5yqcFN6JiCmKw== =Avnm -----END PGP SIGNATURE----- --UHyBxWSVQkiWhVFEMqHbNWUy9pHr1A8fG-- From nobody Tue Oct 6 08:26: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 1895D3A0B29 for ; Tue, 6 Oct 2020 08:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP5sW-2JDtZo for ; Tue, 6 Oct 2020 08:26:56 -0700 (PDT) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFEB3A0B21 for ; Tue, 6 Oct 2020 08:26:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 3EA9CA42; Tue, 6 Oct 2020 11:26:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 06 Oct 2020 11:26:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XsrpNh dZiPrv1MOyJkvCw5Ea/gtPBMNlc03h9NoZ5EQ=; b=rp67btJqyFBkxNFvRp/3ip +WiqiRovZ+7ZVLgfVvmh0CI7mL6E+OEeTZKFp0qsI6C42kbiAwypiSF4VlfEXmBr RxkOJDt4uOK/qEsyHs+NrKxSryQT+8HexEXtnwpaGGxnGOFQT6+TfDoWuweu0inT F8/mVNJCj9M5KvhzCn4G5SE0BoAutvYk3OvN7EG5Z8Hy0ZUmsS3Mfo2sxeBwDIPk PimGzHiE79d8be600sSLe9syaT6ovNJk2T/OgnlX6GUtgvRh5bKtkWJLebJ51ZTc uUE8oqtB8sMXHNrvoAJzrQ28IV0zAzUSn51dxLd88OOanCgRBiokhBV5Mfi+C8Vg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeeggdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtjeenucfhrhhomheplfgrihhmvgcu lfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnhepfe fhhfefgeffvedvudeuvedvfeelieelheeiheehgeekheehlefhtdduffdthfejnecuffho mhgrihhnpehgihhthhhusgdrtghomhdpshgrnhguvghlmhgrnhdrtggrpdhivghtfhdroh hrghenucfkphepkeejrdelfedrvdehrdefheenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: from EMB-918HFH01 (87-93-25-35.bb.dnainternet.fi [87.93.25.35]) by mail.messagingengine.com (Postfix) with ESMTPA id 290393280060; Tue, 6 Oct 2020 11:26:53 -0400 (EDT) Date: Tue, 6 Oct 2020 18:26:51 +0300 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Michael Richardson Cc: Carsten Bormann , core@ietf.org Message-ID: <20201006152651.cmlnyp5bspj6rdzw@EMB-918HFH01> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> <29736.1601491640@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <29736.1601491640@localhost> Archived-At: Subject: Re: [core] issues for stateless AD review 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, 06 Oct 2020 15:26:58 -0000 Hi Michael, I am curious, what was the issue with pip and xml2rfc Ciao! -- Jaime On 30.09.2020 14:47, Michael Richardson wrote: >Carsten Bormann wrote: > > We should replace confusing I-D text here: > > > #8 use automated key management due to AES-CCM/BCP107 > > https://github.com/core-wg/stateless/issues/8 > >I have created pull request #11 for this. >Please comment > > > I think we can simply explain a wontfix on: > > > #3 is stateless updating 7252 on distinguishing unrecognized vs invalid > > extension? https://github.com/core-wg/stateless/issues/3 > > > #4 how does freshness window of client/intermediate interact? > > https://github.com/core-wg/stateless/issues/4 > > > #6 can larger tokens fill responder memory? > > https://github.com/core-wg/stateless/issues/6 > > > #7 how to size the replay window? > > https://github.com/core-wg/stateless/issues/7 > > > #9 look ma, no state! https://github.com/core-wg/stateless/issues/9 > >-- >] Never tell me the odds! | ipv6 mesh networks [ >] Michael Richardson, Sandelman Software Works | IoT architect [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From nobody Tue Oct 6 10:32:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A03A0E2D for ; Tue, 6 Oct 2020 10:32:56 -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 vERoWM86CWbX for ; Tue, 6 Oct 2020 10:32:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6403A0976 for ; Tue, 6 Oct 2020 10:32:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F306389D1; Tue, 6 Oct 2020 13:38:13 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vnHXMdgYJfe9; Tue, 6 Oct 2020 13:38:12 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 60237389D0; Tue, 6 Oct 2020 13:38:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 825D3AF9; Tue, 6 Oct 2020 13:32:52 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FJaime=3D20Jim=3DC3=3DA9nez=3F=3D?= cc: Carsten Bormann , core@ietf.org In-Reply-To: <20201006152651.cmlnyp5bspj6rdzw@EMB-918HFH01> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> <29736.1601491640@localhost> <20201006152651.cmlnyp5bspj6rdzw@EMB-918HFH01> 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] issues for stateless AD review 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, 06 Oct 2020 17:32:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jaime Jim=C3=A9nez wrote: > I am curious, what was the issue with pip and xml2rfc AFAIK, xml2rfc really needs python3 now. Putting the following into .travis.yml: +python: + - "3.8" + install: =2D - pip install xml2rfc + - pip3 install xml2rfc Solved the problem, I think. I also bumped the distro to "bionic", but it's not until ubuntu 20 (Foccil?) that python3 is the default. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl98qkQACgkQgItw+93Q 3WUkrAgAqFbyw1ImwyXU44YgSso1nF6mrj4cTC5eAfvdACRARLKrCW5699wnlAHh cbLeOvRBksUDtZ1+pAmYQD8AcvX+bHru+ey0P7aTPr07DbWv9eZXX50m1w1t+5CX 79oudwtZIwl2HZpU+IUVzvZ1OVKWLVNexGYzxlpa+xqc6pKyfP3+44wkJnpKJ8wi MAplg34MO/XzFHJiDrG25c7+Qa5LHhlraa8ZLhmHZVj1GOF3XomhBTLuPzgmu+lH RRT7LriGKPH/MoVT/v/+oA052usUS7ntaijp2m8DFHlvUQ45jD2M9jUEjM11Gpbr rICSZ5UJ9g7JIknYzF6ni2SGCMFTVg== =YTa6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 7 05:45: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 3BF0F3A0B6C for ; Wed, 7 Oct 2020 05:45:46 -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 cEDiACO9fXHR for ; Wed, 7 Oct 2020 05:45:43 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60041.outbound.protection.outlook.com [40.107.6.41]) (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 BEE4F3A0B4E for ; Wed, 7 Oct 2020 05:45:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FrfGe5ubTjRbT8+6smO0r5nlwkls0Ensbf9UGkoam4VD1+VJDz9QgBjyys3WlTUGHVLceMJq8HV64Oa99Tcv3YzOkrkWPSIA8pkpTnbxcfMo6SsmnPWYVu6gXzYdpeLxDPRbOD2tUQp0UHpvQcVhopj1++xo0TSSFigr91ptjdJS+o8JLf6+GnVlgy6Xt0l0lVgKVCfquQdYDcfE2kmJC8igZK3/wwW2Py83hTK3WlbNN0/7nSAmNONGyyhRwbQqo4mD7Y1QScR5ddAh+Uu3IvJDZm2+9JWAzR1VIVhUtvWhk2d6jaZ14n5EgSqTaDQOzdsOMIQqR5qcADed0xbr0g== 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=tfvUySNZ9UiYneEfO3r1mnn8OzAT/j/RgV8JUhY0kzs=; b=Kfhy2RfFBtxyV2QsXQkYdhwnH3RTDjjNVikpbDrpN2LIkTLgyQg7SEdLRLFxX8OEYr0HXRCpGYcd6Vwv+Zo2hlHVaoZh/yZT4l/oS10CdvE7XNAsfwfbbZfZBsA+Knk1DirzhutSTDwpVPC0xFBo/IpQBN4qJSXAzlfwBNq+5jIN1Dq+nzo/jfo8Q7HCHLLpSGDTQaJvehIhOnr45rfld4fhEq9WKN7EFNt81TuG1r8U6b75lAYAcrspal06oCgNbec9x6EUY7DQLiR4zT6KP+ueDaMGblhTY21SrQrrOBuN7zuIL7ARcRRPZTlBb/Pkgg0u1nl14Dh1opsDOxWEEg== 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=tfvUySNZ9UiYneEfO3r1mnn8OzAT/j/RgV8JUhY0kzs=; b=U7e+dXGpNIo4CWQnrzTfWyIOInZzDv3ZK3Q+QyQABnNkWQLav7vqBcRtH8cipL0R66oi7crBa5Tm8PSXo00iYb145kwZf0+wKjZt7Jwf37l6x/bC3FWk3I+yu8P9EMyjaeWNYKJFL694igwgWC5xunT2ZG9cU+HO1G+Z354TSI8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0311.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Wed, 7 Oct 2020 12:45:36 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%9]) with mapi id 15.20.3433.045; Wed, 7 Oct 2020 12:45:36 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <373d83e7-843e-edad-6795-a4c49bd7a146@ri.se> Date: Wed, 7 Oct 2020 14:45:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pxY5HEvNrnnvqEH34zWhgAOiPZdYWFwZX" X-Originating-IP: [84.17.36.146] X-ClientProxiedBy: HE1PR0902CA0037.eurprd09.prod.outlook.com (2603:10a6:7:15::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (84.17.36.146) by HE1PR0902CA0037.eurprd09.prod.outlook.com (2603:10a6:7:15::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22 via Frontend Transport; Wed, 7 Oct 2020 12:45:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dc02d88f-fbd0-478f-6528-08d86abee315 X-MS-TrafficTypeDiagnostic: DB6P189MB0311: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Jw5tWOf1GiEZjec42MBpNvqy2qnIorQN5mtNUghIXjklqSdgyEkmQpHOQBaX7kVTI7x1F7d+pqN7FY0U5TItT25+Gpd1cxqPfB4jbxkcuW9DNZkGJTWMK0aK7E/DA+fI3sBf4AOY03HBzYZi9gq4x4ID1XHTFy0qSH396b0P+T6zi2iK/6DqW/vufAd8ba+3q64DNApedyT7ovFeph7y4h9pyivnA+kY7iurAeOl3Z9/emzcFoHHfi55QXKmVVibqfJVtBMuJlgLjFhYAocRfuBIOfzhedKK0d/vbOQlUvyiwV5vLdBb092bwzqx5rPdokTiq++tw/srRCM+Z9lytyFE66z6ixCL1XNnaf3JCjjl4t1ObciqJyR59dkaDTe/2rLTgjtXwp87VZthAgTIRe4z6sUOU2pKYh/eiYY4WpjRPF8KEuvEivfSWJ5AzwYcshC+l5HmtTaoSrARjiutRQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39850400004)(376002)(346002)(366004)(2616005)(956004)(478600001)(66574015)(83380400001)(6916009)(966005)(52116002)(44832011)(16526019)(186003)(21480400003)(83080400001)(8936002)(6486002)(316002)(16576012)(66476007)(66946007)(66556008)(6666004)(5660300002)(8676002)(31686004)(86362001)(16799955002)(36756003)(31696002)(2906002)(33964004)(26005)(235185007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: jqT11jXcp5p7DPAAWcvVZURtmRlLPXLQ7HyiIOdxCKlcrztdE0RXWyoB4Bp4kvnuOvt6CW/E6/h/rdn2RrnPKWuCfh3pM9xH0peQJegwHSzCEuIozVemMV+O5qGgjMuBfsfuINBShA9jwHg/muE7D3Ww0PO6EvTQXVcHbb70+RUhj+dJj+vhMe+U6jtxMEK0NTOI3rURHK4xJvmOcsT15y5Stit4Rko6I+jwX/9NjEbzGDZT4r667yn1xRivI6PXelhs7hoHz4r2PDvqYcCANJ2AkXIga5BaWnk6LkNKOGNpfrT2zqlUJ11GdGG+SBlIjdzgylJ0rrv4vmk5BPcdaIPN5Pi1L3oMgxemcOa6tFzuSCI5OPqOE0KyrUFoLZ+2I8PS4CpcOXMbF4lQ/G8EqA/JJj/tVBGgEkb09IBpFmzC5Wd1tDv4Fld61ZKVW3Hl8G8mcn6zhWjBte81sUyWs/rqh5IpdcZJYvalGGXj/g3ljXZzjZML1/LbsOJq48VLShyx5F2eg3BV04udLgHyYtPw8W7udZeqe95/hcMJVcC0gDsSh1QHQP4Xc+vu78JvwulNPnWep3iS+NpHMBkoIU19HjeqeXnSxOTWP2icOpb3aTcg0Feq0no85MIy7V7HNNk/bgGAjfalVCJGweGD0A== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: dc02d88f-fbd0-478f-6528-08d86abee315 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2020 12:45:36.1963 (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: 75xcM/MtFs3D/7OtXpu2J7YjCTolPCLfQzSqLeuMAV/dI0U1dd3IvpYM2g44Pt9CKjSGXc9OMD85wkRwDvxmdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0311 Archived-At: Subject: [core] CoRE WG Virtual Interim 2020-10-08 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, 07 Oct 2020 12:45:46 -0000 --pxY5HEvNrnnvqEH34zWhgAOiPZdYWFwZX Content-Type: multipart/mixed; boundary="BHBmPoWA0eqNzurCfxPJhtrA3M2vQs9gR" --BHBmPoWA0eqNzurCfxPJhtrA3M2vQs9gR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that tomorrow (Thursday) at 14:00 UTC we'll have a virtual interim via Webex. The agenda is to check and discuss: - The processing of comments for the Resource Directory document. - The processing of comments for the Stateless document. Please, find below the information to join the meeting. Best, Marco and Jaime =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2020-core-10-core?bo= th Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dmb3ef6f63cca8d4c20803296e5f07702= f Meeting number: 171 836 3130 Password: constrained More ways to join Join by video system Dial 1718363130@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) Access code: 171 836 3130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=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 --BHBmPoWA0eqNzurCfxPJhtrA3M2vQs9gR-- --pxY5HEvNrnnvqEH34zWhgAOiPZdYWFwZX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl99uGgACgkQ7iZktA5Y 2kOdcwf+PtmJpk0qKDrbHQ3pdW0u7/QHriR7wdJwDhi2kVJyxc1tCXko1iuQF/y5 N2d67JuHdp5pS+J06DoPRp+rkNAWyasQewXHrTAYT4jD1t3N6qOIAGjWkU95z7UW qoG2lJAwIbf9I9DZMO8Y71+SstvbW471+E00T9rH00TQotdKASm5LqFHHTPwgXG/ 6gbuIZGxOZjhP7m+93ZoAO7D5WYDU0IPUIdMje7vQG08oLy/cAyoos8ffST8vO3Y s2evi50h8bFkSFNUs+adi0g5TrQpuhxud5cH66vl6NL5ZxOQwYUtIkNvs5u0cjQA A+/2W09Yql/F2CHRJo9fwo60OVG91Q== =RvCP -----END PGP SIGNATURE----- --pxY5HEvNrnnvqEH34zWhgAOiPZdYWFwZX-- From nobody Wed Oct 7 19:03: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 A0DD13A0D96 for ; Wed, 7 Oct 2020 19:03: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 ix8F2-d1CxZn for ; Wed, 7 Oct 2020 19:02:59 -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 98C133A09C5 for ; Wed, 7 Oct 2020 19:02:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 80762389A0; Wed, 7 Oct 2020 22:08:22 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JhUGXg7MTOl9; Wed, 7 Oct 2020 22:08:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15BCA389CC; Wed, 7 Oct 2020 22:08:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 20E36F5; Wed, 7 Oct 2020 22:02:55 -0400 (EDT) From: Michael Richardson To: Marco Tiloca cc: "core\@ietf.org WG \(core\@ietf.org\)" In-Reply-To: <373d83e7-843e-edad-6795-a4c49bd7a146@ri.se> References: <373d83e7-843e-edad-6795-a4c49bd7a146@ri.se> 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] CoRE WG Virtual Interim 2020-10-08 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, 08 Oct 2020 02:03:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marco Tiloca wrote: > - The processing of comments for the Stateless document. I proposed slides to the DT. They are also at github.com/core-wg/stateless.git in meetings. Bike shed issue: https://github.com/core-wg/stateless/pull/2 =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9+c04ACgkQgItw+93Q 3WWnsAgAkNBaVKfgTOBldv7Y9De81rlhgULaG3QMTveLpQEGypTW8r5BxDiCte4r I0z3lyEOYt9LTXuFxJaPaB/jHtwY0HsQZ0yAEahwtFfORjkU8SLGpMw2CTEgQX1+ CYdCXxruueMiOEpRaelggopJJqqW5yfCt75wHzghGSkDJck+25czbhoSwtQzmR3v 6mT9UI7U+nBgYGbqMQEAfulf4wG1ynSskYdY/675+Ci3kPpyHX6VVfIU2hnAa6Ce 6eV64QIlVNvSnsHQPTv9B4ooB3qIETLVIfpC3jwO2YX6Lz0r3RJe3A/DG1fCFqyo VTUr7Cz9FgD13Xtylp1T+iEadlGMew== =Ru65 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 8 08:14: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 B41C43A0A4A for ; Thu, 8 Oct 2020 08:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 dnI7k4DB42Eo for ; Thu, 8 Oct 2020 08:14:49 -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 00C523A098C for ; Thu, 8 Oct 2020 08:14:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 35DD8389C2 for ; Thu, 8 Oct 2020 11:20:14 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sZrHJ2E2af9E for ; Thu, 8 Oct 2020 11:20:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D8EB5389AB for ; Thu, 8 Oct 2020 11:20:09 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF79418B for ; Thu, 8 Oct 2020 11:14:42 -0400 (EDT) To: core@ietf.org References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> From: Michael Richardson Message-ID: Date: Thu, 8 Oct 2020 11:14:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] issues #8, pull request #11 - fixing the SC AES/nonce issue 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, 08 Oct 2020 15:14:52 -0000 > > #8 use automated key management due to AES-CCM/BCP107 > https://github.com/core-wg/stateless/issues/8 This discussion in today's meeting suggested that we replace some of the nonce discussion with a reference to OSCORE (RFC8613) Appendix B.1.1: https://github.com/core-wg/stateless/pull/11/files shows the diff. The resulting text for section 5.2 is: 5.2. Stateless Clients and Intermediaries Transporting the state needed by a client to process a response as serialized state information in the token has several significant and non-obvious security and privacy implications that need to be mitigated; see Section 3.1 for recommendations. In addition to the format requirements outlined there, implementations need to ensure that they are not vulnerable to maliciously crafted, delayed, or replayed tokens. It is generally expected that the use of encryption, integrity protection, and replay protection for serialized state is appropriate. In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client. 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 might not add value in a specific case. For instance, if the state is an opaque (not sequential) index into a table of existing state. The choice to employ encryption for the state token is purely a local decision based upon understanding of threats to internal state. It should further be emphasized that the encrypted state is created by the sending node, and decrypted by the same node when receiving a response. The key is not shared with any other system. Therefore the choice of encryption scheme and the generation of the key for this system is purely a local matter. When encryption is used, the use of AES-CCM [RFC3610] with a 64-bit tag is recommended, combined with a sequence number and a replay window. This choice is informed by available hardware acceleration of on many constrained systems. If a different algorithm is available accelerated on the sender, with similar strength, then it SHOULD be preferred. Where privacy of the state is not required, and encryption is not needed, HMAC-SHA-256 [RFC6234], combined with a sequence number and a replay window, may be used. When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically. If a nonce is ever used for more than one encryption operation with the same key, then the same key stream gets used to encrypt both plaintexts and the confidentiality guarantees are voided. Devices with low-quality entropy sources -- as is typical with constrained devices, which incidentally happen to be a natural candidate for the stateless mechanism described in this document -- need to carefully pick a nonce generation mechanism that provides the above uniqueness guarantee. [RFC8613] appendix B.1.1 ("Sender Sequence Number") provides a model for how to maintain non-repeating nonces without causing excessive wear of flash. From nobody Thu Oct 8 08:40:37 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 3CCCB3A0A64; Thu, 8 Oct 2020 08:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7w-OxuVi7H3; Thu, 8 Oct 2020 08:40:30 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DD73A0895; Thu, 8 Oct 2020 08:40:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id D3F9A1940666; Thu, 8 Oct 2020 11:40:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 08 Oct 2020 11:40:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=uvQpx4sUmJqbvMc1/+VpqA2TPb4Hh WK4NR5hERJDamw=; b=H8O3/Ggy4Sr64ysGxW2ImBVu+DFElSt8qfuyH+kMNTlZu jDRK0Ej3B/C5hd662DM4/McRReDCPuYtPt96oZFejpG+ynietQXRE8FmjmzDpoPp +VIJc0MYA/uJfV8PvgMLMBEqwmZnu5edpAecaoT2qPZ/PL3B20tuRA7rZgeUkX6l 8P1rN4P/x01aZwip44VwTUpyTdoam1+3Mas1jbVfatZck7VRab8x4nJSC6mtH1Sy IZkWLN6RI88p8NfZY6aO9WVzkrRvz+sMflekYLOC3WDXU7MPCk4lowsKVsf9hEpt AhdhWoAqiOM754XNrJ+uRdjAqEbSguOtHsM+Xyi6w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeelgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugesthdtredttddtjeenucfhrhhomheplfgrihhmvgculfhi mhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnhepkeelhe dujefguddutedtfffgfeeugfevudejheefteeifffhvefhieevvdegteeunecukfhppeek jedrleefrddvhedrfeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepjhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: from EMB-918HFH01 (87-93-25-35.bb.dnainternet.fi [87.93.25.35]) by mail.messagingengine.com (Postfix) with ESMTPA id 34EC8328006B; Thu, 8 Oct 2020 11:40:24 -0400 (EDT) Date: Thu, 8 Oct 2020 18:40:22 +0300 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: draft-ietf-core-resource-directory@ietf.org Cc: core@ietf.org, core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, Christian =?utf-8?Q?M=2E_Ams=C3=BCss?= Message-ID: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Archived-At: Subject: [core] Reordering authorship list on RD 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, 08 Oct 2020 15:40:35 -0000 Dear RD authors, During today's CoRE interim it was brought up the excellent work Christian has been doing for quite some time on the resource directory draft. Thus the chairs would like to propose to reshuffle the authorship list and place Christian as first document author. Ciao! -- Marco and Jaime From nobody Thu Oct 8 08:50: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 100313A0DEC; Thu, 8 Oct 2020 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-GYhSlve7jQ; Thu, 8 Oct 2020 08:49:55 -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 89BA13A0DAE; Thu, 8 Oct 2020 08:49:54 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4C6bHh0sv4zycY; Thu, 8 Oct 2020 17:49:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> Date: Thu, 8 Oct 2020 17:49:51 +0200 Cc: draft-ietf-core-resource-directory@ietf.org, =?utf-8?Q?Christian_Ams=C3=BCss?= , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 623864991.608809-34603251d6c9eed6238122063792f092 Content-Transfer-Encoding: quoted-printable Message-Id: <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 08 Oct 2020 15:49:58 -0000 On 2020-10-08, at 17:40, Jaime Jim=C3=A9nez wrote: >=20 > Dear RD authors, >=20 > During today's CoRE interim it was brought up the excellent work = Christian > has been doing for quite some time on the resource directory draft.=20 > Thus the chairs would like to propose to reshuffle the authorship list > and place Christian as first document author.=20 (Maintaining editor role, I presume.) +1 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 8 08: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 47A1E3A0E23 for ; Thu, 8 Oct 2020 08:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smartthings.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 hmkWycU-E9xU for ; Thu, 8 Oct 2020 08:51:39 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 05B133A0E25 for ; Thu, 8 Oct 2020 08:51:38 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id b193so3752903pga.6 for ; Thu, 08 Oct 2020 08:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mDekxiqjF+U1Mxtcah+U8VfYCeBswPv3KGBKJBbALjk=; b=S7nnsmVNLIDWkpE0AN1doQnJQSn374pp1t8jfEoT9HRJpKbEk+V1+IgVn2wSWeGCtj Abn/02QRZeMKwPmE/+asiaKfsm8VstQy0DYvZV988RZT9B+wfHYWmu9+2RGmGCZopdzY ucaUCBz5oe2vFLebD3TV2uUeKk6/UUafYybtsce/60siiZhNWRSiM0Cg/c7zWsGWvBo0 RMQQdkterhp/NLrLho5/gOsvpkSKwQxbXbSs16slpMa5nb2frCLWqE4xB3w9eSoPKSRi lnbE1+1I1t1n+VQ830PB4BrIb4VPqIzc0eZ+QJJeP4OB9x2eGJ2Zf/J8BspPO2W16pGi h2DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mDekxiqjF+U1Mxtcah+U8VfYCeBswPv3KGBKJBbALjk=; b=PH7XbDtHMOjiJuJEEPgbOBsMIeQ/Pu0ujOsLsdjGnrDioXOZHWcAAoO0iq65YLX3a8 Lvego91wwiwv4Bj3VcuvPLwdy/BK4wDiHwGsGWm7E1y5gPyU+IIdtFeJxYAXo8x8rFoQ f3qbQqKrq5WqV8JH+v8m6u86nDVOo6MDvhqiV11G1xOnv1Boc5iBmBLKhK92WuJuyGFN Eg4gAJq4sB07V1ZourkcQUmunOE+zRd6B8tgz//I3LmzVyz1NdXsh7r7/as6LWvA5guF iSwOwSeh1hoTtvU4dMip6Rgy0GqwOyoiJaq+GkrJuhV8tAQlqkoEMQlT6kAdlb5pGGQ8 q5xg== X-Gm-Message-State: AOAM533uzgp6iinclCX6MXWK5s78s3PuWo+D/jvA/TiVRZIfaOyi9L8C rB6UP1yi8R6FiaqebFDod3181w== X-Google-Smtp-Source: ABdhPJw3/sONJ8rbgGZVhBZQ+hFs/UenJxG7Df+4pmmODGS46m9PKvmW19P1inyiMPACNIeCCFMl5A== X-Received: by 2002:aa7:81d5:0:b029:142:2501:39fa with SMTP id c21-20020aa781d50000b0290142250139famr8265272pfn.73.1602172298352; Thu, 08 Oct 2020 08:51:38 -0700 (PDT) Received: from [172.16.0.15] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id i17sm7052709pfa.29.2020.10.08.08.51.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Oct 2020 08:51:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> Date: Thu, 8 Oct 2020 08:51:34 -0700 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "draft-ietf-core-resource-directory@ietf.org" , =?utf-8?Q?Christian_Ams=C3=BCss?= , core-chairs@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 08 Oct 2020 15:51:41 -0000 Agree, +1 Michael > On Oct 8, 2020, at 8:49 AM, Carsten Bormann wrote: >=20 > On 2020-10-08, at 17:40, Jaime Jim=C3=A9nez wrote: >>=20 >> Dear RD authors, >>=20 >> During today's CoRE interim it was brought up the excellent work = Christian >> has been doing for quite some time on the resource directory draft.=20= >> Thus the chairs would like to propose to reshuffle the authorship = list >> and place Christian as first document author.=20 >=20 > (Maintaining editor role, I presume.) >=20 > +1 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Thu Oct 8 08:59: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 D6B5D3A0E44; Thu, 8 Oct 2020 08:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36vRumLw41JR; Thu, 8 Oct 2020 08:59:06 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5C43A0E47; Thu, 8 Oct 2020 08:58:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 6C2101940D03; Thu, 8 Oct 2020 11:58:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 08 Oct 2020 11:58:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=69F/BE/oMwkff8sEJqAEbmsO3HyI3QLtyKIZoJdx/ L4=; b=k7N3ifTWAGbPbDEHzf7cjf2TdGpSpxu6+1Zu03P+l9SOyBTsap9U9DP3p rvgaoR4alk8PsXqWdXHm1vuF+R7YK7BKMq4VXnbXV6+JBg837XOKYs+k6cSIRjQw NdDBd8c3/JDkdo+dkUCIvnoNJ8/0x5GmrB+bvGgLXFA5qCvo4pOACvhB70wD7jhQ vMcF5A3U7InwJyqjiM7aROyA7+K7sSScZWZtoEOi7qp1rE2K3n6ZaHcAzxFQ6Vva enKbslWvgxyyHGAPtlDyFpkSQakwYogzOBwXWtRW1jCU0dJ4VubHYbH+3ZGBVLv0 BVZCEi0UF3gnypUsvhOZ4/XhK48xA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeelgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeflrghimhgv ucflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe dtudduffdtueeugfegtdethfekffdtveekiedvveetudetgeegveeuvdegffffieenucfk phepkeejrdelfedrvdehrdefheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: from EMB-918HFH01 (87-93-25-35.bb.dnainternet.fi [87.93.25.35]) by mail.messagingengine.com (Postfix) with ESMTPA id 5334F3280063; Thu, 8 Oct 2020 11:58:56 -0400 (EDT) Date: Thu, 8 Oct 2020 18:58:55 +0300 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Carsten Bormann Cc: draft-ietf-core-resource-directory@ietf.org, Christian =?utf-8?Q?Ams=C3=BCss?= , core-chairs@ietf.org, core@ietf.org Message-ID: <20201008155855.pszm6w7favosy4ok@EMB-918HFH01> References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 08 Oct 2020 15:59:08 -0000 On 08.10.2020 17:49, Carsten Bormann wrote: >On 2020-10-08, at 17:40, Jaime Jiménez wrote: >> >> Dear RD authors, >> >> During today's CoRE interim it was brought up the excellent work Christian >> has been doing for quite some time on the resource directory draft. >> Thus the chairs would like to propose to reshuffle the authorship list >> and place Christian as first document author. > >(Maintaining editor role, I presume.) Marco and I were not sure about that part, as Christian has also authored quite a large portion of the draft by now. IMO the authors and editor can decide. > >+1 > >Grüße, Carsten > From nobody Thu Oct 8 09:15:12 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776C93A0D89; Thu, 8 Oct 2020 09:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXisqLX1ADx4; Thu, 8 Oct 2020 09:15:07 -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 743473A0AEC; Thu, 8 Oct 2020 09:15:05 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4C6brh2F3tzyhp; Thu, 8 Oct 2020 18:15:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20201008155855.pszm6w7favosy4ok@EMB-918HFH01> Date: Thu, 8 Oct 2020 18:14:59 +0200 Cc: draft-ietf-core-resource-directory@ietf.org, =?utf-8?Q?Christian_Ams=C3=BCss?= , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 623866499.8398041-2a6c7c3c5a53662ef99d75dad4cc4ff2 Content-Transfer-Encoding: quoted-printable Message-Id: <2F3B4553-F607-4A75-AA11-21B73F0F4E35@tzi.org> References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> <20201008155855.pszm6w7favosy4ok@EMB-918HFH01> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 08 Oct 2020 16:15:12 -0000 On 2020-10-08, at 17:58, Jaime Jim=C3=A9nez wrote: >=20 >>> and place Christian as first document author. >>=20 >> (Maintaining editor role, I presume.) >=20 > Marco and I were not sure about that part, as Christian has > also authored quite a large portion of the draft by now.=20 > IMO the authors and editor can decide.=20 Right. RFC7322 is not very specific on what role=3D=E2=80=9Ceditor=E2=80=9D= actually implies. RFC 7749 and RFC 7991 are more specific :-) Note that this specification does not define a precise meaning for the term "editor=E2=80=9D. To me, this term implies overall responsibility for the document, while = the other authors are only authors of specific parts or aspects of the = document. But others may think that editor =E2=87=92 =C2=AC author, = which I=E2=80=99m not subscribing to. Right now Christian is qualified with role=3D=E2=80=9Ceditor=E2=80=9D, = and I just wanted to say that we didn=E2=80=99t discuss changing that = =E2=80=94 we certainly could if we want. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 8 09:33:31 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 47D5C3A0DBE; Thu, 8 Oct 2020 09:33:30 -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 fipzHuMyeihb; Thu, 8 Oct 2020 09:33:28 -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 DFEF43A0E65; Thu, 8 Oct 2020 09:32:54 -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 B576340039; Thu, 8 Oct 2020 18:32:50 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6015E74; Thu, 8 Oct 2020 18:32:49 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:aaaf:a622:4270:c82f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D7EC744; Thu, 8 Oct 2020 18:32:48 +0200 (CEST) Received: (nullmailer pid 853681 invoked by uid 1000); Thu, 08 Oct 2020 16:32:48 -0000 Date: Thu, 8 Oct 2020 18:32:48 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: Jaime =?iso-8859-1?Q?Jim=E9nez?= , draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org Message-ID: <20201008163248.GA804983@hephaistos.amsuess.com> References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> <20201008155855.pszm6w7favosy4ok@EMB-918HFH01> <2F3B4553-F607-4A75-AA11-21B73F0F4E35@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <2F3B4553-F607-4A75-AA11-21B73F0F4E35@tzi.org> Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 08 Oct 2020 16:33:30 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 08, 2020 at 06:14:59PM +0200, Carsten Bormann wrote: > Right. RFC7322 is not very specific on what role=3D=E2=80=9Ceditor=E2=80= =9D actually implies. > RFC 7749 and RFC 7991 are more specific :-) >=20 > Note that this specification does not define a precise meaning for > the term "editor=E2=80=9D. FWIW, I'm understanding my editor role to reflect that my work on the document is to primarily reflect the WG's decisions about the document, or to take edits when no hard decisions are to be taken (and/or nobody says anything). Topics I'm bringing in are brought up with a WG member hat on (as issues or suggested changes), and as an editor I keep them at a PR level unless there is some positive WG or author reaction. An author's role is that of someone who brings in content before adoption, or (altough I'm not sure whether that is formally covered) advances the document without further WG consultation, to some point. (If I did that, it was not my intention and, to an extent, a flaw in performing the editor role). With that, I (hope to) see the editor role reflected in my work here, but (given it's wobbly terminology, and I probably shouldn't get a say anyway) gladly accept either. Thank you all Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl9/PywACgkQOY0REtOk veEO/BAAyzP1KUrjVSebj8MIkmtl7Bqq5y5D4Ipo+mIauaLYuWBNqtLM9UsjMr0J Zp1nkK73cqfQ0qLdyAsvE9uYw6VoVnxeCSnKE/Dhhe02QpuIadtN3YPRtvVZOQcq O055U218xQm+c5IKQ1C7kMbrhDLn0luEiXNF+k5N0iHbZOwoOp/VLGHOG9awU9OM sBWkzrZKkut8LwEMNuTNdN+piTHcbP/kGOGOTtfr8pSfKuGrx1bwzLRTAsTbtnVR AT1cPKX8DnfBi1XpWb+fodN7i0bS7Ps7WlgkC9/c/sogljv5VyO3Z4dt7YUIIBRC IEgtq+JWrsbfCmzfPpEn1kZL1TSoNm0NwioEn305GSldOsTTKABQ17x26LUmf4VM EgBFMJIdEii7n21d/L+/EIAhW9xP0oOL2Yigu+fMl5mAkw+BWqYrqtyDFi3v0ynh 5WAeo/Wfwt2jqgaCMoS/UR2b7k++41mzU9Smb4L0uRC5Mo8GOz0rWmTvSizeSiWj 0Gcu6IY6lgzsgdZR3ZfXJJlzU96TvTKupzguVFy1IMPqOwHZ0UAZvNOk93pLSZWi QG5trOnMB2CLbv/5+8Z+8ddJcaRBMwbGyBLGI0Qu8BTLNsgBW3C6VM2Id2YCTYgy FA8pP+Gr8ldn76fvOUiAoZOSNuIYO7a3pjTJhRFOcRfHTMgvEMQ= =PieV -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From nobody Thu Oct 8 10:05: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 1DF093A0EA0 for ; Thu, 8 Oct 2020 10:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 Vg9wWYiVOA4k for ; Thu, 8 Oct 2020 10:05:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACC33A0E9F for ; Thu, 8 Oct 2020 10:05:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A0527389B7 for ; Thu, 8 Oct 2020 13:11:14 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8mkQoJ6-gxbY for ; Thu, 8 Oct 2020 13:11:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EC67389B5 for ; Thu, 8 Oct 2020 13:11:13 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1FB4F1CC for ; Thu, 8 Oct 2020 13:05:46 -0400 (EDT) To: core@ietf.org References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> From: Michael Richardson Message-ID: <178f39a0-f4ee-ab1a-0b26-d265cb6e3496@sandelman.ca> Date: Thu, 8 Oct 2020 13:05:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] issues for stateless AD review 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, 08 Oct 2020 17:05:51 -0000 > I think we can simply explain a wontfix on: > > #3 is stateless updating 7252 on distinguishing unrecognized vs invalid extension? > https://github.com/core-wg/stateless/issues/3 It seems that the core of this comment is that stateless should "Update" (in the form of "Amends") RFC7252. I think that is a reasonable thing to do. > #4 how does freshness window of client/intermediate interact? > https://github.com/core-wg/stateless/issues/4 The on-path attacker that can see the token, can send a reply first (dropping the real reply), using up the replay, and thus attack, like any UDP protocol. The off-path attacker that can see the traffic (whatever we are going to call that, see saag), would have to race the legitimate response, otherwise they would get marked as a replay. Marked wontfix. > #6 can larger tokens fill responder memory? > https://github.com/core-wg/stateless/issues/6 Marked wontfix: Klaus' reply explains that if one doesn't have a buffer big enough to receive the packet, then one can't get one's memory exhausted. > #7 how to size the replay window? > https://github.com/core-wg/stateless/issues/7 Upon re-reading, I think that we can answer this with: https://github.com/core-wg/stateless/pull/14/files > #9 look ma, no state! > https://github.com/core-wg/stateless/issues/9 closed wontfix. From nobody Thu Oct 8 10:08: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 7AA1F3A0EA0 for ; Thu, 8 Oct 2020 10:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 zL_faMK8tuFe for ; Thu, 8 Oct 2020 10:08:56 -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 13DFA3A0D14 for ; Thu, 8 Oct 2020 10:08:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 33BD2389B7 for ; Thu, 8 Oct 2020 13:14:22 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WLBqcDjrkDde for ; Thu, 8 Oct 2020 13:14:21 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E4E5389B5 for ; Thu, 8 Oct 2020 13:14:21 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EFC3A1CC for ; Thu, 8 Oct 2020 13:08:53 -0400 (EDT) To: core@ietf.org References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> <20201008155855.pszm6w7favosy4ok@EMB-918HFH01> <2F3B4553-F607-4A75-AA11-21B73F0F4E35@tzi.org> From: Michael Richardson Message-ID: Date: Thu, 8 Oct 2020 13:08:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2F3B4553-F607-4A75-AA11-21B73F0F4E35@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 08 Oct 2020 17:08:58 -0000 On 2020-10-08 12:14 p.m., Carsten Bormann wrote: > On 2020-10-08, at 17:58, Jaime Jiménez wrote: >> >>>> and place Christian as first document author. >>> >>> (Maintaining editor role, I presume.) >> >> Marco and I were not sure about that part, as Christian has >> also authored quite a large portion of the draft by now. >> IMO the authors and editor can decide. > > Right. RFC7322 is not very specific on what role=“editor” actually implies. > RFC 7749 and RFC 7991 are more specific :-) > > Note that this specification does not define a precise meaning for > the term "editor”. > > To me, this term implies overall responsibility for the document, while the other authors are only authors of specific parts or aspects of the document. But others may think that editor ⇒ ¬ author, which I’m not subscribing to. While there are cases where editors are brought in to finish documents, and have reasons they don't want to held responsible for the entire contents, in most cases, I think that editors >= authors in terms of what they contribute. > Right now Christian is qualified with role=“editor”, and I just wanted to say that we didn’t discuss changing that — we certainly could if we want. I think of this qualification is as being a superset. Anyway, yes, I think it's a good idea. From nobody Thu Oct 8 10:09:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F73A0EA5 for ; Thu, 8 Oct 2020 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 jXGJN_q3csel for ; Thu, 8 Oct 2020 10:09:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E462F3A0EA0 for ; Thu, 8 Oct 2020 10:09:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CF91389B7 for ; Thu, 8 Oct 2020 13:15:15 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aX5E6ti9AZkr for ; Thu, 8 Oct 2020 13:15:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B6C6389B5 for ; Thu, 8 Oct 2020 13:15:13 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F2A071CC for ; Thu, 8 Oct 2020 13:09:45 -0400 (EDT) To: core@ietf.org References: <373d83e7-843e-edad-6795-a4c49bd7a146@ri.se> <32255.1602122575@localhost> From: Michael Richardson Message-ID: <2de461af-57b7-ff84-d784-453e461ebf9d@sandelman.ca> Date: Thu, 8 Oct 2020 13:09:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <32255.1602122575@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2020-10-08 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, 08 Oct 2020 17:09:50 -0000 On 2020-10-07 10:02 p.m., Michael Richardson wrote: > > Marco Tiloca wrote: > > - The processing of comments for the Stateless document. > > I proposed slides to the DT. > They are also at github.com/core-wg/stateless.git in meetings. > > Bike shed issue: https://github.com/core-wg/stateless/pull/2 While it is a bike shed issue, it's still actually a problem. Please suggest something in the pull request. From nobody Thu Oct 8 11:01: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 12D323A0BA9 for ; Thu, 8 Oct 2020 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDD2YtN-7NnJ for ; Thu, 8 Oct 2020 11:01: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 672D33A0BA8 for ; Thu, 8 Oct 2020 11:01:44 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4C6fCp3RcyzySQ; Thu, 8 Oct 2020 20:01:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <178f39a0-f4ee-ab1a-0b26-d265cb6e3496@sandelman.ca> Date: Thu, 8 Oct 2020 20:01:41 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 623872901.745765-589df396f6155345e8eb649f985ca239 Content-Transfer-Encoding: quoted-printable Message-Id: <9A8AC156-F0DF-4765-8714-38E5343FBF42@tzi.org> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> <178f39a0-f4ee-ab1a-0b26-d265cb6e3496@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] issues for stateless AD review 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, 08 Oct 2020 18:01:47 -0000 On 2020-10-08, at 19:05, Michael Richardson = wrote: >=20 > The on-path attacker that can see the token, can send a reply first = (dropping the real reply), using up the replay, and thus attack, like = any UDP protocol. > The off-path attacker that can see the traffic (whatever we are going = to call that, see saag), would have to race the legitimate response, = otherwise they would get marked as a replay. Let=E2=80=99s try not to import the brokenness of the terminology being = introduced in SAAG to this document. An on-path attacker is on-path, but doesn=E2=80=99t necessarily have the = power to suppress or modify messages (that would be an in-path attacker? = We used to say MITM and this was clear). An off-path attacker is not seeing the messages; they can only inject = (blind attacker) or start new conversations (thus becoming a form of = on-path for that conversation). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 9 02:27: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 C0A2D3A0DE8 for ; Fri, 9 Oct 2020 02:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ioteropcom.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 WR9apjdoJJFg for ; Fri, 9 Oct 2020 02:27:56 -0700 (PDT) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90139.outbound.protection.outlook.com [40.107.9.139]) (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 A025B3A0DDE for ; Fri, 9 Oct 2020 02:27:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ltx948eD1GxpqVLH2lO1Te2CKFiUZRrTuem8wG/Q9oE/R+TqD+Us3RrRVxdhYNCK9GLqVnuuvTPVKnkkLpC7ZYApw3Ztz50wsRQ9eBqk7oYoo9UP/j0o9hjjlRV8HpqNunHwAgs35rSIduGjDAJy2I1UGfKS7sJgw+9IAHFqS8I4QN7bQdKOsV9BMw9OR2xwC7ajXeKho/YJu0Lgr6aNj35lSYQqvhTnFRtPLF3HUGzrfNsc9pwhmEjDOw/TplZ82TodupKYugvAAItzhVH/kdIbYDy0VWPD+HApdxOsUdzx4ZiJlgPRnFPwE8jOfUurM0S+ZWZk3ia1E5XdNPpNaw== 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=NLJ5qCHuocQfT6mr9WAw5TFFNjvWVHrMMUkb1rU1nrE=; b=NOx28Gw3gLkhNX96tD+Z/T3wKwhbwZHj7RTjZoythFLrYQR956Y58DH8h3wF59ecHzdAbivpFjsqFm3G4q9xuORb4bO9GHaeyeIXV1U0bQJq7XOi/aROQXJ9+G4lJbfIDx+ZAje/sbjfNhhdmbIImXPUGjvu6m8sJuJanHchVYyrJgHycxVVg+InYuCp4GQVsjqCU25d400T5BCVybQ1U+6GY2TzNgg5S60MWSuR7dAYfhVcQQ38u9/yaNkKevPXm/WOCtSg3ctbh4PKz+JjOw30JWAl2jIW771TCtrzLWqEQCv8NnPct9QumboC6wX3vijpWFJT+74EHha7OIGjYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ioterop.com; dmarc=pass action=none header.from=ioterop.com; dkim=pass header.d=ioterop.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ioteropcom.onmicrosoft.com; s=selector1-ioteropcom-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NLJ5qCHuocQfT6mr9WAw5TFFNjvWVHrMMUkb1rU1nrE=; b=oi+cRMBPyxNu/IxG8KMAt5ZMTjVtkFKjhAs7TSkVRb8iWqwjNo4A7wR5totyBRmmZrNOGAWysviou1DMKUSI6IV5HychfoTSRV8TQidIQbPHudHW+BM50sitmbVnwq5lKUheYHK6sNwXxk+3KFNcrMB+0jbqfX+fb9USbVWvcY9P1sac/9t2OiBdG9aILRN+nkBYffsRa2sNQ7AYNinXIrsSpJdIvA/wUCh3RMMtFEcx20++d4VCTqZIPCTyduuQ4B6Uft+AdkmZ9724ree5zQfNevpiLp4Chiof/0KtXJ35cXoH5KX0o80uATllU6LbcZXkhett9OTCJSe+vqmQLw== Received: from PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101:2::22) by PR2P264MB0143.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101:7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Fri, 9 Oct 2020 09:27:48 +0000 Received: from PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM ([fe80::b463:6e2e:492:efc1]) by PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM ([fe80::b463:6e2e:492:efc1%7]) with mapi id 15.20.3433.047; Fri, 9 Oct 2020 09:27:48 +0000 From: David Navarro To: "core@ietf.org" Thread-Topic: Dynlink: pmin and pmax Thread-Index: AdaeHYjb5MOJC/+YRVKXL+AjSyl8jw== Date: Fri, 9 Oct 2020 09:27:48 +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=ioterop.com; x-originating-ip: [90.85.188.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d03c08a5-2cc5-4cdc-a626-08d86c35966f x-ms-traffictypediagnostic: PR2P264MB0143: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2pZPzE4ygcQB55gZ+u0mV2jtmHrlnFmh0m3eA0HgrfAoISbS0Xw2H7x/LB8Vz1tryAH/KZEkAYkTVH5Jetfo7LJFGMW7dXWwFuaHA1BPYprJrbfmKdXydOFZe6+j6hy+oUwIpVf2rzueZuVR36rcxMckIgLB0P52xmgMNUyxy3qNZWpuE9zGYwGcjkrVheTSzj3cJ4fk1MPFZ8ON+TMctueujTlI/eC4S7E+AZYaff/zoyM1wYNpf5hVdxe824KA+wVRXrOaWQZXFVbJ8hbQRtDiPIY8A5FEF/VvBqD/WirYThe5ozRAz2Lohc9jGntNscMe0bmAcZ1QYLjYITAN3ezCNy0Ldo6bcq/k2Q62XLECTKn70iEIlzppckXyZ68rVMyFjixZkp/9XhOXQ6OBDA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(396003)(39830400003)(346002)(376002)(136003)(83080400001)(478600001)(2906002)(6506007)(52536014)(83380400001)(186003)(316002)(71200400001)(76116006)(44832011)(7696005)(26005)(66446008)(966005)(66556008)(66476007)(64756008)(66946007)(8936002)(8676002)(33656002)(9686003)(86362001)(55016002)(5660300002)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 10tMfHaepj0QWL7yezYV4Y1S70ENsao0szSewkgS6lSF5maKcxCYruOpHiHJW+TSP/mRcLbFUOi6ulkIkcs6IvAYuWZBp5Kur4YjOozsSPLSHsu8JjrkZNZElWj4J0RxvxqDQItGRG9tpq/jlOSUkz2rv89HQBZc+XDGlhUhyy1ur6qw0StL9uXdp5TuqDt271NfJxT9sl8walsXW+jqVOJPEsvHGzbqkwoIWgaLKItFHzj8Vyzw3LioKwOyROC35yxliZffKFmaUqpSsVRGSnxOEURA2kRqSPcfZEXbmcKrVz+kYTLWgaASX8LCGRbmtlftDDLf4hCEBUlxKQNq+zicOJ47TOVwbfoqvKQfUFpu3hg+rIq8mVqBkdc3PaoaTXRmAaqb0xf3AkNKMMWRGAEFHr9MdA/gaTR8eUcv7ULCfOATi091ERIgRn4hDwfsYygMGisez5RarkX0BYgsDgH3FHmE2hYxKyEnHl0iwjqQRonsnRU42zAvI4XKmjJbo0qGUqjsbZNepMzVvq4ZMfnMt9+b2HApX9YIvqBkkNc6UU4wFGBbdzC0IK6ZiVEdSqzDCN0CvLUPhTGzkomzc3+nclkE/Q4lvgrzSJb47C7JiGkMuvBVbTNSOqDKfmxveRwML9T+Ny15CLD3Uc/f4Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ioterop.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d03c08a5-2cc5-4cdc-a626-08d86c35966f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 09:27:48.4342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c0df38cb-a6d1-4728-a099-b8bb2ed471dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t6LA+GEJFIAJO+qIrQeS2NvOerUNb9DepWeGAR3DjPRlYGkwmO7DNeB4iZmLnOhtsonC1evnzCs5Kpf7pBWfsuGdyLB+93bo938dbxcCNU8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2P264MB0143 Archived-At: Subject: [core] Dynlink: pmin and pmax 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, 09 Oct 2020 09:27:58 -0000 Hi, I'm a member of the OMA LwM2M working group. The LwM2M protocol is using Mi= nimum Period (pmin) and Maximum Period (pmax) attributes, among others. Regarding these attributes, the DynLink draft has this requirement for pmax= : > The maximum period MUST be greater than zero and MUST be greater than the= minimum period parameter (if present) In its version 1.0, LwM2M had a different version of this requirement in th= e form: > The maximum period parameter MUST be not smaller than the minimum period = parameter. Thus having pmax equal to pmin was allowed. In LwM2M 1.1 we aligned this requirement with the DynLink one, making pmin = equal to pmax forbidden. However, it was brought to our attention[1] that having pmin equal pmax is = a valid use case if the client wants the notification to be sent exactly ev= ery N seconds. Is there a strong opinion on forbidding pmax to be equal to pmin, or are pe= ople open to changing the Dynlink requirement ? I opened an issue for this: https://github.com/core-wg/dynlink/issues/25 And a matching pull request: https://github.com/core-wg/dynlink/pull/26 Best regards, David Navarro [1] https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/4= 95 From nobody Mon Oct 12 02:35:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51263A13B9; Mon, 12 Oct 2020 02:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbmBqbbJMrKt; Mon, 12 Oct 2020 02:35:41 -0700 (PDT) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F093A1336; Mon, 12 Oct 2020 02:35:40 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 2FC28B6E; Mon, 12 Oct 2020 05:35:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 12 Oct 2020 05:35:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=i+dDNCN8ARxu78wB/4CibLuGmA3yZfjPmgCsHAXB+ U8=; b=lb7HNOnn2ILTYQS8lE273V+JlclRwc+KOnNUSwNSeSnA5Pw+4xBkRhaAV Mp8dwCmBi80uG9h51iqyR/p4NJmU0gIZWGGFjGcxXp7415TNiAz87r7cqKKtVMTf TdUSRJbX0PQCIHLr+GV4IsDY/fQOCyAMnXtar79Jo8sh1dekWRH0u2PiHs4VtByi FHK91L84mXmgh7HHTaVAb1AGPcOZInENaFHAFq8wi0cR+FzoxOktmU0sGSwx7BpT L/4igX0gIyHkDJmparuKhJWZQaAlhoL9oydh8ybwcx6NUNR5mgxUaxgQmGh8QCRe iMYg/9F18p1k+coU7AOM4UomP9exQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheejgdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeflrghimhgv ucflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe dtudduffdtueeugfegtdethfekffdtveekiedvveetudetgeegveeuvdegffffieenucfk phepiedvrdduieehrddugeelrdeiieenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: from EMB-918HFH01 (62-165-149-66.co.dnainternet.fi [62.165.149.66]) by mail.messagingengine.com (Postfix) with ESMTPA id CE5A23280064; Mon, 12 Oct 2020 05:35:35 -0400 (EDT) Date: Mon, 12 Oct 2020 12:35:34 +0300 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Christian =?utf-8?Q?Ams=C3=BCss?= Cc: Carsten Bormann , draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org Message-ID: <20201012093534.urjmlvhaycghe2j3@EMB-918HFH01> References: <20201008154022.bnzz6sns76bphdzh@EMB-918HFH01> <314336DD-0944-4B87-8615-F3F468A48F72@tzi.org> <20201008155855.pszm6w7favosy4ok@EMB-918HFH01> <2F3B4553-F607-4A75-AA11-21B73F0F4E35@tzi.org> <20201008163248.GA804983@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201008163248.GA804983@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Reordering authorship list on RD 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, 12 Oct 2020 09:35:43 -0000 Hi, RFC7991 does say that the "editor" is a type of "author" too but indeed the terminology is a bit wobbly. I think both Marco and I would be happy with whichever alternative you (authors & editor) choose. I think you can make the changes directly on the repo as well. Thank you! Marco & Jaime. On 08.10.2020 18:32, Christian Amsüss wrote: >On Thu, Oct 08, 2020 at 06:14:59PM +0200, Carsten Bormann wrote: >> Right. RFC7322 is not very specific on what role=“editor” actually implies. >> RFC 7749 and RFC 7991 are more specific :-) >> >> Note that this specification does not define a precise meaning for >> the term "editor”. > >FWIW, I'm understanding my editor role to reflect that my work on the >document is to primarily reflect the WG's decisions about the document, >or to take edits when no hard decisions are to be taken (and/or nobody >says anything). Topics I'm bringing in are brought up with a WG member >hat on (as issues or suggested changes), and as an editor I keep them at >a PR level unless there is some positive WG or author reaction. > >An author's role is that of someone who brings in content before >adoption, or (altough I'm not sure whether that is formally covered) >advances the document without further WG consultation, to some point. >(If I did that, it was not my intention and, to an extent, a flaw in >performing the editor role). > >With that, I (hope to) see the editor role reflected in my work here, >but (given it's wobbly terminology, and I probably shouldn't get a say >anyway) gladly accept either. > >Thank you all >Christian > >-- >To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Mon Oct 12 04:25:17 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 EE3E93A0D38 for ; Mon, 12 Oct 2020 04:25:15 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK9dbST7ztb1 for ; Mon, 12 Oct 2020 04:25:13 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50096.outbound.protection.outlook.com [40.107.5.96]) (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 141233A0D24 for ; Mon, 12 Oct 2020 04:25:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZcUm4QiD8C2byXAkWBKGczBujzjvZpomR89aQK9uDn6I/A9heXoBZgOOMtUA1kG/QcOZHqLrCMZWlgCCxGTvU3mruon2J+d9O9SYR9DCsl0lSmoaWpx04XF8wvlS1IUu+7HJwvAIKEgYqYyhdkesNgNOYS2JSK/fyYPK7gahoGCzwCV/jk572oLQtPS6XM8OSldJwP2WqwQbhBKGAil1kjQlzELa5vRajk8KXcfMPhmzZx+2jDADgFRenlHThg0q/HriTgLjd5iCRKQiV63DbynTeIvW0plqn/oM3TIkuTKDNsNoO9qAcXUpt7l/0lHun8CWa9sEy+oESS6xh1Dlyg== 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=JhTsuMXjOkn19zEK9quFnbIA5PK0uGqVEuCfD6Qzt4k=; b=jarENVdkvy3GYnNG+e5uW4yyooKr33CcP+zSP19TaQkmBOi0js+lYCb/cg71fxvbKrcZET4f5FPVZq/bosvIsXkSa+aHs/w3Zx8oYNC7peJwX3FYEAzX6y7RO+rzh/i/VivrloP28cEpobi0jMncCavs93tzICbbkGp7nSD7ku1gtw3Jy93wRYr4oAsQXEJDQmbcKLD0Seps1DcxJHN0mrYtw+bKtNGw+oPDZx5TGrrJOg3bsSaasI18ra4Dar7tqZLkfXA3KGGq2FIvFKC25eA8xVdJFH8vvDEFJjfl1PwIWyT7jE0N9orv0Ei35HxTholeZxU/EIio+w2U7ANCkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JhTsuMXjOkn19zEK9quFnbIA5PK0uGqVEuCfD6Qzt4k=; b=MRxNX9W1ysvcN74XISThkqyWl5Giw498CsyH9cCFMES9MiDx0+7VOG30NDZScvgxQRJS1qV1ZDNDkQw/Akb6pkDdw6yfIhyjvWmwD2ugZoH/j8uVph7ZCJomhLp1xP3dKZTliHl8sNuCu6hTB/8opnddPO1TgYsZmghOipuMadU= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0737.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:195::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Mon, 12 Oct 2020 11:25:10 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3455.029; Mon, 12 Oct 2020 11:25:10 +0000 From: Esko Dijk To: "core@ietf.org" CC: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? Thread-Index: AdagiZ7ddTpjV6VySOOkvoVV5WS9KQ== Date: Mon, 12 Oct 2020 11:25:10 +0000 Message-ID: Accept-Language: en-US, nl-NL 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=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:358c:6ab9:6ef9:2619] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 393de971-64fa-4cfb-6e29-08d86ea17ad7 x-ms-traffictypediagnostic: AM0P190MB0737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Gqft8g44UkReOzPmiFtgYv2mXJ3zuKDUW76yGv9sta4YTPJJaiIIY1TjSTDKTfOaov8b/loTA1Vysx0UgeNUoTsMiwDvE92OpXjgsWW6AW9VU5Vt3JkyAIzbWepg+7n16ZbKN4HfUOSkFSuUE7FcyMPcYkYkK1hxxr+WXL6zRUMP6+u3aYWCVbk3oAJNafWq3q2aj2qtTksaaff/BAlcVQ6uuPcZn1dSyjL7YkJ2Hb2FqAWylELVmAavSBtQV57imFjB++3seDAJ6s1vTUzw/Vja3oscxOuCcgnBbVLkG+tgLHDL0BKwHqcfgJ1WkUKi9yFBFsQS+jBmeFdi55J6cKGNHOVzq2yLFIij8Boz4vqteUZl4b8GitNBf7zLGTkG+XXn2+JR0Edb5uL/S5KJVg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(346002)(136003)(366004)(39830400003)(376002)(44832011)(8936002)(9686003)(186003)(4744005)(6916009)(6506007)(966005)(71200400001)(33656002)(2906002)(86362001)(7696005)(478600001)(76116006)(66556008)(66446008)(66946007)(5660300002)(55016002)(83080400001)(166002)(8676002)(316002)(83380400001)(52536014)(4326008)(66476007)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 4tBml/HqmXJ6nm8AfEE3q/bsWgXXlS5XLuOj9/WWfCC0aOnFkEVEJ5FZyZ7IMKvegrqw+uACWGh4JHabywKQsN8OZqfueEzvhz5XQic2Ztd0IArpEqNuVJVh3wLCBJ+XFLz4Zcggzjfr4ixNnleWy165tP21/ltf9l2zqoQMwnoGPNitGIktEGWaDWaYj8ZPa3LU12w+R+HDNExk9lGahqOG2NTzt6vauf14B0qye4cGbboLhSvYZk3hu0Z5R7w97OBi0GN5PANXST5S6DbrQHeCo+sdV5hu8HZ8iGyM3Qzo2iF8tLTg3z/qGpM96Ds4ABoy0354Uo/z/kN8uhQrOIuVGstKWJZsVtDsPpo4OdZWSPuQt6xtFs7QEhNwEjFi5IYmSy/A5gi8YNlHB9cpgsClD+nmsoRHKqaRYSvwRPg54eiye3A/UXhs5o3yNtSUYsTY68fVi5naIFON5VYpcDoOwGxp5Z4XJQV6Z9dPu6fBsPAeF7sQcigMhmF86TNNdrMed5Rl/btqNcMRS/Ux9vLh0uBv/pLUrNj5qog/CwpsRDrBucDjheGy/cb2LU7g6EHRFR2fdEIVNCf87gkSrJJcPA1RSvpruxmJ6ivRA4dC9gOL65lNUJ1RytObBLgUz2Ie805Zam0GnHtZ8HTvfTqqoyWOPd198tE04t/WF/IK7PALkvk2Cpvs3gp9BSE7pIyk3ByqFh3kT0n5ZALdhA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB09798CB94C780DBB8DD718CBFD070AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 393de971-64fa-4cfb-6e29-08d86ea17ad7 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 11:25:10.1359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vYCHzxXTWV/7T93T78UlLPg5CVDjo8AhrKirbUBUzz169mOdQ57X2P5BHMs/jzcXkyhBwjBIbbRJDipFmbYbhDcRuA9+EbVg6LMMAnywLaw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0737 Archived-At: Subject: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 11:25:16 -0000 --_000_AM8P190MB09798CB94C780DBB8DD718CBFD070AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCknigJl2ZSBjcmVhdGVkIGEgR2l0aHViIGlzc3VlIGZvciBSRDogaHR0cHM6 Ly9naXRodWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5L2lzc3Vlcy8yODEgLCBhYm91 dCDigJxhbmNob3LigJ0gYXR0cmlidXRlcyBpbiBMaW5rIEZvcm1hdCB0aGF0IHNlZW0gdW5uZWNl c3NhcnkuIEhvcGluZyB0aGlzIGhlbHBzIHRvIG1ha2UgTGluayBGb3JtYXQgZG9jdW1lbnRzIHNt YWxsZXIgaW4gc2l6ZS4NClRoaXMgaXMgc29tZXRoaW5nIEkgZm91bmQgYWZ0ZXIgcmV2aWV3aW5n IFJEIGFnYWluIGFmdGVyIHNvbWUgeWVhcnMgSSBsYXN0IGxvb2tlZCBhdCBpdC4gICAgKE1heWJl IHRoZXJlIHdlcmUgbmV3IGluc2lnaHRzIHRoYXQgY2F1c2VkIHRoaXMgY2hhbmdlLCBpbiB3aGlj aCBjYXNlIEkgbXVzdCBoYXZlIG1pc3NlZCB0aGVzZSDigKYgIGFwb2xvZ2llcyBpZiBzbykNCg0K QmVzdCByZWdhcmRzDQpFc2tvDQoNCklvVGNvbnN1bHRhbmN5Lm5sICB8ICBFbWFpbC9UZWFtczog ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPG1haWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFu Y3kubmw+DQoNCg== --_000_AM8P190MB09798CB94C780DBB8DD718CBFD070AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9 IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZl IGNyZWF0ZWQgYSBHaXRodWIgaXNzdWUgZm9yIFJEOiA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5j b20vY29yZS13Zy9yZXNvdXJjZS1kaXJlY3RvcnkvaXNzdWVzLzI4MSI+DQpodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9yZXNvdXJjZS1kaXJlY3RvcnkvaXNzdWVzLzI4MTwvYT4gLCBhYm91dCDi gJxhbmNob3LigJ0gYXR0cmlidXRlcyBpbiBMaW5rIEZvcm1hdCB0aGF0IHNlZW0gdW5uZWNlc3Nh cnkuIEhvcGluZyB0aGlzIGhlbHBzIHRvIG1ha2UgTGluayBGb3JtYXQgZG9jdW1lbnRzIHNtYWxs ZXIgaW4gc2l6ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMg c29tZXRoaW5nIEkgZm91bmQgYWZ0ZXIgcmV2aWV3aW5nIFJEIGFnYWluIGFmdGVyIHNvbWUgeWVh cnMgSSBsYXN0IGxvb2tlZCBhdCBpdC4mbmJzcDsmbmJzcDsmbmJzcDsgKE1heWJlIHRoZXJlIHdl cmUgbmV3IGluc2lnaHRzIHRoYXQgY2F1c2VkIHRoaXMgY2hhbmdlLCBpbiB3aGljaCBjYXNlIEkg bXVzdCBoYXZlIG1pc3NlZCB0aGVzZSDigKYgJm5ic3A7YXBvbG9naWVzIGlmIHNvKTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkVza288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Jb1Rjb25zdWx0YW5jeS5ubDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsgfCZuYnNwOyBFbWFp bC9UZWFtczoNCjxhIGhyZWY9Im1haWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5lc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw8L3Nw YW4+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9ImVuLU5MIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM8P190MB09798CB94C780DBB8DD718CBFD070AM8P190MB0979EURP_-- From nobody Fri Oct 16 16:32: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 91DA13A0965; Fri, 16 Oct 2020 16:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOlLTV6HgEJt; Fri, 16 Oct 2020 16:32:21 -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 1596E3A0978; Fri, 16 Oct 2020 16:32:19 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CCj9Y6g7szyX6; Sat, 17 Oct 2020 01:32:17 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 624583937.127264-88b71d10106123a895c57d7ea3ef9d06 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 17 Oct 2020 01:32:17 +0200 Message-Id: To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF109: DRAFT AGENDA 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, 16 Oct 2020 23:32:23 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF109. Remember that there is still quite some potential for changes. The conflicts that meet the eye this time seem to impact generalists = only. Great scheduling job! All times *on my agenda* are in UTC (the default page is UTC+0700). https://datatracker.ietf.org/meeting/agenda-utc might be handy. Note that both EU and US are on winter time (standard time) then. Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 9, 2020 0500-0700 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, November 13, 2020 0500-0700 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, November 16, 2020 0500-0700 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 3 IRTF qirg Quantum Internet Research Group Rm 5 RTG raw Reliable and Available Wireless WG Rm 6 SEC *** lake Lightweight Authenticated Key Exchange = WG 0730-0830 Session II Rm 3 INT add Adaptive DNS Discovery WG Rm 4 IRTF maprg Measurement and Analysis for Protocols Rm 7 SEC *** cose CBOR Object Signing and Encryption WG 0900-1100 Session III Rm 1 ART jsonpath JSON Path WG Rm 6 SEC secdispatch Security Dispatch WG Rm 7 TSV tsvwg Transport Area Working Group WG TUESDAY, November 17, 2020 0500-0700 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 2 INT 6man IPv6 Maintenance WG Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 0730-0830 Session II Rm 5 RTG babel Babel routing protocol WG Rm 6 SEC tls Transport Layer Security WG 0900-1100 Session III Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things WG Rm 2 IRTF irtfopen IRTF Open Meeting Rm 4 RTG apn Application-aware Networking BOF Rm 7 SEC *** rats Remote ATtestation ProcedureS WG WEDNESDAY, November 18, 2020 0500-0700 Session I Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services BOF Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 7 SEC *** ace Authentication and Authorization for = Constrained Environments WG Rm 8 TSV quic QUIC WG 0730-0830 Session II Rm 3 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 4 INT *** drip Drone Remote ID Protocol WG Rm 7 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 8 TSV tsvwg Transport Area Working Group WG THURSDAY, November 19, 2020 0500-0700 Session I Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC saag Security Area Open Meeting 0730-0830 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 RTG detnet Deterministic Networking WG Rm 5 SEC acme Automated Certificate Management = Environment WG 0900-1100 Session III Rm 4 OPS v6ops IPv6 Operations WG Rm 6 RTG *** roll Routing Over Low power and Lossy = networks WG Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG FRIDAY, November 20, 2020 0500-0700 Session I Rm 2 INT add Adaptive DNS Discovery WG Rm 6 RTG rift Routing In Fat Trees WG Rm 7 SEC emu EAP Method Update WG 0730-0830 Session II Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 INT *** lwig Light-Weight Implementation Guidance WG Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 6 SEC *** suit Software Updates for Internet of Things = WG Rm 7 TSV tsvarea Transport Area Open Meeting 0900-1100 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 2 INT 6man IPv6 Maintenance WG Rm 4 IRTF cfrg Crypto Forum Rm 7 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG From nobody Mon Oct 19 04:38:25 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 EA7523A0B3B; Mon, 19 Oct 2020 04:38:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160310749885.9021.13004247254810729275@ietfa.amsl.com> Date: Mon, 19 Oct 2020 04:38:18 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-fasor-01.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: Mon, 19 Oct 2020 11:38:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP Authors : Ilpo Jarvinen Markku Kojo Iivo Raitahila Zhen Cao Filename : draft-ietf-core-fasor-01.txt Pages : 15 Date : 2020-10-19 Abstract: This document specifies an alternative retransmission timeout and congestion control back off algorithm for the CoAP protocol, called Fast-Slow RTO (FASOR). The algorithm specified in this document employs an appropriate and large enough back off of Retransmission Timeout (RTO) as the major congestion control mechanism to allow acquiring unambiguous RTT samples with high probability and to prevent building a persistent queue when retransmitting. The algorithm also aims to retransmit quickly using an accurately managed retransmission timeout when link- errors are occuring, basing RTO calculation on unambiguous round-trip time (RTT) samples. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-fasor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-fasor-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-fasor-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-fasor-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 20 03:32: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 073793A1129 for ; Tue, 20 Oct 2020 03:32:17 -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 l6XbhUcl692D for ; Tue, 20 Oct 2020 03:32:14 -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 809273A0A9E for ; Tue, 20 Oct 2020 03:32:13 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2905F4012D; Tue, 20 Oct 2020 12:32:11 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 462FBAB; Tue, 20 Oct 2020 12:32:05 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:df5a:9992:c1e5:2358]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DC3F234; Tue, 20 Oct 2020 12:32:04 +0200 (CEST) Received: (nullmailer pid 319509 invoked by uid 1000); Tue, 20 Oct 2020 10:31:59 -0000 Date: Tue, 20 Oct 2020 12:31:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Esko Dijk Cc: "core@ietf.org" Message-ID: <20201020103159.GA311699@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 10:32:17 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Esko, (picking this to go first as it's the most visible of your comments, and thanks for all of them), On Mon, Oct 12, 2020 at 11:25:10AM +0000, Esko Dijk wrote: > [...] about =E2=80=9Canchor=E2=80=9D attributes in Link Format that seem = unnecessary. > Hoping this helps to make Link Format documents smaller in size. > > This is something I found after reviewing RD again after some years I > last looked at it. The issue with the redundancy between anchor and target is that the RFC6690 link format details about target and anchor are ... well we can argue about whether they are ambiguous, but they do conflate concepts (context and base), are hard to read, subtly different from the Link header and, most importantly, nobody ever implemented them right[1]. Consequently, a compatible subset of link-format and Link headers, that would be consumable by a wider range of devices, was added as Limited Link Format (in the RD appendix B). It's admittedly not great at compression, but at least it works with how people use link-format. Back when this was added, the hope was that nobody would practically use text-based link format anyway because links-json[2] (actually, -cbor) was on the brink of being published. It wouldn't have removed all the warts, but at least the most pressing ones about resolution. (It would still have kept the ASCII-delimited arrays for rt and if, and would not have had a way to set an inline base address, as you'd probably want to do when returning more than two links from a single endpoint). The document was withdrawn to avoid churn anticipating a more powerful solution to the problem (CoRAL), which hasn't landed yet. (Avoiding too many formats war also why Limited Link Format was born: We could have done a 6690bis, but feared it'd delay RD too much (hah, anticipating a publication in 2019), and it would only delay a proper solution that doesn't need to be held back by the link-format decisions.) Does this, to you, explain and justify the choices made about the link-format representations? KR Christian [1]: https://mailarchive.ietf.org/arch/msg/core/D_kuIq6QoBZ86FNniN7G_6d1Rtg/ [2]: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+OvJwACgkQOY0REtOk veFeihAAl5iSKrQW9ig4ltriePjaQjZzp4gR5kZ5J4Wu+rV3Tnp1qTo5Br0V6mlQ gPBqKJPCx5Q6KSHbkG1mOE46VwutOdZaiAQikAa6uxYuRv0fFGJhC67bJvuz06q0 0fmDibWYiyAfnZyI2zv3KhPpIzz+oAP68Cxj6MSTq17dDlibwn2M+KmO+m1gPYkp q2PdahCkjsJvdnHryjbNcpHaZ/rMAF8jxa8MEqldSEyKtHJS35Gq2Co8SSzvtdwc 6UuVpWnwnDqRUwO3h7kvOZuAWdPUN3iDXFp68SDL3PnTj7i1GMB2CYs3GdgfG6Ec FMjT1uzzPTMN1rzRHcCbfA+HYIStR1KR4+FH1bfzMGWIqEbxXIqDhX3uRrGB9wss FfcfbMGtBlBRa68AJL3U2+l79HBvtxc6QF85domvNxVyJR7GohhXm3hTYsCFyElD S/p+zcL2WXZbk85rdUSPtaYJw0XgkgNF9rNgCSz3lekwOQs0WVDJW0psviz+H4Z9 HqsGMltcPjK+ejei2bDmQb2UNzgnxLqVADjoPjbKgOouImBSost705vziuI8AmpR MrkqBeMwZY13hnX5dmJe/2EWqxAFywMFBB0IB/H4jiuNDJ3IR+ZslomZ8fTSivcH zmxivCQ82EGNB4mzycN/E6xmv7NdD+P/ELBadiArq7oGtFO8uoI= =SBz8 -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From nobody Tue Oct 20 08:17: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 DE5103A105B for ; Tue, 20 Oct 2020 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 MUAxU-GzGaEj for ; Tue, 20 Oct 2020 08:17:32 -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 EAF123A1051 for ; Tue, 20 Oct 2020 08:17:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 631AA38990 for ; Tue, 20 Oct 2020 11:23:42 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xI0X-7n_zVuA for ; Tue, 20 Oct 2020 11:23:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CF5A38988 for ; Tue, 20 Oct 2020 11:23:41 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1D43F1CC for ; Tue, 20 Oct 2020 11:17:29 -0400 (EDT) To: core@ietf.org References: <30317.1601403281@localhost> From: Michael Richardson Message-ID: Date: Tue, 20 Oct 2020 11:17:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <30317.1601403281@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] issues for stateless AD review 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, 20 Oct 2020 15:17:34 -0000 On 2020-09-29 2:14 p.m., Michael Richardson wrote: > > With Klaus' blessing, I have turned the remaining DISCUSS points into issues. > I list them below. > I will begin posting them to the list for discussion in an hour or so along > with some proposed changed text (pull requests). > > Barry: Quite a number of points were already dealt with, but we need confirmation > from the AD that they were dealt with. If needed, I can collect those into > an email. > > It seems that all of the comments from Roman were dealt with, possibly with > the exception of issue 9 ("look ma, no state"), which seems like a "wontfix". > > Roman had cleared his DISCUSS. > The second DISCUSS was from Erik Kline. > > Here is the list of issues. The titles are mine. At this point, I would like to ask the WG to declare the work done. There is one more pull request that could use some endorsement/review https://github.com/core-wg/stateless/pull/11 I'd like to post a new ID tomorrow. From nobody Tue Oct 20 17:03: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 E8F183A0A68 for ; Tue, 20 Oct 2020 17:03: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 MWmsAJ53rG0Y for ; Tue, 20 Oct 2020 17:03:34 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDA13A0A64 for ; Tue, 20 Oct 2020 17:03:33 -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 E13E54012D for ; Wed, 21 Oct 2020 02:03:30 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 19D2AAB for ; Wed, 21 Oct 2020 02:03:28 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:b5e3:21a5:c6eb:f5c2]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8DB40121 for ; Wed, 21 Oct 2020 02:03:27 +0200 (CEST) Received: (nullmailer pid 483397 invoked by uid 1000); Wed, 21 Oct 2020 00:03:27 -0000 Date: Wed, 21 Oct 2020 02:03:27 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Core WG mailing list Message-ID: <20201021000327.GB303030@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline Archived-At: Subject: [core] (not only) RD: Authorized servers 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, 21 Oct 2020 00:03:37 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, one of the outstanding issues in RD is server authorization with respect to operations on particular paths. This continues an ACE thread[1] I regrettably missed to follow up on, but simplifies the examples based on the recent interims. While originally phrased as the attacker tricking the server into using the client's good credentials for something the client did not intend, here they are phrased now in terms of server authorization as relevant for RD discovery and RD security policies. For two examples, a client needs to trust a server to provide a service, but has received misleading hints that cause disagreement between the client and the server about the performed operation. Example 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D An RD with a "links are confidential" policy also operates a bulletin board at `/bb`. During the unprotected discovery phase, the endpoint is fed a link `;rt=3Dcore.rd`. The client connects to rd.example.com, verifies that its server credentials are good for an RD that will reveal links posted to it only to authorized lookup clients. It then posts all its links to /bb, where anyone who knows to use a bulletin board can read them. Example 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D A time server also exposes its current core temperature as `/monitoring/temp`. A malicious RD operator modifies the time server's registration to read `;rt=3Dunixtime`. A starting device in the network asks the RD for any rt=3Dunixtime, verifies that time.example.com is indeed authorized to give the right time, and wakes up on the morning of January 1st, 1970. Problem summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The client has an abstract intention with an operation, which it checks against the server's authorization. Then it forms that intention, with additional unverified knowledge about the server, into a request, which it protects. The server then reconstructs that intention with its authoritative knowledge of itself, and uses any client provided credentials to act on it. If the client's knowledge about the server is erroneous, the intentions are misaligned. Neither is the intention protected, nor does the client point out the claims it wants to hold the server to in its request (or, in the original examples from the ACE thread, express the precise claims about itself it intends the server to assess). Solution approaches =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the ACE thread back then, Jim said that he'd expect the client to use different keys (originally in talking to the AS, and thus different keys in talking to the RS). Doing that to the end would probably result in the devices having to handle a lot more keys, something like one for any operation that could be mixed up with any other? Michael in the last interim mentioned that in OAuth it's common to only run one service on one host for the very same reason. Kind of boils down to the same thing, as virtual-hosting these services would create multiple keys. My approach in the -25 RD Section 7.2 is to (losely, there; would need stronger and more precise wording) say that any information that any information using which intention is encoded in the request in a lossy way is to be rechecked from the origin server. That'd be more or less straightforward for example 1, but incur an additional costly recheck with the origin server about many things that could be learned efficiently from the RD. Does any of that solve the issues? Can we do any better? How do we put that into RD to satisfy the small comment about Section 7.2 that opens this can of worms? Is there anything quotable on OAuth's best practices on multiple services on the same host? Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/ace/TLIbCfU0unm1el99Kjo2eoB37Qw/ --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+PesoACgkQOY0REtOk veFt5Q//Zx7ehXePYha87rvxmgSU+Dh0eXruY36vrL9gfQP05s9cpRDQnVWmlOE9 KR7JiVXPjapEQKWNkTSiPgl1Hs/kn2vN6nq2jZyCMtv9tkDcErT9c8NBPQKP++IE cmaaqX7ct9tKm4cFFO7jMZxdJGHmaPjaUuDz/ZsLLKUCzTxpsWN4GvLFe+ee+zzV TzmD+1lODEcZ4vIIz5iKN3fh66oadVnsoqYYpAW6M9W3GMCPWtnR4ge2N07MG2B5 w1YSo9tuclKT+ZagqMgYkv07CtbDlgK6HkkoG9sHM9DP//V0C9tZ03d02Z2nMO7M XJGaStUeMkWCI8xoDRICk9Qefgd/AYQm5k0K+W/DIWL1CIpQW1ICP6zNgQ0WiBQp An3Ujq2Mz8kLObnT40X6amnofFNcMNkW45/BgLe0FXG+8HcVOuJr9ur/u6+JUds3 PHGO67vMulu8f5AXr1vqA6JzGUPIaPhPQG2S99UlXQ9/QnOAhUgAZ8kY9feXxIpr KGzAP0IdAs2ZZHrx+lWe7phD8BzhbI9TLqvXVX4co5B7P1W0P88/E6nB2MGkWFnv l/HhRJ5IJSL2iOPKJOzd+fis7KyeZpZivMF0sn+6C0U3yKrIBSi59lUgebB9ffad CFEhkOTcJl1N4RQL0P3Rovfj+14QkIivhv61pWXprvtyNB6ypdo= =6zxS -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From nobody Tue Oct 20 17:10:25 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 568713A0AD9 for ; Tue, 20 Oct 2020 17:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O7EPMX-zHnWT for ; Tue, 20 Oct 2020 17:10:21 -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 3C5AB3A0ACB for ; Tue, 20 Oct 2020 17:10:21 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 34C424012D for ; Wed, 21 Oct 2020 02:10:19 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 93E2AAB for ; Wed, 21 Oct 2020 02:10:17 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:b5e3:21a5:c6eb:f5c2]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E9DC6121 for ; Wed, 21 Oct 2020 02:10:16 +0200 (CEST) Received: (nullmailer pid 485357 invoked by uid 1000); Wed, 21 Oct 2020 00:10:15 -0000 Date: Wed, 21 Oct 2020 02:10:15 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Core WG mailing list Message-ID: <20201021001015.GA483775@hephaistos.amsuess.com> References: <20201021000327.GB303030@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20201021000327.GB303030@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] (not only) RD: Authorized servers 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, 21 Oct 2020 00:10:23 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =2E.. and I missed to capture Carsten's input from the interim: On Wed, Oct 21, 2020 at 02:03:27AM +0200, Christian M. Ams=FCss wrote: > Solution approaches > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carsten suggested that the server's claims should be more precise about its paths, promising to keep links confidential *when posted in RD registrations to /rd* and to serve time *when requested from /time*. For example 2, this would roughly mean that the information that would need to be obtained in the "verify again with origin server" model is contained in the certificate, or more generally in the sets of claims exchanged about the server at some point. KR Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+PfGcACgkQOY0REtOk veGZbBAAlTOglTfwWWpYxKYn3ZlAcJVxtvbm77WA1Y6Zj2vEoqURndlRvW5e7eqy d+lzTv+KvkIYRBE0qnb+jHAZsIDmKvvBMhqTyCveorZZ/q6B5LgjbmrA84AaytYL x6ck8+jmYkaCYmhjdZ8+SorkgJ87+mjq0P6yIq4L7kPsnpkoUgxajruqSwaJZSmT n9R+yojeDb5btOemOfesc/IEkSRj9WZ4s92ppJADDqJbyybJZQ4OBSUcNi1CLa8i NyKYA9o+ftQPnevIsmMs4dWB3rWhs9IUPMXYstrRl+urMA7/1beRtHQK/kb9/Eh2 II/2RocooEo1RwDZ1Uw4MLR5yUJXDIAptG+0DGoP38wrpjpeYsl97KmthUNHsCrm EsIQhdSb+3sEGvbJC6W+Zo51EMth8GJLO1wyHFjXpHW0StX37DAlK88HzURwXJLb IDfGyqNuPvSJOs4w2X0xIHPlR0WORPvQ8DmYZNsss/WMlXcKNGvRtv9QZSOegDx2 9KQJ+nkwBb3O8HuZDOfYGICxCkX8CjKuWrWn6TUxgt9oQ+TyubcSfWpelgKtcMww h3XN6IRxKzIouBlv3bSf4ll6+8mkLzlfdnVrElsPT1AoStOOMbf/VyE3rbMBCrBq MpqL94B+jJnlSwWJUlVVIuWV3SbekcyJGUV1I3Ib1+TbkjjHn3U= =MZOf -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From nobody Wed Oct 21 02:46:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAED3A1579 for ; Wed, 21 Oct 2020 02:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjpdMWudlZUH for ; Wed, 21 Oct 2020 02:46:52 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70122.outbound.protection.outlook.com [40.107.7.122]) (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 24AD23A1562 for ; Wed, 21 Oct 2020 02:46:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=avLAGNxPo8DQbPju786FsAioCykcFJ3Iw3LlUIWR5ZCb1tyEVHayulcmdqrZeY8e/69PurpSA1yFLBegavQT5YSGNr+Knk54g3JUOD68odUZDd+gevoK42PatHwq2YxipjeAibDYc9s9pjmRFZx5S+eEp8phF5vJ36geHf+ezUU9fkeNL6eJ7cwdzOCCLsmmo8KkW3vUCIV/KeKU5JEdyjgZOx6L3CDRSUT3tjmouTumIa2LUckabylU0SgB7quQqN2FzGv4J4qVK/U7HMq4lW7V6LDfv2P5Qbh6ckRHjxWbAbTds9xZ2JpHafWp+aTROqt4e4Ay2aGA1H6laVPwEQ== 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=eP4/mEOsufv2SvdezhSHnKl8U6Oq/PuUsKeq/52O704=; b=Hbd8sVsvioXdvvsfMPygfUCgHPh0NrV3SMLXpwMKx7skTR9nivKAUfpoJJKNNYvyXRIOYhn5uVczwWFfZYOFAJ3SEk8sP2jIML7nW4GguY3DUi9lE/jp0G3UUNzMgvLQQDX+zReDgO2phJvsPx7k/JdWYjEtqyaVz9Conor8bKQ3ADOqWiwFccv+/9/0EtA2u8yD3C1rWaiJQaFlws5xcUczjRthLZ7S6VWTIkYEwVGeNWqO7KgNLntntTvn03+YbKKO8sd/r9M9VtB2m9Kn33ssicm18dCwlGJYeEgvRBlXkXQVZMZeKUuPlnduE/LGGyLuQTSJUzkroyCsm9dVVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eP4/mEOsufv2SvdezhSHnKl8U6Oq/PuUsKeq/52O704=; b=rX5sKAXMUsO+BeQ1M2XQw5RS0AWj3BYCzU3hKfPRFuwmwzfHeBdaAnwfXE/KlGckWTFJhvmUpRv+jRE/RQqcZlzZkpeIPV7N8hJBTxO+8GsmF/EPosRCACZU1z0LBbc8B3fk4eINOH7yc/HdwuoMPox1OcsqOz1AzYkknfjWsiM= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0036.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.26; Wed, 21 Oct 2020 09:46:46 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3499.018; Wed, 21 Oct 2020 09:46:46 +0000 From: Esko Dijk To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "core@ietf.org" Thread-Topic: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? Thread-Index: AdagiZ7ddTpjV6VySOOkvoVV5WS9KQGQp6uAAC9rtEA= Date: Wed, 21 Oct 2020 09:46:46 +0000 Message-ID: References: <20201020103159.GA311699@hephaistos.amsuess.com> In-Reply-To: <20201020103159.GA311699@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:d030:cc1b:a030:56f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58e76211-a35a-46cc-88cb-08d875a639d5 x-ms-traffictypediagnostic: AM4P190MB0036: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lIzdpZK6V6Cu5OkpQoqSmLACil/RvfqJHAK9hqSiBxJ51O5gQHGuyeiqCAQDcYRgT5VHJk328hooZJtP+vnssae7dt4SmU9pJBVv5REUCpngmMUbqmlQZ+p2MpZy7TboGp2FaqFAtd7/bStBN87oaA7c9/cSaU4Z+57SvGez/j2SdcLuSNcncgZvpeVvWOkE2bex0zIAm6erHbb0w1gw0c90L1/gbjkvacvwwQBzgxkmAP2DPaCoqupPo8z7Np2TdN9EcLTbyVb1iKdkaLFl0FFWFxsUZmT/jWmPgBdED/dy4lvBQB91JrSoDIB+QNNSy7vN7qH3U4JvPriWoYaupktrvjdm/XC2jmRgTQDZqMlT9zGkeJX3D7rpJ1xkmhsgEXZyBByRFFRxNJWFhdT0KA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(136003)(376002)(346002)(366004)(396003)(86362001)(2906002)(9686003)(8936002)(478600001)(186003)(53546011)(6506007)(4326008)(44832011)(71200400001)(7696005)(52536014)(66446008)(5660300002)(76116006)(6916009)(966005)(66574015)(55016002)(8676002)(316002)(66556008)(64756008)(66476007)(33656002)(66946007)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rTbZNqM70WB/sbXUeOBqiEl40a09HdvuMFLl9Q3HGwicHQaOffrzShaVwsn4oce33rOiEZAC4rNm93uI9NnGmoC6wccZk1Q/ZpxzUQQkF8WewOJNcSYeTuMPCLFGRb+nwLaifDe/xVTGcynkUg2LbnbnihqY33iJOozZvluX90uu3Th6WWFsNjZ910lA5sCJP2InbUC2zflf7Qh2BNQ0RPdu6B+UwIoSqlWT5gAH3fG3jUlUDR/Tg80FLlQ+KqbDaPz6Er9ojHfbNISCvHwcR0PXwnZXYt6RtbzhhFXXcc8bPyI3HqfsG34iLiB9Xet24+/pI5q+wIY3amfHsP5LKabDSBStQZDMCZMMm6Wj/3ZiYDmKPakn/iM+mJFQooxTxSAwok2NI4/0jCzaca+tiBOXJhaWZHnl7HikRJv4hbfWU2dQmqhSn63ES7SVnw3KmH1pYi5vIpkuJfa61wt/wt9oLq6zNhfEYqI1ff+6lUefcY7K8XkmhtW/2vtPwuQvsPjJN+JFdnCuLQoTdeR5aPrWpT4KezDys85AmUEczXqUImjsklg/L2abcOVALG/TMVedlqjK0fXLNX6kdwjmJkOKxTDla2VYe6DSGXIyKRmxe0zi4WeTo6XW1FY1ZzKBQUFXon06A6bewfHiKZZdSXAhm9WJLnOl1Hb/TiSttDkpguCub6ASG/WRnAYz0Oz27QNjKuZEEry9yLnSk6ulbw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 58e76211-a35a-46cc-88cb-08d875a639d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 09:46:46.7196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7e14Vlk9oVsUmp7/etqaSub7XT0TEZz6ZuALlXeNEHzV339GCRu3Ylp/CEykkLt6154crVCqMcgYGzd9lai6qqsSRGKdnq0SD04FxWzL7L4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0036 Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 09:46:55 -0000 SGVsbG8gQ2hyaXN0aWFuLA0KDQpUaGFua3MgZm9yIHRoZSBiYWNrZ3JvdW5kIGluZm9ybWF0aW9u LiBXaGF0IEkgZG9uJ3QgdW5kZXJzdGFuZCBpcyB0aGF0IHlvdSBzZWVtIHRvIHNheSB0aGF0IExp bWl0ZWQgTGluayBGb3JtYXQgaXMgdGhlIGNhdXNlIG9mIGEgbGVzcyBlZmZpY2llbnQgZW5jb2Rp bmcgb2YgbGluayBmb3JtYXQgcGF5bG9hZHMuDQpXaGVuIEkgbG9vayBpbnRvIEFwcGVuZGl4IEMg KEdpdGh1YiBtYXN0ZXIgYnJhbmNoIC5tZCkgSSBkb24ndCBzZWUgYW55IHJ1bGVzIHRoYXQgdGhl cmUgbXVzdCBiZSBhbiBhbmNob3IgcHJlc2VudCBpbiBwYXJ0aWN1bGFyIGNhc2VzLiBBbmQgSSBk b24ndCBzZWUgcnVsZXMgdGhhdCBjaGFuZ2Ugb3Igc2ltcGxpZnkgU2VjdGlvbiAyLjEgb2YgUkZD IDY2OTAuDQoNCkkgYWdyZWUgdGhhdCBMaW5rIEZvcm1hdCBjYW4gYmUgdHJlbWVuZG91c2x5IGNv bXBsZXggd2hlbiBhbGwgaXRzIGZlYXR1cmVzIGFyZSBiZWluZyB1c2VkLCBhbmQgaXQgaXMgaGFy ZCB0byBnZXQgaXQgcmlnaHQgaW4gdGhpcyBjYXNlLiBBbmQgeWVzIGl0IGhhcyBwYXJ0aWN1bGFy IGZsYXdzIChlLmcuIHRyZW1lbmRvdXNseSBpbmVmZmljaWVudCB3aGVuIGluZGljYXRpbmcgb3Zl ciBjb2FwOi8vIHJlc291cmNlcyBob3N0ZWQgb24gdGhlIHNhbWUgaG9zdCB1bmRlciBjb2Fwczov LyApIA0KQnV0IEkgYWxzbyBzZWUgdGhhdCB0aGUgYmFzaWMgaWRlYSBvZiBsaW5rIGZvcm1hdCBm b3IgY29uc3RyYWluZWQgZGV2aWNlcyBpcyBqdXN0IHRvIHVzZSBtb3N0bHksIG9yIGV4Y2x1c2l2 ZWx5LCB0aGUgImhvc3RzIiByZWxhdGlvbiB3aGljaCBpcyB0aGUgZGVmYXVsdC4NCkluIHRoaXMg Y2FzZSB5b3UgZ2V0IG5vdGhpbmcgbW9yZSBvciBsZXNzIHRoYW4gYSBsaXN0IG9mIHJlc291cmNl cywgd2l0aCBzb21lIG9wdGlvbmFsIGF0dHJpYnV0ZXMgd2l0aCBpdCB0aGF0IGRlc2NyaWJlIGUu Zy4gY29udGVudCBmb3JtYXQgYW5kIHJlc291cmNlIHR5cGUgc2VtYW50aWNzLg0KDQpTdWNoIGEg bGlzdCBvZiByZXNvdXJjZXMgaXMgcXVpdGUgc3RyYWlnaHRmb3J3YXJkIHRvIGdlbmVyYXRlLCB0 byBwYXJzZSwgYW5kIHRvIGdldCByaWdodCBJIGJlbGlldmUuDQoNClNvIHdoYXQgdGhlIExpbWl0 ZWQgTGluayBGb3JtYXQgQXBwZW5kaXggY291bGQgZGVmaW5lIGluIGFkZGl0aW9uIGlzIHRoZSBm b2xsb3dpbmcgcnVsZToNCiogImFuY2hvciIgYXR0cmlidXRlIE1VU1QgTk9UIGJlIHByZXNlbnQg Zm9yIGEgbGluayB3aXRoIHRoZSAiaG9zdHMiIHJlbGF0aW9uICAgKGkuZS4gdGhlIGRlZmF1bHQg cmVsYXRpb24gaWYgbm9uZSBzcGVjaWZpZWQpDQoNClRoaXMgd2lsbCBsZWFkIHRvIHRoZSBkZXNp cmVkLCBhbmQgb3JpZ2luYWxseSBpbnRlbmRlZCwgc29sdXRpb24gZm9yIElvVCBkZXZpY2VzIHRo YXQgbm90aGluZyBtb3JlIHRoYW4gYSBsaXN0IG9mIFVSSXMgaXMgY29tbXVuaWNhdGVkIHdpdGgg b3B0aW9uYWwgc2VtYW50aWMgYXR0cmlidXRlcy4NCg0KU28gYSBkZXZpY2Ugc2VydmluZyBpdHMg b3duIGxpbmtzIHdvdWxkIHJlc3BvbmQgcmVsYXRpdmUgbGlua3MgZS5nLg0KPC9zZW5zb3JzL3Rl bXA+O3J0PXRlbXBlcmF0dXJlLWM7aWY9InNlbnNvciIsDQo8L3NlbnNvcnMvbGlnaHQ+O3J0PWxp Z2h0LWx1eDtpZj0ic2Vuc29yIg0KDQpUaGlzIGlzIHNpbXBsZSB0byBpbnRlcnByZXQgYXMgInJl c291cmNlcyBhcmUgaG9zdGVkIG9uIHRoZSBzYW1lIENvQVAgZW5kcG9pbnQiLg0KDQpBIGRldmlj ZSBsaWtlIGFuIFJEIHNlcnZpbmcgb3RoZXIncyBsaW5rcyB3b3VsZCByZXNwb25kIHdpdGggYWJz b2x1dGUgbGlua3MgZS5nLg0KPGNvYXA6Ly9uZXcuZXhhbXBsZS5jb20vc2Vuc29ycy90ZW1wPjty dD10ZW1wZXJhdHVyZS1jO2lmPSJzZW5zb3IiLA0KPGNvYXA6Ly9uZXcuZXhhbXBsZS5jb20vc2Vu c29ycy9saWdodD47cnQ9bGlnaHQtbHV4O2lmPSJzZW5zb3IiDQoNClRoaXMgaXMgYWxzbyBzaW1w bGUgdG8gaW50ZXJwcmV0IGFzICJyZXNvdXJjZXMgYXJlIGhvc3RlZCBhdCB0aGUgc3BlY2lmaWVk IENvQVAgZW5kcG9pbnQiLg0KQWRkaW5nIGFuICJhbmNob3IiIGF0dHJpYnV0ZSB0byB0aGUgYWJv dmUgbGlzdCB3b3VsZCBvbmx5IGNvbmZ1c2UgdGhpbmdzIGFuZCB0aGUgcmVxdWVzdGluZyBjbGll bnQgLS0gaWYgYW4gSW9UIGRldmljZSAtLSB3b3VsZG4ndCBhbnlob3cgdXNlIHRoaXMgaW5mb3Jt YXRpb24hIFNlZSBTZWN0aW9uIDIuMyBvZiBSRkMgNjY5MC4NCg0KVG8gbWUsIGl0IHNlZW1zIHdl IGNhbiBtYWtlIExpbmsgRm9ybWF0IG1vcmUgbGltaXRlZCwgYW5kIHNpbXBsZXIsIGFuZCBtb3Jl IGVmZmljaWVudCBhdCB0aGUgc2FtZSB0aW1lLCBieSB0aGUgYWJvdmUuIEFuZCBpdCB3b3VsZCBh bHNvIGJlIGEgdHJ1ZSBzdWJzZXQgb2YgUkZDIDY2OTAgTGluayBGb3JtYXQuDQoNClRvIG1ha2Ug dGhpbmdzIG1vcmUgY2xlYXIgLCBhbmQgbW9yZSBzdWJzZXQsIG9uZSBjYW4gYWxzbyBjb25zaWRl ciB0byBhZGQgdGhlIGJlbG93IHJ1bGU6DQoqICJhbmNob3IiIGF0dHJpYnV0ZSBNVVNUIGJlIHBy ZXNlbnQgZm9yIGEgbGluayB0aGF0IHNwZWNpZmllcyBhIHJlbGF0aW9uICgicmVsIikgYXR0cmli dXRlLiAgIChJLmUuLCB0aGF0IGluY2x1ZGVzIGEgInJlbCIgYXR0cmlidXRlIC0gYW5kIGRvZXMg bm90IHVzZSB0aGUgaW1wbGljaXQgImhvc3RzIiByZWxhdGlvbi4pDQoNClNvIHRoaXMgbWFrZXMg aXQgY2xlYXIgdGhlcmUgYXJlIDIgdHlwZXMgb2YgbGlua3MgcG9zc2libGU6DQoxKSBTaW1wbGUg Imhvc3RzIiBsaW5rcyB0aGF0IGp1c3Qgc3BlY2lmeSB0aGUgcmVzb3VyY2UgKHJlbGF0aXZlIG9y IGFic29sdXRlKSAtIGFsc28gSW9UIGRldmljZXMgY2FuIHBhcnNlIHRoZXNlIGFzIGEgbGlzdCBv ZiBsaW5rcy9yZXNvdXJjZXMgd2l0aG91dCBmb3JtaW5nIHNlbWFudGljIFJERiB0cmlwbGVzIGlu dGVybmFsbHkgOikNCjIpIE1vcmUgY29tcGxleCBsaW5rcyAoICdzdWJqZWN0JyA8cmVsYXRpb24+ ICdvYmplY3QnIC0gc2VtYW50aWMgc3RhdGVtZW50cykgdGhhdCBJb1QgZGV2aWNlcyBhcmUgbm90 IGV4cGVjdGVkIHRvIHBhcnNlLCBidXQgbW9yZSBwb3dlcmZ1bCBkZXZpY2VzIGNvdWxkLiBFLmcu IGEgQ29tbWlzc2lvbmluZyBUb29sLiAgQW5kIHRoZXJlIHdvdWxkIG5vdCBiZSBjb25mdXNpb24g YXMgdG8gd2hhdCB0aGUgJ3N1YmplY3QnIGlzIGJlY2F1c2UgdGhhdCdzIGFsd2F5cyBzcGVjaWZp ZWQgaW4gdGhlIGxpbmsuDQoNCg0KT3ZlcmFsbCBJIGRvIG5vdCBzZWUgeWV0IGEgZ29vZCByZWFz b24gd2h5IHRoZSAiYW5jaG9yIiBhdHRyaWJ1dGUgaXMgdGhlcmUgaW4gdGhlIFJEIGRyYWZ0IC0g Z2l2ZW4gdGhhdCB0aGUgc2ltcGxlIElvVCBjbGllbnQgbWF5IGp1c3QgaWdub3JlIGl0IChTZWN0 aW9uIDIuMyBvZiBSRkMgNjY5MCkgYW5kIGdpdmVuIHRoYXQgdGhlIEFwcGVuZGl4IEMgZG9lc24n dCBjaGFuZ2UgdGhlIGludGVycHJldGF0aW9uIHJ1bGVzIChlLmcuIFNlY3Rpb24gMi4xIG9mIFJG QyA2NjkwKS4NCkNvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB3aHkgaXQgd291bGQgYmUgdXNlZnVs IG9yIGdvb2QgdG8gaGF2ZSB0aGUgImFuY2hvciIgYXR0cmlidXRlIHRoZXJlIGZvciB0aGUgImhv c3RzIiByZWxhdGlvbj8gICBJbmNsdWRpbmcgdGhpcyBzZWVtcyB0byBtYWtlIGl0IG1vcmUgcmF0 aGVyIHRoYW4gbGVzcyBjb21wbGV4IEkgZmVhci4NCg0KT2YgY291cnNlIGlmIHdlIGV4cGVjdCB0 aGlzIExpbWl0ZWQgTGluayBGb3JtYXQgaXNuJ3QgZ29pbmcgdG8gYmUgdXNlZCBtdWNoIGJlY2F1 c2UgQ29yYWwgd2lsbCBldmVudHVhbGx5IHJlcGxhY2UgaXQsIG91ciBkaXNjdXNzaW9uIG1heSBi ZSBsZXNzIHVzZWZ1bC4gDQoNCkJlc3QgcmVnYXJkcw0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQ2hyaXN0aWFuIEFtc8O8c3MgPGNocmlzdGlhbkBhbXN1ZXNzLmNv bT4gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIwLCAyMDIwIDEyOjMyDQpUbzogRXNrbyBEaWpr IDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+DQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtjb3JlXSBVbm5lY2Vzc2FyeSAiYW5jaG9yIiBhdHRyaWJ1dGVzIGluIGRyYWZ0LWll dGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMjUgPw0KDQpIZWxsbyBFc2tvLA0KDQoocGlja2lu ZyB0aGlzIHRvIGdvIGZpcnN0IGFzIGl0J3MgdGhlIG1vc3QgdmlzaWJsZSBvZiB5b3VyIGNvbW1l bnRzLCBhbmQNCnRoYW5rcyBmb3IgYWxsIG9mIHRoZW0pLA0KDQpPbiBNb24sIE9jdCAxMiwgMjAy MCBhdCAxMToyNToxMEFNICswMDAwLCBFc2tvIERpamsgd3JvdGU6DQo+IFsuLi5dIGFib3V0IOKA nGFuY2hvcuKAnSBhdHRyaWJ1dGVzIGluIExpbmsgRm9ybWF0IHRoYXQgc2VlbSB1bm5lY2Vzc2Fy eS4NCj4gSG9waW5nIHRoaXMgaGVscHMgdG8gbWFrZSBMaW5rIEZvcm1hdCBkb2N1bWVudHMgc21h bGxlciBpbiBzaXplLg0KPg0KPiBUaGlzIGlzIHNvbWV0aGluZyBJIGZvdW5kIGFmdGVyIHJldmll d2luZyBSRCBhZ2FpbiBhZnRlciBzb21lIHllYXJzIEkNCj4gbGFzdCBsb29rZWQgYXQgaXQuDQoN ClRoZSBpc3N1ZSB3aXRoIHRoZSByZWR1bmRhbmN5IGJldHdlZW4gYW5jaG9yIGFuZCB0YXJnZXQg aXMgdGhhdCB0aGUNClJGQzY2OTAgbGluayBmb3JtYXQgZGV0YWlscyBhYm91dCB0YXJnZXQgYW5k IGFuY2hvciBhcmUgLi4uIHdlbGwgd2UgY2FuDQphcmd1ZSBhYm91dCB3aGV0aGVyIHRoZXkgYXJl IGFtYmlndW91cywgYnV0IHRoZXkgZG8gY29uZmxhdGUgY29uY2VwdHMNCihjb250ZXh0IGFuZCBi YXNlKSwgYXJlIGhhcmQgdG8gcmVhZCwgc3VidGx5IGRpZmZlcmVudCBmcm9tIHRoZSBMaW5rDQpo ZWFkZXIgYW5kLCBtb3N0IGltcG9ydGFudGx5LCBub2JvZHkgZXZlciBpbXBsZW1lbnRlZCB0aGVt IHJpZ2h0WzFdLg0KDQpDb25zZXF1ZW50bHksIGEgY29tcGF0aWJsZSBzdWJzZXQgb2YgbGluay1m b3JtYXQgYW5kIExpbmsgaGVhZGVycywgdGhhdA0Kd291bGQgYmUgY29uc3VtYWJsZSBieSBhIHdp ZGVyIHJhbmdlIG9mIGRldmljZXMsIHdhcyBhZGRlZCBhcyBMaW1pdGVkDQpMaW5rIEZvcm1hdCAo aW4gdGhlIFJEIGFwcGVuZGl4IEIpLiBJdCdzIGFkbWl0dGVkbHkgbm90IGdyZWF0IGF0DQpjb21w cmVzc2lvbiwgYnV0IGF0IGxlYXN0IGl0IHdvcmtzIHdpdGggaG93IHBlb3BsZSB1c2UgbGluay1m b3JtYXQuDQoNCkJhY2sgd2hlbiB0aGlzIHdhcyBhZGRlZCwgdGhlIGhvcGUgd2FzIHRoYXQgbm9i b2R5IHdvdWxkIHByYWN0aWNhbGx5IHVzZQ0KdGV4dC1iYXNlZCBsaW5rIGZvcm1hdCBhbnl3YXkg YmVjYXVzZSBsaW5rcy1qc29uWzJdIChhY3R1YWxseSwgLWNib3IpDQp3YXMgb24gdGhlIGJyaW5r IG9mIGJlaW5nIHB1Ymxpc2hlZC4gSXQgd291bGRuJ3QgaGF2ZSByZW1vdmVkIGFsbCB0aGUNCndh cnRzLCBidXQgYXQgbGVhc3QgdGhlIG1vc3QgcHJlc3Npbmcgb25lcyBhYm91dCByZXNvbHV0aW9u LiAoSXQgd291bGQNCnN0aWxsIGhhdmUga2VwdCB0aGUgQVNDSUktZGVsaW1pdGVkIGFycmF5cyBm b3IgcnQgYW5kIGlmLCBhbmQgd291bGQgbm90DQpoYXZlIGhhZCBhIHdheSB0byBzZXQgYW4gaW5s aW5lIGJhc2UgYWRkcmVzcywgYXMgeW91J2QgcHJvYmFibHkgd2FudCB0bw0KZG8gd2hlbiByZXR1 cm5pbmcgbW9yZSB0aGFuIHR3byBsaW5rcyBmcm9tIGEgc2luZ2xlIGVuZHBvaW50KS4gVGhlDQpk b2N1bWVudCB3YXMgd2l0aGRyYXduIHRvIGF2b2lkIGNodXJuIGFudGljaXBhdGluZyBhIG1vcmUg cG93ZXJmdWwNCnNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIChDb1JBTCksIHdoaWNoIGhhc24ndCBs YW5kZWQgeWV0Lg0KDQooQXZvaWRpbmcgdG9vIG1hbnkgZm9ybWF0cyB3YXIgYWxzbyB3aHkgTGlt aXRlZCBMaW5rIEZvcm1hdCB3YXMgYm9ybjogV2UNCmNvdWxkIGhhdmUgZG9uZSBhIDY2OTBiaXMs IGJ1dCBmZWFyZWQgaXQnZCBkZWxheSBSRCB0b28gbXVjaCAoaGFoLA0KYW50aWNpcGF0aW5nIGEg cHVibGljYXRpb24gaW4gMjAxOSksIGFuZCBpdCB3b3VsZCBvbmx5IGRlbGF5IGEgcHJvcGVyDQpz b2x1dGlvbiB0aGF0IGRvZXNuJ3QgbmVlZCB0byBiZSBoZWxkIGJhY2sgYnkgdGhlIGxpbmstZm9y bWF0DQpkZWNpc2lvbnMuKQ0KDQpEb2VzIHRoaXMsIHRvIHlvdSwgZXhwbGFpbiBhbmQganVzdGlm eSB0aGUgY2hvaWNlcyBtYWRlIGFib3V0IHRoZQ0KbGluay1mb3JtYXQgcmVwcmVzZW50YXRpb25z Pw0KDQpLUg0KQ2hyaXN0aWFuDQoNClsxXTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9jb3JlL0Rfa3VJcTZRb0JaODZGTm5pTjdHXzZkMVJ0Zy8NClsyXTogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLWxpbmtzLWpzb24vDQoNCi0t IA0KVG8gdXNlIHJhdyBwb3dlciBpcyB0byBtYWtlIHlvdXJzZWxmIGluZmluaXRlbHkgdnVsbmVy YWJsZSB0byBncmVhdGVyIHBvd2Vycy4NCiAgLS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0K From nobody Wed Oct 21 03:52: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 442F73A160A for ; Wed, 21 Oct 2020 03:52:58 -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 Kjrs8nRIpk5E for ; Wed, 21 Oct 2020 03:52:55 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2078.outbound.protection.outlook.com [40.107.21.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 0E5EB3A157E for ; Wed, 21 Oct 2020 03:52:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZbRTPRBoO7x+0N7kKrHLPzz1LQYpROfM3e4GgGbrttl3bdulDL0ylHdmRwJsc3qQ7zF0JozETfMRcdXwfNgzCuHEOjfiis/CaOXHhguHgqrjmbltQNZlLgp5fNgUF+mZ/vgmUB/mAb7/VNSEKuiHnQaqK/bLoyp3tehrwIpDitac2spj623+6gBY9plxccJzwYAE541IH29NEfudOCMIozeJBmVxJwtw+Ha5IeKjgg4vbbQzO4downJLHIP0rU1igj2+6v8F23zSMzSjuYpz9s2fyxaLDVcf+1e47dj3pU8gVDC3q0lNZmsT6wdUExFTSRm0gr6tL5a2Bl+epd5WWw== 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=rGTE2lHy9dVOK6vhwb+EXzIvCdER8FDBMkVN3SniTFQ=; b=T07aWkMd+WVZwWxNcqvf2JoxUtIFZshr3fVdbQolKS5C3cSbOLoj5n/mWhK4aHffdxf05IrUqmKlUG/nB0iS/KFnZiyzAEN3DDvrMdC7ZMK23f2E90NDBOwgZHfrBhZySxFDvnA45Lml85JeUVaS5u/22H0BjdC4eZhaValmIVtb3cSH04u87OB0tRjyABcCjG3VoPstfeYU9cPXhmqnoW7c3LnYe4rIHbm4/VcpQyHzMHKNgmrx9X6PB1bt3H3KmHCvj6XA0KAA8O2fmiSVd0JXVWoYWdHs7E0Va2DnSrX+N/QAPNq0QlmjhYcEIMDNnN3RrQqAHLYfRY4ziaNZuA== 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=rGTE2lHy9dVOK6vhwb+EXzIvCdER8FDBMkVN3SniTFQ=; b=LjUeZiqpy15SYQhVHekbkhGVrzBoIxvPFgBxkzltZKXwE/3QdKVEZJLG0Udmi9kDeBhJ3UkRL0k6rjOcDneZjrFP12r+t0AZT4mIPtGOA9C6DCflbG6VdDfJLiLnf7xcUrBhDNF6mS/FDm/xS2msJnMn7dd39ymqfZdJ0/B359Y= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0603.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fd::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 21 Oct 2020 10:52:50 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3477.029; Wed, 21 Oct 2020 10:52:50 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <0ba0173e-29ae-0449-9be6-f954f6e46ed2@ri.se> Date: Wed, 21 Oct 2020 12:52:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KjXa0knyszjwWBPOi9XzNDCMuKF0LgrfR" X-Originating-IP: [45.83.91.204] X-ClientProxiedBy: HE1P190CA0014.EURP190.PROD.OUTLOOK.COM (2603:10a6:3:bc::24) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.3] (45.83.91.204) by HE1P190CA0014.EURP190.PROD.OUTLOOK.COM (2603:10a6:3:bc::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Wed, 21 Oct 2020 10:52:50 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 62263446-8f23-4017-3bce-08d875af7449 X-MS-TrafficTypeDiagnostic: DB8P189MB0603: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4303; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1AXfDuAvg30sv6ssn3lNz90OenFJm8UgYxcwtMM1f98Rj7JGFUK/PhP9D8sKozBVBOUa0XVA7NMLfPP15zQtJodcG6W6KvNKSmxiau5OwcjHnLwXyJrjHsVCp+O1nGsvgqxObMMSLwhBCqhM4J6TqqyTsbsynSGISWgJ3fLMDprpx8zkwyaBldBT0fEnCc2cIW8F7EVxptFgvC1h2VnDfyj851q9iUJh9Hbp/4Qil8m4XgysyzDHM4Ui/vAA9eO60d8VYGiIxekasZzBupDsou9CdG6UiKEOoN1dY+MrbEcZsRjVlzrmj7liX84DOs19/r79/yK8CqfFfBZU2z1Rzl2MjOTJEHUSm1oCqJHiN/I2gGN1mMfD30uwJWYDMQhHjTWKZ5rFlkvBD9MNjFoH+4vXGetYfdjHKeSgF150n53oVubx+ksXsKqHmOWQrFGX4PBx7X9LeT8JuoXItVRIGw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(39850400004)(136003)(376002)(52116002)(33964004)(956004)(44832011)(86362001)(66556008)(66946007)(31696002)(6666004)(66476007)(36756003)(5660300002)(2906002)(83380400001)(235185007)(16576012)(66574015)(8936002)(316002)(6916009)(186003)(966005)(478600001)(26005)(16526019)(21480400003)(8676002)(16799955002)(2616005)(31686004)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: loWzv4GrR6TdkUYJM0yp1g0JWRaKooNtagotfIo6LVuOn35Try7ebFhcIJsUK3US/9aEVtsUyH6WsEUK7LQyof8C3leIx0eqyTLEvMsinKn/0k6abO2R4keTSeBWzPzcJR8IAvAtluqHPTeOI2AQeWzjptUTciwp2O4rfRRHCuTbKJAbbuzLdmWTNX/qbEYBY9fhPvZu/TyqnB3OzBTg7Jc2xdEGyWiagWzKa/Lpr7n7TxVYqRDiUTAb+9f4ZnPeSk4po+10TuZKE3Oyy9+K0CU6ZaVhKHsi8gY+lsiK1/USdt1PT9xsuueq7O7PRv35zlQVpXxx27oRvYILd4/u+NOH/XxxnHTiZ/+9tpd8VfCSotVyR6NuHZlU+RjuEHdUYjbC8LsaTkkXwee0aiUx8aL4YFc45z1QnjP9nrQ7Eei85+/0OeXJUwfkyrUXzTuzIXUwSZ6fNI/w/xJiRNSujYOf7xsqNQ3wlMpN+VpTAAJvVI5ul//XOnWQ+ZV1PoTT2n0OdAQVp5PVz7hUjttXs3/65+oHzUoIwR0+vbiZB29ya8gDf2X239qx7uqylEfKB8DN/Lg89Uk45h3hn34Ds/u43iYsP4JzwubA1FezEaPI8G6N3IIi/TJyJoxqqFkbCOK3rS7JDbJDcr9SOgBxCA== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 62263446-8f23-4017-3bce-08d875af7449 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2020 10:52:50.5111 (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: 15eCV3VISLaQFp4xmg7BOjwoeraMrIV0+Na88ipdCbUuzvvpPzJBS6qJriQUfLE8wu/qbYSWcxCPaV9d/Rna2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0603 Archived-At: Subject: [core] CoRE WG Virtual Interim 2020-10-22 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, 21 Oct 2020 10:52:58 -0000 --KjXa0knyszjwWBPOi9XzNDCMuKF0LgrfR Content-Type: multipart/mixed; boundary="2C5PR6fUQxjTQbPu1pwaj3qBFEtbnPSiG" --2C5PR6fUQxjTQbPu1pwaj3qBFEtbnPSiG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that tomorrow (Thursday) at 14:00 UTC we'll have a virtual interim via Webex. The agenda is to check and discuss the latest updates to the new-block document [1] as well as considerations on its implementation [2]. Please, find below the information to join the meeting. Best, Marco and Jaime [1] https://tools.ietf.org/html/draft-ietf-core-new-block-01 [2] https://mailarchive.ietf.org/arch/msg/core/rqp5tEPnBLY14tW4i__bHqgJ2T= 4/ =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2020-core-11-core?bo= th Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm500e0dee578ce618c4ffcf26ca3aedd= 9 Meeting number: 171 330 2933 Password: constrained More ways to join Join by video system Dial 1713302933@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) Access code: 171 330 2933 --=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 --2C5PR6fUQxjTQbPu1pwaj3qBFEtbnPSiG-- --KjXa0knyszjwWBPOi9XzNDCMuKF0LgrfR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+QEvsACgkQ7iZktA5Y 2kM4twf+MIR+UtINqVtLjYZpfVA1x5aprPV99g5Ab1PDYu7hPYrn3hyRSe8CkPIk nY8X+Gp0ZZBa322vS+gpE4YTRWHq5tLwdkXIKJ90WQtAV0yHEK1qOAEevz/JMeLF 8WEYU9v+LY1KNBCiIfVSkn3Fs/7EJlhSvFL1MCCI9sF8XXCco3mfHXZ6PAXiAm4N Hv72YU4ku23u85LdayaPMYfm87RTuDkyLzHc4UAQP859H2lmUwL2hYrmiAWwlzoU 6fODC2CXFRf9BLD5Ii80xx9KsyW2Yg8nVgE/Nk+thAzhtyiA5Rluj9sS1Zoy+89G ZWdzUA78NJYK56ZehmLV/jNvqOcBdw== =LVIW -----END PGP SIGNATURE----- --KjXa0knyszjwWBPOi9XzNDCMuKF0LgrfR-- From nobody Wed Oct 21 04:37:46 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 31CAF3A1769 for ; Wed, 21 Oct 2020 04:37:44 -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 9f8IKkpK64m3 for ; Wed, 21 Oct 2020 04:37:42 -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 CBCAE3A1768 for ; Wed, 21 Oct 2020 04:37:40 -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 7F6AB4012D; Wed, 21 Oct 2020 13:37:38 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5C149AB; Wed, 21 Oct 2020 13:37:37 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:b5e3:21a5:c6eb:f5c2]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C34AA34; Wed, 21 Oct 2020 13:37:36 +0200 (CEST) Received: (nullmailer pid 628427 invoked by uid 1000); Wed, 21 Oct 2020 11:37:36 -0000 Date: Wed, 21 Oct 2020 13:37:36 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Esko Dijk Cc: "core@ietf.org" Message-ID: <20201021113736.GC303030@hephaistos.amsuess.com> References: <20201020103159.GA311699@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 11:37:44 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Esko, hello CoRE, You're right, this does not only come from Limited Link Format, but is an explicit additional requirement on the lookup side. As I remember, this was intruduced for two reasons: * There was little trust in implementations following the RFC6690 rules -- they might just as well work under Link Header rules. * The 6690 rules would require that any present relative anchor would need resolution, and in some absent cases, an absent anchor would need to be set to a (full) URI. Given the varying interpretations of 6690, it would be difficult to come up with sharp rules when the anchor could be elided. Re-reading the 6690 rules, I see that some of my own interpretations of the resolution process (that, apart from discussions on whether or not the relation type can have a bearing on the resolution process[1], seemed to be largely agreed on) can easily have been wrong -- and that reading played into the "always absolute in lookup" rules. If what how I think you interpret 6690[2] is the accepted reading of 6690, the explicit anchor can indeed be elided for many cases. The changes would be manageable on a prescriptive level (but affect a lot of lookup examples -- removing text from the wire so that's a very good thing, but still a large change). The three reasons I'm not jumping to just doing it but ask the WG to chime in are: * We're quite late in the process. * If we pick [2] as The Reading of 6690, we should be sure about it, and I've been wrong about details of the 6690 process too often to jump to conclusions here. * Very few people using link-format seem to care about the semantics of the links in link-format, using it more for the list of resources (like, we could have used some resource description format in the first place). This makes reviews on preserving the actual link semantics -- which we have to to not break the few cases where it does matter -- hard to come by. Chairs, can we even still make such a change? Esko, does [2] capture how you read the resolution process? Group, can we find agreement on that being the right interpretation? KR Christian [1]: > * "anchor" attribute MUST NOT be present for a link with the "hosts" > relation (i.e. the default relation if none specified) This is relatively hard to check -- sure you can test for the presence, but how about if someone made it explicit as rel=3Dhosts? What about rel=3D"managed-by hosts"? [2]: I've read and written too many phrasings of that, maybe this is less ambiguous -- the RFC6690 algorithm as I think you understand it: ``` docbase =3D the RFC3986 base URI (from the encapsulating entity, as link-format has no base embedded in the content) href =3D string part between the angular brackets anchor =3D string value of the anchor attribute, or null if absent target =3D resolve href against docbase if anchor =3D=3D null: context =3D resolve anchor against docbase else: context =3D origin of target ``` --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --9zSXsLTf0vkW971A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+QHXgACgkQOY0REtOk veGldA//XOO4glFot4ixbE9DYPJUrUiJlfP792kL/wVWB7zYFoBKDw/6P2LOvGIF uDUx/yGLqaTTB+Qnf2xW+xmnUmnuZCWQuAMJaynTnXzHhWpfscQH4ffdd/HG/LhB txI1LtJ8AsbAFH6g8p0+tHy9AmSXlsPXoK464D4JNcrWxYoBlljI9UamwbOjCQha yC3k4gOOotBPM8JsOfnH+cUb9Dk/kxsVOyNHAAQ14738c7u9QUDpI/S577918v4B jAQAMWCSHxipKEB0gx+z2kCxlnmUayURxsbQwaHnLv2XZPQbrosXo8VE/9sbJFoS tJKlWg3/awhH+nBJZk1Ypma0cNDtYGESUI9l92Uew1GgDvNuGcfdSdXW27N4pSiu h6RS4cw0WucPe4MymuzapvFo/E3KYnx/2G2fAymhmcqDXEPYk4FDUgGyk0iPLP6V aI8I+HLXiPsRNP8JuK4p+TNjRGny0Ft1w4T7S8FBrQ8ow4ayzTkH3s1ndPlCnVmG Az1CaVt0voFYFPltXH7ewdDaCZIF3YnhIFK+F/zBM+ZvYpFftv1nqRWIgHCh2lXm HKjgar8pS7WXpVObC+I1jAauM0Esq1xQbsq6a7jzpCxZf9zavfewb/LH6RYU9M4W 9KOhyAqg+uxvLNHQF3/OOr+fn2U5AKE9GgxYgw93ca7nNKyFl2c= =+H0f -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From nobody Wed Oct 21 06:00:12 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1A73A0AA3 for ; Wed, 21 Oct 2020 06:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNFyKW4BZqGd for ; Wed, 21 Oct 2020 06:00:08 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2108.outbound.protection.outlook.com [40.107.22.108]) (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 03A4E3A02BC for ; Wed, 21 Oct 2020 06:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KDdr1GyqccYZd2ENSMYbAgmZoVMfUp7YMNdYb4ROy+GVQ++8J+5N2+IyPDVQ2Nh72N8BqoDn1CPVyIWeKr9+djyNkbno/MUaGTIESdmUNN8D/l4dTZJxVOf6fz2m1OYayuW/ldiBKVga5PWrOSERUEnw0EpJN7EGVUuAnSGP0AH7CaeZqjC+z+HDaJRZqGhWxo3NVQ9c8vrtTxc5D5PK/fkWyWdvmI7mBDjssA5x+VrV5biqTj+Z0W1zPRpnIaDmOEl5wuP9c158gWdZxGzcwX6pAebZccIg9gnrBMGaLnzUmulAy82g1nrxOM23cZPykNkcBQ3zyUOn9ORK5PBEaQ== 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=Uqt3U8WJpjEvFdy07dkOHqpwdq2LVTWts6q9XFDRQd8=; b=IF9H3kM/h4dzkmF8Mxdo7/Jl/WXbFh9CBeyvuPFw4WxcTqf5XilN7CYuvO/SFRwl0XNwrsMN37AWryXuDQrgdiNHQq4I5ZfaCbwWRsid1vIF6evGUZhjCUnjo23cQL7LojiU8ETGpnesAmYxUAP93LljP+Sy7iU9q/av4XZ3/xMIgXq7QpgC63krTNGsgfEjpOr1CmOs48c8ziCVj9LNRX5oykv7KL1vVqHccE7SfTa1ZFLMk+uPyWsPIeU5PCN2654X32Sjy9QYFxcGQ3pmFZYQWYx1OrWxOPnM+Hefp+H2j7KgiTwXY1yXXTbzB/7la6yw+ZQieemxluSmnbDQ2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uqt3U8WJpjEvFdy07dkOHqpwdq2LVTWts6q9XFDRQd8=; b=S+85wVs7wcsGax66j9tb/QwCOpVSUocLqeI7P116K442a6W+JWbnjT4go/iFYRk64xneCcofrw2wxW3G4CeOwmLn76McWPo8UjHXUX27dC3a6z489KaDiC1gv+Pyziigf5yAOjjkOFjL1bx7zqQ8T63NSFpziD5nbPHuE62gFKA= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM8P190MB0836.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d2::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Wed, 21 Oct 2020 12:59:59 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3499.018; Wed, 21 Oct 2020 12:59:59 +0000 From: Esko Dijk To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "core@ietf.org" Thread-Topic: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? Thread-Index: AdagiZ7ddTpjV6VySOOkvoVV5WS9KQGQp6uAAC9rtEAABSmPAAABpo/A Date: Wed, 21 Oct 2020 12:59:59 +0000 Message-ID: References: <20201020103159.GA311699@hephaistos.amsuess.com> <20201021113736.GC303030@hephaistos.amsuess.com> In-Reply-To: <20201021113736.GC303030@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:d030:cc1b:a030:56f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88a0155c-6f96-4b89-d305-08d875c137a2 x-ms-traffictypediagnostic: AM8P190MB0836: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O6o8W6CPwrfap4xbOn213n/QlcJguQK20dKz6rgkLFbFSGSdIG7Ex8KX8MKaMToNKp+fdaDYZquITXP6MlFQOTjlJhjjHFfCtVOng6rb3Ck7qN/Hi18mY1/+1DDMTc8gKQHhvM3DIJUSv6erqZnC6kH4TJIR+/Tutc/cJFZwSZSDBpbTHDinkcOZ2xP7GwljH67Sv/4UoHxBiTsZ1J8MKlqI0DsLamm3GtByF8//CN1FfQcB7zVVJNvW/oNCCBkX+hWesLf/qlb8JJH4EpsUMSzDiLuvNhCIaaiY9x+eMbfSQIC1aRGjTSxzg6U+igeFD959zRR4OeC/+nlH/Eg72Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(376002)(39830400003)(396003)(136003)(366004)(76116006)(86362001)(66446008)(316002)(478600001)(71200400001)(6916009)(8936002)(55016002)(7696005)(6506007)(5660300002)(9686003)(66574015)(66556008)(2906002)(4326008)(52536014)(33656002)(53546011)(64756008)(8676002)(186003)(66946007)(44832011)(66476007)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TQM8ecO7g9v3H8tAgoR2bH2Jm973XwqnbQLzcoqPVywF9DMSORrWZ1sCeXn4G0/tyUw7v/JCovtiiusjSJGms5ZeaPc0dFGPSCgchYFKYuPi21M0XDwTNocrzbTkh+52X3nfy8itKOBNISEBipnOY2CH/1jZMm5mG1lvSsRZ/uO/2FLr6Ju4nuIFKFbIYQ5lAq/rTRdDm1PjX3rD+2zMFFZSpXzvDAI62oakPimZaEqDihdy6lNEbGqXgXaK2tof0iQxq/ZZLkSlUaBtkCZeZaaXNg8pSPQQyf6AnXb1t9BkGYYosfinWE1q5At8MRfSoo17kcYF0StwqJidvqGBTt4bI56h6W+9bpwCYk8R53o9f9wWYd30wV7cnepHVLPNS2qmRTLp++LK7vRcevlaepeCJpM3AL+zN3IN7mXC31sRU8EesB0yT0GiaVyKi3bb288lsVWlVPUbsRDFZbSjLd+eCvfDw29+euBIooeEVrUOhvPfQq5Kbtkx+/VVKqcwevw1cK94oC6p3AV8aZluDMY+WoBCdaw4ISkWBeKJ0q/jGNEoJdgax+Bx3hO7ISXs81V0BwnPzKuPde/yLUqeXp94ISC/zwV0cPIQPQs/4fs4O+n8mAU/U7+Xid/wHQVQU88f3EvZSBuV46ftZJdLUTINkaavf5aKfmhUoCRJmZ/KMEuBS2HqhUXaloNq9dopphCLi9BSvMgWVJv85KSb3A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 88a0155c-6f96-4b89-d305-08d875c137a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 12:59:59.4992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k24wEpx+6ccS34s/Stfkuym7wreo7IVn5cvsA/QD+LH4LPqU07rddxKyZYcdH4NfGpZZLKN5oMjArNIxNjrG9aWFMBDVbWJCNDsyknG3BwY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0836 Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 13:00:11 -0000 SGVsbG8gQ2hyaXN0aWFuLA0KDQpUaGFua3MgZm9yIHRoZSBoZWxwZnVsIHJlc3BvbnNlLiBJJ3Zl IHN3YXBwZWQgdHdvIGxpbmVzIGluIHlvdXIgaXRlbSBbMl0gcGx1cyBhZGRlZCBzb21lIGNvbW1l bnRzIGZvciBjbGFyaWZpY2F0aW9uOyBiZWxvdyBpcyBteSB1bmRlcnN0YW5kaW5nOg0KDQpgYGAN CmRvY2Jhc2UgPSB0aGUgUkZDMzk4NiBiYXNlIFVSSSAoZnJvbSB0aGUgZW5jYXBzdWxhdGluZyBl bnRpdHksIGFzIGxpbmstZm9ybWF0IGhhcyBubyBiYXNlIGVtYmVkZGVkIGluIHRoZSBjb250ZW50 KQ0KaHJlZiA9IHN0cmluZyBwYXJ0IGJldHdlZW4gdGhlIGFuZ3VsYXIgYnJhY2tldHMNCmFuY2hv ciA9IHN0cmluZyB2YWx1ZSBvZiB0aGUgYW5jaG9yIGF0dHJpYnV0ZSwgb3IgbnVsbCBpZiBhYnNl bnQNCnRhcmdldCA9IHJlc29sdmUgaHJlZiBhZ2FpbnN0IGRvY2Jhc2UNCmlmIGFuY2hvciA9PSBu dWxsOg0KICAgICAgICBjb250ZXh0ID0gb3JpZ2luLW9mICggdGFyZ2V0ICkgICAgICAgICAgICAg IyBTZWN0aW9uIDIuMSBydWxlIChiKSBhbmQgKGMpLiBJZiBocmVmIGlzIEFCTkYgJ1VSSScgdGhl biB0aGlzIGlzIG9yaWdpbi1vZihocmVmKSwgaWYgaHJlZiAncmVsYXRpdmUtcmVmJyB0aGVuIG9y aWdpbi1vZihkb2NiYXNlKS4NCmVsc2U6DQogICAgY29udGV4dCA9IHJlc29sdmUgYW5jaG9yIGFn YWluc3QgZG9jYmFzZSAgICAgICAjIFNlY3Rpb24gMi4xIHJ1bGUgKGEpIC0gaWYgYW5jaG9yIGlz IEFCTkYgJ1VSSScgdGhlbiByZXN1bHQgb2YgcmVzb2x1dGlvbiBpcyBhZ2FpbiAnYW5jaG9yJy4g SWYgQUJORiAncmVsYXRpdmUtcmVmJyB0aGVuIHJlc3VsdCBpcyAiZG9jYmFzZSAvIHJlbGF0aXZl LXJlZiINCmBgYA0KDQpCZWNhdXNlIHRoaXMgbWF5IGJlIG11bHRpLWludGVycHJldGFibGUsIG15 IGlkZWEgZm9yIExpbWl0ZWQgTGluayBGb3JtYXQgd2FzIHRvIHNpbXBsaWZ5IHRoZSBwYXJzaW5n IGJ5IHNwbGl0dGluZyBpbnRvIHR3byBwb3NzaWJsZSBjYXNlczogMSkgaW1wbGljaXQgcmVsPWhv c3RzIHdpdGhvdXQgJ2FuY2hvcicgOyBhbmQgMikgYW55IG90aGVyIGxpbmsgd2l0aCAnYW5jaG9y Jy4NClRoZW4gZm9yIHBhcnNlcnMgdGhhdCB3b3VsZCBhY2NlcHQgY2F0ZWdvcnkgMikgdGhleSBj YW4gcmVtb3ZlIHRoZSBhYm92ZSAiYW5jaG9yPT1udWxsIiBjYXNlIGluIHRoZSBwYXJzaW5nLCB3 aGljaCBzaW1wbGlmaWVzIGl0LiAgQW5kIElvVCBkZXZpY2VzIGNvdWxkIGp1c3QgaWdub3JlIGFu eSBzdWNoICdjb21wbGV4JyBsaW5rcyB0aGF0IHNwZWNpZnkgYSAncmVsJyBhbmQgYW4gJ2FuY2hv cicuIChBcyBpcyBhbHNvIGV4cGVjdGVkIHBlciBSRkMgNjY5MCk7IGFuZCBvbmx5IHBhcnNlIGNh c2UgMSkgbGlua3MuDQpDYXNlIDEpIGlzIHRoZSBzaW1wbGUgImxpc3Qgb2YgbGlua3MiIHdoaWNo IGlzIGVhc2llciB0byBpbnRlcnByZXQgdGhhbiB0aGUgbW9yZSBnZW5lcmFsIGNhc2UgMikuDQoN CkJhc2Ugb24geW91ciBjb21tZW50IFsxXSBJIHNlZSB0aGF0IG15IHByb3Bvc2VkIHJ1bGUgbmVl ZHMgc29tZSB1cGRhdGUgdG8gZG8gdGhpcyBwcm9wZXJseTogIHdoYXQgYWJvdXQgMiBydWxlczoN CjEqICJhbmNob3IiIGF0dHJpYnV0ZSBNVVNUIE5PVCBiZSBwcmVzZW50IGZvciBhbnkgbGluayB3 aXRob3V0IHRoZSAicmVsIiBhdHRyaWJ1dGUgICAodGhpcyBpbXBsaWVzIHRoYXQgdGhpcyBsaW5r IHVzZXMgdGhlIGltcGxpY2l0IHJlbD1ob3N0cyBzZW1hbnRpY3Mgb25seSkNCjIqICJhbmNob3Ii IGF0dHJpYnV0ZSBNVVNUIGJlIHByZXNlbnQgZm9yIGFueSBsaW5rIHdpdGggdGhlICJyZWwiIGF0 dHJpYnV0ZSAgICAgICAgICAgICAgICAgICh0aGlzIGNvdWxkIGJlIGFueSB0eXBlIG9mIGxpbmss IHBvc3NpYmx5IHVzaW5nIHJlbD0ibWFuYWdlZC1ieSBob3N0cyIgb3IgcmVsPSJob3N0cyIgb3Ig cmVsPWhvc3RzICkNCg0KU28gdGhlbiB0aGUgb25seSBjYXNlIHdoZXJlICJhbmNob3IiIGNhbiBi ZSBlbGlkZWQgaXMgdGhlIGNhc2Ugb2YgdXNpbmcgdGhlIGltcGxpY2l0ICdyZWw9aG9zdHMnIHJl bGF0aW9uLCBhY2hpZXZlZCBieSBsZWF2aW5nIG91dCB0aGUgInJlbCIgYXR0cmlidXRlLg0KDQpU aGVyZSBpcyBvbmUgbW9yZSBjb25zaWRlcmF0aW9uIGZvciB0aGUgY3VycmVudCBSRCBkcmFmdCAt IGluIGNhc2Ugd2UgZGVjaWRlIHRvIGtlZXAgdGhlIGV4cGxpY2l0ICJhbmNob3IiIGF0dHJpYnV0 ZSBpbiBhbGwgdGhlIGV4YW1wbGVzLiBCZWNhdXNlIFJGQyA2NjkwIGlzIGEgbm9ybWF0aXZlIHJl ZmVyZW5jZSwgdGhlIGFzc3VtcHRpb24gb2YgdGhlIHJlYWRlciBjdXJyZW50bHkgc2hvdWxkIHN0 aWxsIGJlIHRoYXQgdGhlICJhbmNob3IiIGF0dHJpYnV0ZSB0aGF0J3MgYWRkZWQgaW4gYWxsIHRo ZSBleGFtcGxlIGlzIGp1c3Qgc3VwZXJmbHVvdXMgaS5lLg0KKiBhbiBSRCBpbXBsZW1lbnRhdGlv biBtYXkgZWxpZGUgaXQgLCBmb2xsb3dpbmcgUkZDIDY2OTAgcnVsZXMgIChpbiB0aGUgaW50ZXJw cmV0YXRpb24gYXMgY29kZWQgYXQgdGhlIHRvcCBvZiB0aGlzIGVtYWlsLikgYW5kIFNlY3Rpb24g Mi4zIG9mIDY2OTANCiogYW4gUkQgY2xpZW50IGRvaW5nIGxvb2t1cHMgbWF5IGlnbm9yZSBpdCwg Zm9sbG93aW5nIFJGQyA2NjkwIHJ1bGVzIGluIFNlY3Rpb24gMi4zDQoNClNvIHdlIHN0aWxsIHdp bGwgYmUgZmFjZWQgd2l0aCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBpZiBSRCBpbXBsZW1lbnRl cnMgaW50ZXJwcmV0IFJGQyA2NjkwIGRpZmZlcmVudGx5LiAgIFdoYXQgaXMgbmVlZGVkIGluIHRo aXMgY2FzZSBpcyB0aGF0IHdlICp1cGRhdGUqIFJGQyA2NjkwIHJ1bGVzIGV4cGxpY2l0bHkgZS5n LiBieSBtYWtpbmcgImFuY2hvciIgbWFuZGF0b3J5IGluIGFsbCBjYXNlcy4gIChXaGV0aGVyIHdl IGZvcm1hbGx5IHVwZGF0ZSBSRkMgNjY5MCBvciBqdXN0IGRlZmluZSBpdCBhcyBwYXJ0IG9mIExp bWl0ZWQgTGluayBGb3JtYXQgZG9lc24ndCBtYXR0ZXIgdGhhdCBtdWNoIEkgdGhpbmsuKQ0KDQpC ZXN0IHJlZ2FyZHMNCkVza28NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Q2hyaXN0aWFuIEFtc8O8c3MgPGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4gDQpTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMjEsIDIwMjAgMTM6MzgNClRvOiBFc2tvIERpamsgPGVza28uZGlqa0Bpb3Rj b25zdWx0YW5jeS5ubD4NCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFVu bmVjZXNzYXJ5ICJhbmNob3IiIGF0dHJpYnV0ZXMgaW4gZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNl LWRpcmVjdG9yeS0yNSA/DQoNCkhlbGxvIEVza28sIGhlbGxvIENvUkUsDQoNCllvdSdyZSByaWdo dCwgdGhpcyBkb2VzIG5vdCBvbmx5IGNvbWUgZnJvbSBMaW1pdGVkIExpbmsgRm9ybWF0LCBidXQg aXMNCmFuIGV4cGxpY2l0IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnQgb24gdGhlIGxvb2t1cCBzaWRl LiBBcyBJIHJlbWVtYmVyLA0KdGhpcyB3YXMgaW50cnVkdWNlZCBmb3IgdHdvIHJlYXNvbnM6DQoN CiogVGhlcmUgd2FzIGxpdHRsZSB0cnVzdCBpbiBpbXBsZW1lbnRhdGlvbnMgZm9sbG93aW5nIHRo ZSBSRkM2NjkwIHJ1bGVzDQogIC0tIHRoZXkgbWlnaHQganVzdCBhcyB3ZWxsIHdvcmsgdW5kZXIg TGluayBIZWFkZXIgcnVsZXMuDQoNCiogVGhlIDY2OTAgcnVsZXMgd291bGQgcmVxdWlyZSB0aGF0 IGFueSBwcmVzZW50IHJlbGF0aXZlIGFuY2hvciB3b3VsZA0KICBuZWVkIHJlc29sdXRpb24sIGFu ZCBpbiBzb21lIGFic2VudCBjYXNlcywgYW4gYWJzZW50IGFuY2hvciB3b3VsZCBuZWVkDQogIHRv IGJlIHNldCB0byBhIChmdWxsKSBVUkkuDQoNCiAgR2l2ZW4gdGhlIHZhcnlpbmcgaW50ZXJwcmV0 YXRpb25zIG9mIDY2OTAsIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0bw0KICBjb21lIHVwIHdpdGgg c2hhcnAgcnVsZXMgd2hlbiB0aGUgYW5jaG9yIGNvdWxkIGJlIGVsaWRlZC4NCg0KUmUtcmVhZGlu ZyB0aGUgNjY5MCBydWxlcywgSSBzZWUgdGhhdCBzb21lIG9mIG15IG93biBpbnRlcnByZXRhdGlv bnMgb2YNCnRoZSByZXNvbHV0aW9uIHByb2Nlc3MgKHRoYXQsIGFwYXJ0IGZyb20gZGlzY3Vzc2lv bnMgb24gd2hldGhlciBvciBub3QNCnRoZSByZWxhdGlvbiB0eXBlIGNhbiBoYXZlIGEgYmVhcmlu ZyBvbiB0aGUgcmVzb2x1dGlvbiBwcm9jZXNzWzFdLA0Kc2VlbWVkIHRvIGJlIGxhcmdlbHkgYWdy ZWVkIG9uKSBjYW4gZWFzaWx5IGhhdmUgYmVlbiB3cm9uZyAtLSBhbmQgdGhhdA0KcmVhZGluZyBw bGF5ZWQgaW50byB0aGUgImFsd2F5cyBhYnNvbHV0ZSBpbiBsb29rdXAiIHJ1bGVzLg0KDQpJZiB3 aGF0IGhvdyBJIHRoaW5rIHlvdSBpbnRlcnByZXQgNjY5MFsyXSBpcyB0aGUgYWNjZXB0ZWQgcmVh ZGluZyBvZg0KNjY5MCwgdGhlIGV4cGxpY2l0IGFuY2hvciBjYW4gaW5kZWVkIGJlIGVsaWRlZCBm b3IgbWFueSBjYXNlcy4NCg0KVGhlIGNoYW5nZXMgd291bGQgYmUgbWFuYWdlYWJsZSBvbiBhIHBy ZXNjcmlwdGl2ZSBsZXZlbCAoYnV0IGFmZmVjdCBhDQpsb3Qgb2YgbG9va3VwIGV4YW1wbGVzIC0t IHJlbW92aW5nIHRleHQgZnJvbSB0aGUgd2lyZSBzbyB0aGF0J3MgYSB2ZXJ5DQpnb29kIHRoaW5n LCBidXQgc3RpbGwgYSBsYXJnZSBjaGFuZ2UpLiBUaGUgdGhyZWUgcmVhc29ucyBJJ20gbm90IGp1 bXBpbmcNCnRvIGp1c3QgZG9pbmcgaXQgYnV0IGFzayB0aGUgV0cgdG8gY2hpbWUgaW4gYXJlOg0K DQoqIFdlJ3JlIHF1aXRlIGxhdGUgaW4gdGhlIHByb2Nlc3MuDQoqIElmIHdlIHBpY2sgWzJdIGFz IFRoZSBSZWFkaW5nIG9mIDY2OTAsIHdlIHNob3VsZCBiZSBzdXJlIGFib3V0IGl0LCBhbmQNCiAg SSd2ZSBiZWVuIHdyb25nIGFib3V0IGRldGFpbHMgb2YgdGhlIDY2OTAgcHJvY2VzcyB0b28gb2Z0 ZW4gdG8ganVtcCB0bw0KICBjb25jbHVzaW9ucyBoZXJlLg0KKiBWZXJ5IGZldyBwZW9wbGUgdXNp bmcgbGluay1mb3JtYXQgc2VlbSB0byBjYXJlIGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YNCiAgdGhl IGxpbmtzIGluIGxpbmstZm9ybWF0LCB1c2luZyBpdCBtb3JlIGZvciB0aGUgbGlzdCBvZiByZXNv dXJjZXMNCiAgKGxpa2UsIHdlIGNvdWxkIGhhdmUgdXNlZCBzb21lIHJlc291cmNlIGRlc2NyaXB0 aW9uIGZvcm1hdCBpbiB0aGUNCiAgZmlyc3QgcGxhY2UpLiBUaGlzIG1ha2VzIHJldmlld3Mgb24g cHJlc2VydmluZyB0aGUgYWN0dWFsIGxpbmsNCiAgc2VtYW50aWNzIC0tIHdoaWNoIHdlIGhhdmUg dG8gdG8gbm90IGJyZWFrIHRoZSBmZXcgY2FzZXMgd2hlcmUgaXQgZG9lcw0KICBtYXR0ZXIgLS0g aGFyZCB0byBjb21lIGJ5Lg0KDQoNCkNoYWlycywgY2FuIHdlIGV2ZW4gc3RpbGwgbWFrZSBzdWNo IGEgY2hhbmdlPw0KDQpFc2tvLCBkb2VzIFsyXSBjYXB0dXJlIGhvdyB5b3UgcmVhZCB0aGUgcmVz b2x1dGlvbiBwcm9jZXNzPw0KDQpHcm91cCwgY2FuIHdlIGZpbmQgYWdyZWVtZW50IG9uIHRoYXQg YmVpbmcgdGhlIHJpZ2h0IGludGVycHJldGF0aW9uPw0KDQpLUg0KQ2hyaXN0aWFuDQoNClsxXToN Cj4gKiAiYW5jaG9yIiBhdHRyaWJ1dGUgTVVTVCBOT1QgYmUgcHJlc2VudCBmb3IgYSBsaW5rIHdp dGggdGhlICJob3N0cyINCj4gcmVsYXRpb24gICAoaS5lLiB0aGUgZGVmYXVsdCByZWxhdGlvbiBp ZiBub25lIHNwZWNpZmllZCkNCg0KVGhpcyBpcyByZWxhdGl2ZWx5IGhhcmQgdG8gY2hlY2sgLS0g c3VyZSB5b3UgY2FuIHRlc3QgZm9yIHRoZSBwcmVzZW5jZSwNCmJ1dCBob3cgYWJvdXQgaWYgc29t ZW9uZSBtYWRlIGl0IGV4cGxpY2l0IGFzIHJlbD1ob3N0cz8gV2hhdCBhYm91dA0KcmVsPSJtYW5h Z2VkLWJ5IGhvc3RzIj8NCg0KWzJdOiBJJ3ZlIHJlYWQgYW5kIHdyaXR0ZW4gdG9vIG1hbnkgcGhy YXNpbmdzIG9mIHRoYXQsIG1heWJlIHRoaXMgaXMNCmxlc3MgYW1iaWd1b3VzIC0tIHRoZSBSRkM2 NjkwIGFsZ29yaXRobSBhcyBJIHRoaW5rIHlvdSB1bmRlcnN0YW5kIGl0Og0KDQpgYGANCmRvY2Jh c2UgPSB0aGUgUkZDMzk4NiBiYXNlIFVSSSAoZnJvbSB0aGUgZW5jYXBzdWxhdGluZyBlbnRpdHks IGFzDQogIGxpbmstZm9ybWF0IGhhcyBubyBiYXNlIGVtYmVkZGVkIGluIHRoZSBjb250ZW50KQ0K aHJlZiA9IHN0cmluZyBwYXJ0IGJldHdlZW4gdGhlIGFuZ3VsYXIgYnJhY2tldHMNCmFuY2hvciA9 IHN0cmluZyB2YWx1ZSBvZiB0aGUgYW5jaG9yIGF0dHJpYnV0ZSwgb3IgbnVsbCBpZiBhYnNlbnQN CnRhcmdldCA9IHJlc29sdmUgaHJlZiBhZ2FpbnN0IGRvY2Jhc2UNCmlmIGFuY2hvciA9PSBudWxs Og0KICAgIGNvbnRleHQgPSByZXNvbHZlIGFuY2hvciBhZ2FpbnN0IGRvY2Jhc2UNCmVsc2U6DQog ICAgY29udGV4dCA9IG9yaWdpbiBvZiB0YXJnZXQNCmBgYA0KDQotLSANClRvIHVzZSByYXcgcG93 ZXIgaXMgdG8gbWFrZSB5b3Vyc2VsZiBpbmZpbml0ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlciBw b3dlcnMuDQogIC0tIEJlbmUgR2Vzc2VyaXQgYXhpb20NCg== From nobody Wed Oct 21 06:21:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3823A0FDF for ; Wed, 21 Oct 2020 06:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NAbjRgNoUQy for ; Wed, 21 Oct 2020 06:21:47 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2139.outbound.protection.outlook.com [40.107.21.139]) (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 C3AEE3A0FFA for ; Wed, 21 Oct 2020 06:21:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SrZXwoixxQYCei1lbCttTAjhnjgQLEQ5vxnWy46IlxSPXUHy6HvVVUgovxV1nF6RM+rrwxLlSQpjLeHEbD9OVKyiWoXfrDvT/AISIMDKqmHqZAaAInXYZoRq1gON7v/uQkJrCinvFB7kho0XBncEVnFHb3rwmBvgjf+9RzNxH3oZc13MJ+1Q75nuxG9VIgNjC88TTC816/7neeEE8FPwlbjYwKZ5KUkzU7IrUaxyGFChYhtv7L7ahQExaytPiC1RD4lNhrSWNskcEZMkghejoHKVBA/occF1vBCMIj3q5mgP/OtRml/2gU4RRu2gsChkT1dFHGOzxJLptyISwGWlBw== 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=mMS7+6KeCKvVznRJm72Vzri1PzVcesisXlIfp48gVe8=; b=J239PJLlHQQMGRk4WVmvD0rRiJl+vJeTSmza4IcfwsEbDp/fgXk+OKUTQw40e0QVEJjzFZeC91ZVbxbsKcS7EdBBamV7O1T3PcnZDnPpWPBk9biFWPp5kTRM6+bsytdlcYgDCCHqoTPmFzqiM5HlH30TsHyOcpYG1dpa2m6BO3cUBR/PmpJTZILyb0p71rvZLBX0xz4ZHKYRxYIJklEAwdfMvs7DXXfn1N7jUBNyLb5eed157tkRr+QnVmm7U4OR0VxRRRDqZCQky9xR6dIfNA1Z2qatxLQGV0JGOaZ7puCPz+dlMtFjCHLYf5tF+EKoEDVMUFbbpk6OcF41mq2d0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMS7+6KeCKvVznRJm72Vzri1PzVcesisXlIfp48gVe8=; b=yq1LHVpLU6FudDomKg8CbwUSLe9Ago9yP7xam53MTJGDGticXnrCjv0oG4mZEYjj5dXYDbHUNPagFyw2qASReRrgZvEpjArHR6KqeiK913di1R/4T0rpFk8zb8Kks3Zjxwk+gTjTwNv8/Cm6suW2gKdlJXUrlATKlD1RGdI+7Mw= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0579.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Wed, 21 Oct 2020 13:21:42 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3499.018; Wed, 21 Oct 2020 13:21:42 +0000 From: Esko Dijk To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "core@ietf.org" Thread-Topic: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? Thread-Index: AdagiZ7ddTpjV6VySOOkvoVV5WS9KQGQp6uAAC9rtEAABSmPAAABpo/AAAGlLiA= Date: Wed, 21 Oct 2020 13:21:42 +0000 Message-ID: References: <20201020103159.GA311699@hephaistos.amsuess.com> <20201021113736.GC303030@hephaistos.amsuess.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:d030:cc1b:a030:56f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9c3a48c-8ab2-485d-e032-08d875c44047 x-ms-traffictypediagnostic: AM0P190MB0579: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JzphE0dWM122iPiQllow9FRN6viwFx4rEEXqCi2KrQLgXhCEW1PWUH2QBiq+hu/U02fsDzN7s3g3PWB6rylcJKS0AuCv4+AWEpCvH8Pff8tvLyg/5PP11uI4n7sxne914DBRDjIEmDxGskHkQxJdIGO9+/jIYw4ptZu9jBCWZNDSMxfXPKB8znj/dl00ceYxJc8mPXmLduVIyico+kGc3YYIZ9YPPaIz5q+mmhhw4mt5LDdNOcE34F1eGNRve+3WHFKtRVN4OeaHKMMn1viISB2jAnhzFtI+nVw3a/pWtFxeTAQlTlLGkIg8P3pEQeDDY4mq5bfSoAeSsv6Wdxc2kXuT5Bolq9D1raGPqmrFjl9QjeQ3DzmnEqMk0EvyyxitrQKtnsER9gaoNmh+CuB6OA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(39830400003)(136003)(396003)(366004)(7696005)(55016002)(478600001)(66476007)(6506007)(66946007)(66446008)(966005)(44832011)(66574015)(52536014)(76116006)(64756008)(66556008)(71200400001)(53546011)(9686003)(4326008)(6916009)(5660300002)(316002)(2940100002)(8936002)(86362001)(33656002)(8676002)(2906002)(83380400001)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0vQxWQBj0nVkDFbpbxM9PONGcHT4vYtce5jTrJMvPJPKyc/4g9VPyeX6MYrzzSnG2M+cWtYiyXDcjAYqfjcLjRb6clE4LQuKumW0+gAPCKxxwGGHWixYdGmqCcs+r1N/OJn+wh4d1Q+aIVJi+dOLPERHGlRvOHTwZfGYbtaT6n31u1MrcM5yNuCtBd5NcCl+WZZ/E0rgzdUXmtKfuaCK4FpVi/GzQ4spWEueSlWCv4UfF2By+RV20Y9Wybp2aThL9HoHJ8iC1ssHz2CV7wGtVMa1c8mKbUviE8ucnYFvydFG9EP4SR21cWY0gdMf77mBPvfT3EFCn/w2NUmWn73ef3ZU1eLPthSX4BBUHFK6ogrydKKeusk5YrfCypw5tiyQ0qN7LrKmJSQKLR8Ex8qMxp1fQ/CrqcGww7XocDjriYdz10ttFRpRqJ7/VKlEW0cFOrMv5s7NZIUlViIaA61QJsLi5zwNd9ylYAy2PfMIZgtZFgMwjVEczoW7blyQ6hMtuzL4gxnm6D668Lq1crm8GAm4TtRUeZX3a3o+/Jzh+ySQ9++0mlK/llZFScMXlF0h2viZTMS6MhpyW7YkkGL7bkm6bd0/laBIJCvoXuxpZAfROf9bBJ3ajCXJs0m7H66v600rKVf7VYUVHEF8HuUt6v/xKkrl6rUiIx6wSZFNX+k8AnjpbxyTrKAGWz8vcfqFTvBKtbbunj8UiTAv/vH9nA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b9c3a48c-8ab2-485d-e032-08d875c44047 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 13:21:42.4182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 69YE9kunTVT/YjqIin2V0uomEMnTv7LTacebuZpkDwHwX3krh/xKmi/YgaDBfIatMdURY3PpM7hiRzT64q0QTGg0+CuPaRT72uyNWO5URp4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0579 Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 13:21:50 -0000 UFMgb25lIGFkZGl0aW9uYWwgcmVtYXJrIHRvIG15IHByZXZpb3VzIGVtYWlsLg0KDQpJbiB0aGUg cHJlc2VudCBsaW5rIGV4YW1wbGVzIG9idGFpbmVkIGZyb20gUkQgd2UgbWF5IGhhdmU6DQoNCjxj b2FwOi8vWzIwMDE6ZGI4OjM6OjEyM106NjE2MTYvdGVtcD47cnQ9InRhZzpleGFtcGxlLm9yZywy MDIwOnRlbXBlcmF0dXJlIjthbmNob3I9ImNvYXA6Ly9bMjAwMTpkYjg6Mzo6MTIzXTo2MTYxNiIN Cg0KSSB3YXMgd29uZGVyaW5nIHdoYXQgcGFyc2luZyBwcm9ibGVtcyB3b3VsZCBhcmlzZSBpbiB0 aGUgY2xpZW50IGlmIGl0IHdlcmUgcmV0dXJuZWQgd2l0aG91dCB0aGUgJ2FuY2hvcic6DQoNCjxj b2FwOi8vWzIwMDE6ZGI4OjM6OjEyM106NjE2MTYvdGVtcD47cnQ9InRhZzpleGFtcGxlLm9yZywy MDIwOnRlbXBlcmF0dXJlIg0KDQpUaGF0IHNlZW1zIGNsZWFyOyBmcm9tIHRoaXMgYW5zd2VyIC0g aG93IGNvdWxkIGFueW9uZSBiZSBtaXN0YWtlbiBhYm91dCB0aGUgYW5jaG9yIGkuZS4gd2hpY2gg c2VydmVyIGlzIGhvc3RpbmcgdGhlICcvdGVtcCcgcmVzb3VyY2UgPyBUaGVyZSdzIG9ubHkgb25l IHNlcnZlciBtZW50aW9uZWQgc28gdGhhdCdzIHRoZSBvbmUgcmlnaHQgOikgICAgDQpBbmQgZm9y IHRoZSByZWw9aG9zdHMgcmVsYXRpb24gaXQgd291bGQgbm90IG1ha2UgbXVjaCBzZW5zZSB0byBw cm9jbGFpbSBlLmcuICJjb2FwOi8vc2VydmVyMSAgaG9zdHMgIGNvYXA6Ly9zZXJ2ZXIyL3Jlc291 cmNlIiAgLi4uIA0KDQpCZXN0IHJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEVz a28gRGlqaw0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDIwIDE1OjAwDQpUbzogQ2hy aXN0aWFuIEFtc8O8c3MgPGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4NCkNjOiBjb3JlQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW2NvcmVdIFVubmVjZXNzYXJ5ICJhbmNob3IiIGF0dHJpYnV0ZXMgaW4g ZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0yNSA/DQoNCkhlbGxvIENocmlzdGlh biwNCg0KVGhhbmtzIGZvciB0aGUgaGVscGZ1bCByZXNwb25zZS4gSSd2ZSBzd2FwcGVkIHR3byBs aW5lcyBpbiB5b3VyIGl0ZW0gWzJdIHBsdXMgYWRkZWQgc29tZSBjb21tZW50cyBmb3IgY2xhcmlm aWNhdGlvbjsgYmVsb3cgaXMgbXkgdW5kZXJzdGFuZGluZzoNCg0KYGBgDQpkb2NiYXNlID0gdGhl IFJGQzM5ODYgYmFzZSBVUkkgKGZyb20gdGhlIGVuY2Fwc3VsYXRpbmcgZW50aXR5LCBhcyBsaW5r LWZvcm1hdCBoYXMgbm8gYmFzZSBlbWJlZGRlZCBpbiB0aGUgY29udGVudCkNCmhyZWYgPSBzdHJp bmcgcGFydCBiZXR3ZWVuIHRoZSBhbmd1bGFyIGJyYWNrZXRzDQphbmNob3IgPSBzdHJpbmcgdmFs dWUgb2YgdGhlIGFuY2hvciBhdHRyaWJ1dGUsIG9yIG51bGwgaWYgYWJzZW50DQp0YXJnZXQgPSBy ZXNvbHZlIGhyZWYgYWdhaW5zdCBkb2NiYXNlDQppZiBhbmNob3IgPT0gbnVsbDoNCiAgICAgICAg Y29udGV4dCA9IG9yaWdpbi1vZiAoIHRhcmdldCApICAgICAgICAgICAgICMgU2VjdGlvbiAyLjEg cnVsZSAoYikgYW5kIChjKS4gSWYgaHJlZiBpcyBBQk5GICdVUkknIHRoZW4gdGhpcyBpcyBvcmln aW4tb2YoaHJlZiksIGlmIGhyZWYgJ3JlbGF0aXZlLXJlZicgdGhlbiBvcmlnaW4tb2YoZG9jYmFz ZSkuDQplbHNlOg0KICAgIGNvbnRleHQgPSByZXNvbHZlIGFuY2hvciBhZ2FpbnN0IGRvY2Jhc2Ug ICAgICAgIyBTZWN0aW9uIDIuMSBydWxlIChhKSAtIGlmIGFuY2hvciBpcyBBQk5GICdVUkknIHRo ZW4gcmVzdWx0IG9mIHJlc29sdXRpb24gaXMgYWdhaW4gJ2FuY2hvcicuIElmIEFCTkYgJ3JlbGF0 aXZlLXJlZicgdGhlbiByZXN1bHQgaXMgImRvY2Jhc2UgLyByZWxhdGl2ZS1yZWYiDQpgYGANCg0K QmVjYXVzZSB0aGlzIG1heSBiZSBtdWx0aS1pbnRlcnByZXRhYmxlLCBteSBpZGVhIGZvciBMaW1p dGVkIExpbmsgRm9ybWF0IHdhcyB0byBzaW1wbGlmeSB0aGUgcGFyc2luZyBieSBzcGxpdHRpbmcg aW50byB0d28gcG9zc2libGUgY2FzZXM6IDEpIGltcGxpY2l0IHJlbD1ob3N0cyB3aXRob3V0ICdh bmNob3InIDsgYW5kIDIpIGFueSBvdGhlciBsaW5rIHdpdGggJ2FuY2hvcicuDQpUaGVuIGZvciBw YXJzZXJzIHRoYXQgd291bGQgYWNjZXB0IGNhdGVnb3J5IDIpIHRoZXkgY2FuIHJlbW92ZSB0aGUg YWJvdmUgImFuY2hvcj09bnVsbCIgY2FzZSBpbiB0aGUgcGFyc2luZywgd2hpY2ggc2ltcGxpZmll cyBpdC4gIEFuZCBJb1QgZGV2aWNlcyBjb3VsZCBqdXN0IGlnbm9yZSBhbnkgc3VjaCAnY29tcGxl eCcgbGlua3MgdGhhdCBzcGVjaWZ5IGEgJ3JlbCcgYW5kIGFuICdhbmNob3InLiAoQXMgaXMgYWxz byBleHBlY3RlZCBwZXIgUkZDIDY2OTApOyBhbmQgb25seSBwYXJzZSBjYXNlIDEpIGxpbmtzLg0K Q2FzZSAxKSBpcyB0aGUgc2ltcGxlICJsaXN0IG9mIGxpbmtzIiB3aGljaCBpcyBlYXNpZXIgdG8g aW50ZXJwcmV0IHRoYW4gdGhlIG1vcmUgZ2VuZXJhbCBjYXNlIDIpLg0KDQpCYXNlIG9uIHlvdXIg Y29tbWVudCBbMV0gSSBzZWUgdGhhdCBteSBwcm9wb3NlZCBydWxlIG5lZWRzIHNvbWUgdXBkYXRl IHRvIGRvIHRoaXMgcHJvcGVybHk6ICB3aGF0IGFib3V0IDIgcnVsZXM6DQoxKiAiYW5jaG9yIiBh dHRyaWJ1dGUgTVVTVCBOT1QgYmUgcHJlc2VudCBmb3IgYW55IGxpbmsgd2l0aG91dCB0aGUgInJl bCIgYXR0cmlidXRlICAgKHRoaXMgaW1wbGllcyB0aGF0IHRoaXMgbGluayB1c2VzIHRoZSBpbXBs aWNpdCByZWw9aG9zdHMgc2VtYW50aWNzIG9ubHkpDQoyKiAiYW5jaG9yIiBhdHRyaWJ1dGUgTVVT VCBiZSBwcmVzZW50IGZvciBhbnkgbGluayB3aXRoIHRoZSAicmVsIiBhdHRyaWJ1dGUgICAgICAg ICAgICAgICAgICAodGhpcyBjb3VsZCBiZSBhbnkgdHlwZSBvZiBsaW5rLCBwb3NzaWJseSB1c2lu ZyByZWw9Im1hbmFnZWQtYnkgaG9zdHMiIG9yIHJlbD0iaG9zdHMiIG9yIHJlbD1ob3N0cyApDQoN ClNvIHRoZW4gdGhlIG9ubHkgY2FzZSB3aGVyZSAiYW5jaG9yIiBjYW4gYmUgZWxpZGVkIGlzIHRo ZSBjYXNlIG9mIHVzaW5nIHRoZSBpbXBsaWNpdCAncmVsPWhvc3RzJyByZWxhdGlvbiwgYWNoaWV2 ZWQgYnkgbGVhdmluZyBvdXQgdGhlICJyZWwiIGF0dHJpYnV0ZS4NCg0KVGhlcmUgaXMgb25lIG1v cmUgY29uc2lkZXJhdGlvbiBmb3IgdGhlIGN1cnJlbnQgUkQgZHJhZnQgLSBpbiBjYXNlIHdlIGRl Y2lkZSB0byBrZWVwIHRoZSBleHBsaWNpdCAiYW5jaG9yIiBhdHRyaWJ1dGUgaW4gYWxsIHRoZSBl eGFtcGxlcy4gQmVjYXVzZSBSRkMgNjY5MCBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UsIHRoZSBh c3N1bXB0aW9uIG9mIHRoZSByZWFkZXIgY3VycmVudGx5IHNob3VsZCBzdGlsbCBiZSB0aGF0IHRo ZSAiYW5jaG9yIiBhdHRyaWJ1dGUgdGhhdCdzIGFkZGVkIGluIGFsbCB0aGUgZXhhbXBsZSBpcyBq dXN0IHN1cGVyZmx1b3VzIGkuZS4NCiogYW4gUkQgaW1wbGVtZW50YXRpb24gbWF5IGVsaWRlIGl0 ICwgZm9sbG93aW5nIFJGQyA2NjkwIHJ1bGVzICAoaW4gdGhlIGludGVycHJldGF0aW9uIGFzIGNv ZGVkIGF0IHRoZSB0b3Agb2YgdGhpcyBlbWFpbC4pIGFuZCBTZWN0aW9uIDIuMyBvZiA2NjkwDQoq IGFuIFJEIGNsaWVudCBkb2luZyBsb29rdXBzIG1heSBpZ25vcmUgaXQsIGZvbGxvd2luZyBSRkMg NjY5MCBydWxlcyBpbiBTZWN0aW9uIDIuMw0KDQpTbyB3ZSBzdGlsbCB3aWxsIGJlIGZhY2VkIHdp dGggaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgaWYgUkQgaW1wbGVtZW50ZXJzIGludGVycHJldCBS RkMgNjY5MCBkaWZmZXJlbnRseS4gICBXaGF0IGlzIG5lZWRlZCBpbiB0aGlzIGNhc2UgaXMgdGhh dCB3ZSAqdXBkYXRlKiBSRkMgNjY5MCBydWxlcyBleHBsaWNpdGx5IGUuZy4gYnkgbWFraW5nICJh bmNob3IiIG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMuICAoV2hldGhlciB3ZSBmb3JtYWxseSB1cGRh dGUgUkZDIDY2OTAgb3IganVzdCBkZWZpbmUgaXQgYXMgcGFydCBvZiBMaW1pdGVkIExpbmsgRm9y bWF0IGRvZXNuJ3QgbWF0dGVyIHRoYXQgbXVjaCBJIHRoaW5rLikNCg0KQmVzdCByZWdhcmRzDQpF c2tvDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGlhbiBBbXPD vHNzIDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+IA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIx LCAyMDIwIDEzOjM4DQpUbzogRXNrbyBEaWprIDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+ DQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBVbm5lY2Vzc2FyeSAiYW5j aG9yIiBhdHRyaWJ1dGVzIGluIGRyYWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMjUg Pw0KDQpIZWxsbyBFc2tvLCBoZWxsbyBDb1JFLA0KDQpZb3UncmUgcmlnaHQsIHRoaXMgZG9lcyBu b3Qgb25seSBjb21lIGZyb20gTGltaXRlZCBMaW5rIEZvcm1hdCwgYnV0IGlzDQphbiBleHBsaWNp dCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50IG9uIHRoZSBsb29rdXAgc2lkZS4gQXMgSSByZW1lbWJl ciwNCnRoaXMgd2FzIGludHJ1ZHVjZWQgZm9yIHR3byByZWFzb25zOg0KDQoqIFRoZXJlIHdhcyBs aXR0bGUgdHJ1c3QgaW4gaW1wbGVtZW50YXRpb25zIGZvbGxvd2luZyB0aGUgUkZDNjY5MCBydWxl cw0KICAtLSB0aGV5IG1pZ2h0IGp1c3QgYXMgd2VsbCB3b3JrIHVuZGVyIExpbmsgSGVhZGVyIHJ1 bGVzLg0KDQoqIFRoZSA2NjkwIHJ1bGVzIHdvdWxkIHJlcXVpcmUgdGhhdCBhbnkgcHJlc2VudCBy ZWxhdGl2ZSBhbmNob3Igd291bGQNCiAgbmVlZCByZXNvbHV0aW9uLCBhbmQgaW4gc29tZSBhYnNl bnQgY2FzZXMsIGFuIGFic2VudCBhbmNob3Igd291bGQgbmVlZA0KICB0byBiZSBzZXQgdG8gYSAo ZnVsbCkgVVJJLg0KDQogIEdpdmVuIHRoZSB2YXJ5aW5nIGludGVycHJldGF0aW9ucyBvZiA2Njkw LCBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgdG8NCiAgY29tZSB1cCB3aXRoIHNoYXJwIHJ1bGVzIHdo ZW4gdGhlIGFuY2hvciBjb3VsZCBiZSBlbGlkZWQuDQoNClJlLXJlYWRpbmcgdGhlIDY2OTAgcnVs ZXMsIEkgc2VlIHRoYXQgc29tZSBvZiBteSBvd24gaW50ZXJwcmV0YXRpb25zIG9mDQp0aGUgcmVz b2x1dGlvbiBwcm9jZXNzICh0aGF0LCBhcGFydCBmcm9tIGRpc2N1c3Npb25zIG9uIHdoZXRoZXIg b3Igbm90DQp0aGUgcmVsYXRpb24gdHlwZSBjYW4gaGF2ZSBhIGJlYXJpbmcgb24gdGhlIHJlc29s dXRpb24gcHJvY2Vzc1sxXSwNCnNlZW1lZCB0byBiZSBsYXJnZWx5IGFncmVlZCBvbikgY2FuIGVh c2lseSBoYXZlIGJlZW4gd3JvbmcgLS0gYW5kIHRoYXQNCnJlYWRpbmcgcGxheWVkIGludG8gdGhl ICJhbHdheXMgYWJzb2x1dGUgaW4gbG9va3VwIiBydWxlcy4NCg0KSWYgd2hhdCBob3cgSSB0aGlu ayB5b3UgaW50ZXJwcmV0IDY2OTBbMl0gaXMgdGhlIGFjY2VwdGVkIHJlYWRpbmcgb2YNCjY2OTAs IHRoZSBleHBsaWNpdCBhbmNob3IgY2FuIGluZGVlZCBiZSBlbGlkZWQgZm9yIG1hbnkgY2FzZXMu DQoNClRoZSBjaGFuZ2VzIHdvdWxkIGJlIG1hbmFnZWFibGUgb24gYSBwcmVzY3JpcHRpdmUgbGV2 ZWwgKGJ1dCBhZmZlY3QgYQ0KbG90IG9mIGxvb2t1cCBleGFtcGxlcyAtLSByZW1vdmluZyB0ZXh0 IGZyb20gdGhlIHdpcmUgc28gdGhhdCdzIGEgdmVyeQ0KZ29vZCB0aGluZywgYnV0IHN0aWxsIGEg bGFyZ2UgY2hhbmdlKS4gVGhlIHRocmVlIHJlYXNvbnMgSSdtIG5vdCBqdW1waW5nDQp0byBqdXN0 IGRvaW5nIGl0IGJ1dCBhc2sgdGhlIFdHIHRvIGNoaW1lIGluIGFyZToNCg0KKiBXZSdyZSBxdWl0 ZSBsYXRlIGluIHRoZSBwcm9jZXNzLg0KKiBJZiB3ZSBwaWNrIFsyXSBhcyBUaGUgUmVhZGluZyBv ZiA2NjkwLCB3ZSBzaG91bGQgYmUgc3VyZSBhYm91dCBpdCwgYW5kDQogIEkndmUgYmVlbiB3cm9u ZyBhYm91dCBkZXRhaWxzIG9mIHRoZSA2NjkwIHByb2Nlc3MgdG9vIG9mdGVuIHRvIGp1bXAgdG8N CiAgY29uY2x1c2lvbnMgaGVyZS4NCiogVmVyeSBmZXcgcGVvcGxlIHVzaW5nIGxpbmstZm9ybWF0 IHNlZW0gdG8gY2FyZSBhYm91dCB0aGUgc2VtYW50aWNzIG9mDQogIHRoZSBsaW5rcyBpbiBsaW5r LWZvcm1hdCwgdXNpbmcgaXQgbW9yZSBmb3IgdGhlIGxpc3Qgb2YgcmVzb3VyY2VzDQogIChsaWtl LCB3ZSBjb3VsZCBoYXZlIHVzZWQgc29tZSByZXNvdXJjZSBkZXNjcmlwdGlvbiBmb3JtYXQgaW4g dGhlDQogIGZpcnN0IHBsYWNlKS4gVGhpcyBtYWtlcyByZXZpZXdzIG9uIHByZXNlcnZpbmcgdGhl IGFjdHVhbCBsaW5rDQogIHNlbWFudGljcyAtLSB3aGljaCB3ZSBoYXZlIHRvIHRvIG5vdCBicmVh ayB0aGUgZmV3IGNhc2VzIHdoZXJlIGl0IGRvZXMNCiAgbWF0dGVyIC0tIGhhcmQgdG8gY29tZSBi eS4NCg0KDQpDaGFpcnMsIGNhbiB3ZSBldmVuIHN0aWxsIG1ha2Ugc3VjaCBhIGNoYW5nZT8NCg0K RXNrbywgZG9lcyBbMl0gY2FwdHVyZSBob3cgeW91IHJlYWQgdGhlIHJlc29sdXRpb24gcHJvY2Vz cz8NCg0KR3JvdXAsIGNhbiB3ZSBmaW5kIGFncmVlbWVudCBvbiB0aGF0IGJlaW5nIHRoZSByaWdo dCBpbnRlcnByZXRhdGlvbj8NCg0KS1INCkNocmlzdGlhbg0KDQpbMV06DQo+ICogImFuY2hvciIg YXR0cmlidXRlIE1VU1QgTk9UIGJlIHByZXNlbnQgZm9yIGEgbGluayB3aXRoIHRoZSAiaG9zdHMi DQo+IHJlbGF0aW9uICAgKGkuZS4gdGhlIGRlZmF1bHQgcmVsYXRpb24gaWYgbm9uZSBzcGVjaWZp ZWQpDQoNClRoaXMgaXMgcmVsYXRpdmVseSBoYXJkIHRvIGNoZWNrIC0tIHN1cmUgeW91IGNhbiB0 ZXN0IGZvciB0aGUgcHJlc2VuY2UsDQpidXQgaG93IGFib3V0IGlmIHNvbWVvbmUgbWFkZSBpdCBl eHBsaWNpdCBhcyByZWw9aG9zdHM/IFdoYXQgYWJvdXQNCnJlbD0ibWFuYWdlZC1ieSBob3N0cyI/ DQoNClsyXTogSSd2ZSByZWFkIGFuZCB3cml0dGVuIHRvbyBtYW55IHBocmFzaW5ncyBvZiB0aGF0 LCBtYXliZSB0aGlzIGlzDQpsZXNzIGFtYmlndW91cyAtLSB0aGUgUkZDNjY5MCBhbGdvcml0aG0g YXMgSSB0aGluayB5b3UgdW5kZXJzdGFuZCBpdDoNCg0KYGBgDQpkb2NiYXNlID0gdGhlIFJGQzM5 ODYgYmFzZSBVUkkgKGZyb20gdGhlIGVuY2Fwc3VsYXRpbmcgZW50aXR5LCBhcw0KICBsaW5rLWZv cm1hdCBoYXMgbm8gYmFzZSBlbWJlZGRlZCBpbiB0aGUgY29udGVudCkNCmhyZWYgPSBzdHJpbmcg cGFydCBiZXR3ZWVuIHRoZSBhbmd1bGFyIGJyYWNrZXRzDQphbmNob3IgPSBzdHJpbmcgdmFsdWUg b2YgdGhlIGFuY2hvciBhdHRyaWJ1dGUsIG9yIG51bGwgaWYgYWJzZW50DQp0YXJnZXQgPSByZXNv bHZlIGhyZWYgYWdhaW5zdCBkb2NiYXNlDQppZiBhbmNob3IgPT0gbnVsbDoNCiAgICBjb250ZXh0 ID0gcmVzb2x2ZSBhbmNob3IgYWdhaW5zdCBkb2NiYXNlDQplbHNlOg0KICAgIGNvbnRleHQgPSBv cmlnaW4gb2YgdGFyZ2V0DQpgYGANCg0KLS0gDQpUbyB1c2UgcmF3IHBvd2VyIGlzIHRvIG1ha2Ug eW91cnNlbGYgaW5maW5pdGVseSB2dWxuZXJhYmxlIHRvIGdyZWF0ZXIgcG93ZXJzLg0KICAtLSBC ZW5lIEdlc3Nlcml0IGF4aW9tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Wed Oct 21 06:36: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 0797A3A104D for ; Wed, 21 Oct 2020 06:36:48 -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 hIWAIAuY_VxW for ; Wed, 21 Oct 2020 06:36:44 -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 DC4673A139D for ; Wed, 21 Oct 2020 06:32:12 -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 073124012D; Wed, 21 Oct 2020 15:32:11 +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 201C2AB; Wed, 21 Oct 2020 15:32:09 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:b5e3:21a5:c6eb:f5c2]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6CF1634; Wed, 21 Oct 2020 15:32:08 +0200 (CEST) Received: (nullmailer pid 645852 invoked by uid 1000); Wed, 21 Oct 2020 13:32:07 -0000 Date: Wed, 21 Oct 2020 15:32:07 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Esko Dijk Cc: "core@ietf.org" Message-ID: <20201021133207.GD303030@hephaistos.amsuess.com> References: <20201020103159.GA311699@hephaistos.amsuess.com> <20201021113736.GC303030@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 13:36:48 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 21, 2020 at 01:21:42PM +0000, Esko Dijk wrote: > That seems clear; from this answer - how could anyone be mistaken > about the anchor i.e. which server is hosting the '/temp' resource ? > There's only one server mentioned so that's the one right :) =20 > > And for the rel=3Dhosts relation it would not make much sense to > proclaim e.g. "coap://server1 hosts coap://server2/resource" ...=20 That's intuitively clear for coap://server1 and coap://server2, but a statement like coap://server1 hosts coap+sms://+15551234567/ might make a bit more sense, and the tautological definition of the relation doesn't help much there. As the meaning is so vague, I'm loathe to make precise rules depend on it. The description in RFC6690 Section 2.2 doesn't help either; it potentially makes it worse by claiming that hosts only works with relative references in the target. That statement is probably what fueled my (probably mis?)conception about the target being resolved relative to the anchor, as only then it makes sense. (Salvaging it by saying there can't be an anchor with a hosts relation would just make it worse by breaking RD). KR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+QOFMACgkQOY0REtOk veHX/w//XmT8Yjo8jIIyNcw3X0T9YhfLuMFWaVtm0HTGfHMv1NW0USnaZ8xdj+sF FeKJsTP6W/Ij98fvrGoNGBwMZeFaMZnVZFWriEIoXSWpe3HPzlo2ttVU1YRjj1AK 9OY/G138Pu1E27IMBhjeluf7uFQ2iBIB+4OYFF8omcMx4us+KMhywNqJrvTxh8aP XhfACWSVOeL83qx23F60CDalar3neclVUJW1FJOvv1ahy3eq1LhWRzke1yl9GMXA bBCvd1dYxI8+oUqvNf5pvdrPu4oe1aO5yNIcUeGm46QiWaitNlDRcjiEZYnxwu9q QdtzyBJ89R2oR8U7ojceb066X3YLQFalStnu/ohkC0BA7+zUdKHYQ67AuSjX+jkw tQhky5Z3gKim7ssFToPsqQ8TLmJlvz0Y3nlwz2VJDbJ1ZTY0tsiQ9G9aILItGYBA 2yQksCRL9F9ta00ZdLPNTd99ZiNG0wTjP4TzWAi3TAScf1M7yG3ACnP9P2oBpuH7 oDU+gWl9wq5t5whhKAbZWin2L50XVKBIkA/z4tZC0ToGk1iQvAouUdjzgm7gEZM7 qu8AAtwQqT3I2ws68a4mUf7IOt4iGFj5CkZDCKKwXtd95o+N9hwZOgR3Qi2zjyJy dXqqT7Ew3wqTdm/sUKKs/VKPDhOtB1LRcAhfKu2RNsrazcwS3D4= =GmnG -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From nobody Wed Oct 21 06:59:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA83A0BB2 for ; Wed, 21 Oct 2020 06:59:55 -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 6CaQn8yctlMK for ; Wed, 21 Oct 2020 06:59:53 -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 1A3063A0B3E for ; Wed, 21 Oct 2020 06:59:52 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 65D004012D; Wed, 21 Oct 2020 15:59:49 +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 0E67AAB; Wed, 21 Oct 2020 15:59:48 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:b5e3:21a5:c6eb:f5c2]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8EFF434; Wed, 21 Oct 2020 15:59:47 +0200 (CEST) Received: (nullmailer pid 653273 invoked by uid 1000); Wed, 21 Oct 2020 13:59:46 -0000 Date: Wed, 21 Oct 2020 15:59:46 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Esko Dijk Cc: "core@ietf.org" Message-ID: <20201021135946.GE303030@hephaistos.amsuess.com> References: <20201020103159.GA311699@hephaistos.amsuess.com> <20201021113736.GC303030@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VV4b6MQE+OnNyhkM" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 13:59:55 -0000 --VV4b6MQE+OnNyhkM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Esko, On Wed, Oct 21, 2020 at 12:59:59PM +0000, Esko Dijk wrote: > I've swapped two lines in your item [2] plus added some comments for > clarification The swapping resolved a refactoring error of mine -- so we are aligned there. > Because this may be multi-interpretable, my idea for Limited Link > Format was to simplify the parsing by splitting into two possible > cases: 1) implicit rel=3Dhosts without 'anchor' ; and 2) any other link > with 'anchor'. It the above reading is agreed on, the rule can even be simpler: "If anchor was absent originally, it can stay absent". That would catch the same cases and some more, not depend on understanding rel, and upset the same set of implementations (those based on the 2018 understanding, and AFAIK that means it's only mine). > 1* "anchor" attribute MUST NOT be present for any link without the "rel" = attribute (this implies that this link uses the implicit rel=3Dhosts sema= ntics only) > 2* "anchor" attribute MUST be present for any link with the "rel" attribu= te (this could be any type of link, possibly using rel=3D"= managed-by hosts" or rel=3D"hosts" or rel=3Dhosts ) If we go that route (and at least a brief chair chat earlier today sounded a bit reluctant), I'd revisit the known implementations. My expectation is that these restrictions won't even be necessary. The main offender that necessitated the full-anchor-everywhere was my 2018 understanding. The change would be to reiterate in Limited Link Format that unlike in the Link header, an absent anchor means the context is origin-of(resolved-target), and then no further conditions on rel need apply. So probably it'd be either leave-it-and-say-why-it's-like-that, or going even a step further than you are suggesting. > There is one more consideration for the current RD draft - in case we > decide to keep the explicit "anchor" attribute in all the examples. > Because RFC 6690 is a normative reference, the assumption of the > reader currently should still be that the "anchor" attribute that's > added in all the example is just superfluous i.e. > > * an RD implementation may elide it , following RFC 6690 rules (in > the interpretation as coded at the top of this email.) and Section > 2.3 of 6690 I disagree here -- just because we normatively use 6690 doesn't mean we can't profile it and prescribe that a particular serialization needs to be used. > * an RD client doing lookups may ignore it, following RFC 6690 rules > in Section 2.3 =2E.. and here: 6690 says that "A consuming implementation can, however, choose to ignore such links." (and not such attributes). The client woud just ignore all resource lookup results, and the implementer would thus need to implement (at least rudimentary) support for the anchor attribute. KR, and thanks for all your input Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --VV4b6MQE+OnNyhkM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+QPs8ACgkQOY0REtOk veEByg/9HDLgzENo1nj33RvyiLVLjaFfH0Qbhsrdy/TNaQDI6kg9YcvfQXiOgku1 SUp3unlMbSfbUyeJ+5UlUbCYEuPvWBdowh/QXw6zf17w5Yv7BEwVmBUAxP2O1hVL 9Jczfq37nDb4Z1pCZ4Qt0+NzeFeXOcsRCc2xsRezutHb+Z4xVZ4J6kevZwnDiStL vJDK6bDEBdtYCwwz/6hcCmyKPRnNGR5S1O0iA5IthIvgMPnetuLyl2IpuGigTKhx sMTjJb42jHl53NsoT0AF8FNBIwaG3McdNY98zOKVJ9Mj/YyoJHo0ZskS1T8qTkZR jXbvCnS2UHkanIx/camMuafPHvQUvpTzix+zzUyuBLJONKti26HzKnSIDYWme4Rj ch7c0jRwnnQ8A0wXracFgHknNzWtkaGmfZXfyCDPeC/+BK2koHCTGNfmJdnGZQn+ Tab80u0d8RnAgYRw6pMKeOfwCdht2atMmqigugaZJHwRn2Vylw7vqrUKq5s8VViM i1aAmd5lEh71s9Lht0ZFgEz2sKNN8+xUlB4jXd5QWLm/IZonXEGQC0xnRfqZMyQE 1MAgwyOMKaS99Lz/KW3Pv5IsL7P1sZvBSp5mi2+BCpZv3YRd9ijJvsJ2Z5yByX1u fEr4qYifNVvFNObLtc9Ufm5C6DZdSWYM2cCT1UVQs30MjZtHxrs= =On/f -----END PGP SIGNATURE----- --VV4b6MQE+OnNyhkM-- From nobody Thu Oct 22 15:22: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 BB5543A0898 for ; Thu, 22 Oct 2020 15: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 RGTpYkZsHbLE for ; Thu, 22 Oct 2020 15:21:58 -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 2137C3A0895 for ; Thu, 22 Oct 2020 15:21:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CD271389AF; Thu, 22 Oct 2020 18:28:16 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qGfY9xDFx7Mf; Thu, 22 Oct 2020 18:28:16 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70183389AD; Thu, 22 Oct 2020 18:28:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 909041FB; Thu, 22 Oct 2020 18:21:55 -0400 (EDT) From: Michael Richardson To: Christian =?us-ascii?Q?=3D=3Fiso-8859-1=3FB=3FTS4gQW1z=2FHNz=3F=3D?= , Core WG mailing list In-Reply-To: <20201021000327.GB303030@hephaistos.amsuess.com> References: <20201021000327.GB303030@hephaistos.amsuess.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] (not only) RD: Authorized servers 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, 22 Oct 2020 22:22:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm not very well informed about the RD document. I have skimmed the document at various intervals. And these comments are rather late, I agree. It seems to me that a fundamental problem with the whole RD concept is that it must make the secure identities part of the result. It's not really interested to say that 2001:db8:3::127 has a oic.d.sensor. What's interesting is to say that principal X, (who was seen at address 200= 1:db8:3::127), has an oic.d.sensor. Section 7.1 has placed the RD in the place of trying to be a gate keeper for accurate information, which is just can't do in a general way for arbitrary clients with abitrary policies. I think that it would be much simpler and more secure if we restarted and d= id the security first rather than last. That does mean that one has to pick o= ne (or a very small number) of security systems to work with. This is not a place were we can or should attempt to generalize. I'm sorry if this is a rather depressing suggestion. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+SBgMACgkQgItw+93Q 3WVl+gf/Sp5yPXvhuNPc3Q9tKxyUwOnIGmOfCRMaQhIT9Hpog89xlHajJjHu0Sa1 ij9600GtH5MaKY+Kqav6yqbEl778WKaooL+3UEkxTQsWfW147g35mCIbyzrwm8lR /KmsQTkUo/4wkviJLs1QDvrmwFOeV6XywcwZy9RK8VkRlJRJTJeINbLGNlIWJ6jJ ziFtfpZQt28DmoRCXDT9y7kFiCEih3wp8+xCiP3EbNwhl/Iq1Khs3Z/yggy4IVBg k8wA+eI6fd76KOP3uHl9LCg5QS6lGCXauWzPd6xOnIT1Oukcv8kLWMSfLEaianEa pZQJfvk+AKMg5dQi/Jbapp1rdXtXAQ== =3LRb -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 23 00:05:02 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 22EDC3A0957; Fri, 23 Oct 2020 00:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 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, RCVD_IN_DNSWL_LOW=-0.7, 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 HhidXoHKikdA; Fri, 23 Oct 2020 00:04:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7064B3A093D; Fri, 23 Oct 2020 00:04:59 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4CHZx55pCxz8xc9; Fri, 23 Oct 2020 09:04:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603436697; bh=6YlMJu5ak5S3pJSevccTdF+zGli8VP4Bjtk7Bm9CL0I=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Imsg8XOmKh/Im8EWqG/ucWwmXO7Do5cQlOl60/04MvOlSaSWkM8zuq1Y091GIZovq /ISGyipPnetjaG8BM48ihnwUFgTDLAB9RwxSfuEHe0c0k3wd/6drrnWtcK/CxiHhME BJkYUOywT0czwE3FoPXkyIdtSQvjXL3/AkRqDhKjt8nhGeXOIC7+rxNo2aken7muee VgXD6F3jDfBwo6wAggmH6QRa7lm3izhLPJmDGRL72c/P0fcBwlqf8kLFTgCPJZkRAH hyuRvQjcYhgq/vRbMUrl5lKBQP9XLmr1D9VW5xqj6uLvmaN2BNzLB8Wvi9IQRsmJtE hMkxdlfDK0DQw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4CHZx54flRz3wbX; Fri, 23 Oct 2020 09:04:57 +0200 (CEST) From: To: "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" Thread-Topic: draft-ietf-core-new-block: Find a better name for the options Thread-Index: AdapCRjyPLyqWm4UTi2bgt6a6EIumw== Date: Fri, 23 Oct 2020 07:04:55 +0000 Message-ID: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315657B6OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [core] draft-ietf-core-new-block: Find a better name for the options 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, 23 Oct 2020 07:05:01 -0000 --_000_787AE7BB302AE849A7480A190F8B9330315657B6OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As a follow-up to the interim meeting, we listed some proposals in https://= doodle.com/poll/2uv4vfez9sq77fa9. Please indicate your preferred one by the= end of next week so that this change can be included in -02. Please note that: * Q: Quick * LL: L(arge amounts of data with)L(ess packet interchanges) * FLLF: F(aster transmission rates for)L(arge amounts of data with)= L(ess packet interchanges as well as)F(aster recovery) If we don't have sufficient input or none of the proposals are acceptable, = we will maintain the current names. Thank you. Cheers, Jon & Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_787AE7BB302AE849A7480A190F8B9330315657B6OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi all,

=  

As a follow-up to the interim meeting, we listed some propos= als in https://doodle.com/pol= l/2uv4vfez9sq77fa9. Please indicate your preferred one by the end of ne= xt week so that this change can be included in -02.

 

Please note that:

·         Q: Quick

· &nb= sp;       LL: L(arge amounts of data with)L(ess p= acket interchanges)

·         FLLF: F(aster transmission rates for)L(ar= ge amounts of data with)L(ess packet interchanges as well as)F(aster recove= ry) 

If we don’t have sufficient input or none of the propo= sals are acceptable, we will maintain the current names.

 

Thank you.

 

Cheers,

Jon & Med

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_787AE7BB302AE849A7480A190F8B9330315657B6OPEXCAUBMA2corp_-- From nobody Fri Oct 23 02:19:15 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 05B923A0ADA; Fri, 23 Oct 2020 02:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Mue0sWdsEC6w; Fri, 23 Oct 2020 02:19:11 -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 9C1C23A0AD8; Fri, 23 Oct 2020 02:19:10 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CHdvw2j59zySd; Fri, 23 Oct 2020 11:19:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 23 Oct 2020 11:19:07 +0200 Cc: "core@ietf.org" , "draft-ietf-core-new-block@ietf.org" X-Mao-Original-Outgoing-Id: 625137547.623817-9bf221355217c07f1f6decfd2f39807e Content-Transfer-Encoding: quoted-printable Message-Id: References: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Find a better name for the options 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, 23 Oct 2020 09:19:14 -0000 On 2020-10-23, at 09:04, = wrote: >=20 > FLLF That would inevitably become =E2=80=9Cfluffy block-wise=E2=80=9D. Actually, I still thing that =E2=80=9Ctough block-wise=E2=80=9D is most = descriptive. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 23 09:20: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 62DA33A0FDF for ; Fri, 23 Oct 2020 09:20:18 -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 0_EVxJuDWT7T for ; Fri, 23 Oct 2020 09:20:15 -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 0DD0D3A101F for ; Fri, 23 Oct 2020 09:20:14 -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 1kVznY-0000jL-MG for core@ietf.org; Fri, 23 Oct 2020 17:20:12 +0100 From: To: Date: Fri, 23 Oct 2020 17:19:59 +0100 Message-ID: <118201d6a958$5ac8bed0$105a3c70$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1183_01D6A960.BC8D26D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdapWFM2SZWQj33aTfeFKldKXygYbQ== Content-Language: en-gb Archived-At: Subject: [core] draft-ietf-core-new-block: Congestion Control 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, 23 Oct 2020 16:20:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1183_01D6A960.BC8D26D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, At the virtual meeting on 22nd Oct 2020, I raised the issue of how better to handle Congestion Control once MAX_PAYLOAD (default 10 blocks) had been hit [1] Slide 7. The bottom line issue is there is a delay of ACK_TIMEOUT (CC requirement) after every transmission of MAX_PAYLOAD blocks which is fine. This delay can be reduced by using CON for the MAX_PAYLOAD packet and triggering the send of the next set of data when the ACK is received, but is likely to create other timeout issues in a lossy environment (especially is the loss is un-directional as in DDoS pipe flooding). Use of NON will always have this ACK_TIMEOUT delay unless there is a way stimulating a response from the peer (which may get lost) which can trigger the sending of the next MAX_PAYLOAD packets (or indicate some of the previous packets are missing). It was suggested that the No-Response RFC7967 could be used. I mentioned that I had looked at it, but did not use it for reasons that I could not immediately recall. RFC7967 is not an IETF submission and is Informal. The No-Response is also defined for Requests, but not Responses (needed for Quick-Block2) which is why I did not continue down that route - updating the RFC to include Responses could be an interesting challenge... I am not convinced that supporting Responses with this option would work with the general CoAP estate out there - especially as the RFC is titled 'No Server Response'. Which brings me back to creating another option (not keen on this) or to have a block layout definition that is different for Quick-Block1/2 when compared to Block1/2. My suggestion is then that the block definition layout is NUM R M SZX instead of NUM M SZX, where R bit, if set, requests the peer to send an appropriate response which, if received, can trigger the sending of the next MAX_PAYLOAD packets. [One cannot assume that MAX_PAYLOAD will be the same at both the client and server] Quick-Block1 solicited response would be a 2.31 or 4.08 if some packets were missing. Quick-Block2 solicited response for a NON sent from the server gets more interesting. It should be a NON and a request (unless we want to consider role reversal of client/server at this point). The best I can think of is the client sends off a request for the next MAX_PAYLOADS (i.e. GET request with MAX_PAYLOAD worth of Quick-Block2 options) which is messy. However... It was raised in the meeting about the meaning of "repeat request" in 3.4 [2] . The text does need clarification, but the challenge here is relevant to the previous para above. The scenario is that a GET with Quick-Block2 where block.num is 0 can mean one of 2 things. It can be a request saying "send me all of the date for this resource" (i.e. all of the blocks) or it can be a request for a single block that that did not arrive (but block.num =1 etc. did arrive). The M bit is used to differentiate as to whether the server responds with a single block or a set of blocks. In terms of the solicited response above, the GET request could just contain the next Quick-Block2 needed and the use of the M bit indicates that that it is asking for an individual block or request the net set of blocks. 3.4 [2] current definition of the use of M bit in Quick-Block2 requests may need to be inverted - i.e. unset if a single block is requested and set if it is this block and following blocks requested. [This then does allow Quick-Block2 to request individual blocks at offset X as allowed by Block-2 - I expressed that this might be difficult in the meeting]. I do not know why the Block1/2 option is up to 3 bytes long - this means that block.num can have a maximum value of 2^20-1 - which supports a maximum transfer size of ~1GB if individual block size is 1024. Networks with smaller PDUs will be less because of the block size reduction. Is there any reason as to why this could not be extended to 4 bytes (or completely relaxed to 8 bytes) to support larger transfers? I am open to other suggestions as to how to move forward with potentially reducing the ACK_TIMEOUT CC turnaround requirement if the network can cope. Regards Jon [1] https://www.ietf.org/proceedings/interim-2020-core-11/slides/slides-interim- 2020-core-11-sessa-coap-block-wise-transfer-options-for-faster-transmission- draft-ietf-core-new-block-01-00 [2] https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-01 ------=_NextPart_000_1183_01D6A960.BC8D26D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

At the virtual meeting on 22nd Oct 2020, I = raised the issue of how better to handle Congestion Control once = MAX_PAYLOAD (default 10 blocks) had been hit [1] Slide = 7.

 

The bottom line issue is there is a delay of = ACK_TIMEOUT (CC requirement) after every transmission of MAX_PAYLOAD = blocks which is fine.  This delay can be reduced by using CON for = the MAX_PAYLOAD packet and triggering the send of the next set of data = when the ACK is received, but is likely to create other timeout issues = in a lossy environment (especially is the loss is un-directional as in = DDoS pipe flooding).

 

Use of NON = will always have this ACK_TIMEOUT delay unless there is a way = stimulating a response from the peer (which may get lost) which can = trigger the sending of the next MAX_PAYLOAD packets (or indicate some of = the previous packets are missing).

 

It was = suggested that the No-Response RFC7967 could be used.  I mentioned = that I had looked at it, but did not use it for reasons that I could not = immediately recall.

 

RFC7967 is = not an IETF submission and is Informal.  The No-Response is also = defined for Requests, but not Responses (needed for Quick-Block2) which = is why I did not continue down that route – updating the RFC to = include Responses  could be an interesting challenge…..  = I am not convinced that supporting Responses with this option would work = with the general CoAP estate out there – especially as the RFC is = titled ‘No Server Response’.

 

Which brings = me back to creating another option (not keen on this) or to have a block = layout definition that is different for Quick-Block1/2 when compared to = Block1/2.  My suggestion is then that the block definition layout = is NUM R M SZX instead of NUM M SZX, where R bit, if set, requests the = peer to send an appropriate response which, if received, can trigger the = sending of the next MAX_PAYLOAD packets.

 

[One cannot = assume that MAX_PAYLOAD will be the same at both the client and = server]

 

Quick-Block1 solicited response would be a 2.31 or = 4.08 if some packets were missing.

 

Quick-Block2 = solicited response for a NON sent from the server gets more = interesting.  It should be a NON and a request (unless we want to = consider role reversal of client/server at this point).  The best I = can think of is the client sends off a request for the next MAX_PAYLOADS = (i.e. GET request with MAX_PAYLOAD worth of Quick-Block2 options) which = is messy. However…..

 

It was = raised in the meeting about the meaning of “repeat request” = in 3.4 [2] . The text does need clarification, but the challenge here is = relevant to the previous para above.  The scenario is that a GET = with Quick-Block2 where block.num is 0 can mean one of 2 things.  = It can be a request saying “send me all of the date for this = resource” (i.e. all of the blocks) or it can be a request for a = single block that that did not arrive (but block.num =3D1 etc. did = arrive).  The M bit is used to differentiate as to whether the = server responds with a single block or a set of blocks.  In terms = of the solicited response above, the GET request could just contain the = next Quick-Block2 needed and the use of the M bit indicates that that it = is asking for an individual block or request the net set of = blocks.  3.4 [2] current definition of the use of M bit in = Quick-Block2 requests may need to be inverted – i.e. unset if a = single block is requested and set if it is this block and following = blocks requested.

 

[This then = does allow Quick-Block2 to request individual blocks at offset X as = allowed by Block-2 – I expressed that this might be difficult in = the meeting].

 

I do not know why the Block1/2 option is up to 3 bytes = long – this means that block.num can have a maximum value of = 2^20-1 – which supports a maximum transfer size of ~1GB if = individual block size is 1024. Networks with smaller PDUs will be less = because of the block size reduction.  Is there any reason as to why = this could not be extended to 4 bytes (or completely relaxed to 8 bytes) = to support larger transfers?

 

I am open to = other suggestions as to how to move forward with potentially reducing = the ACK_TIMEOUT CC turnaround requirement if the network can cope. =

 

Regards

 

Jon

 

[1] https://www.ietf.org/proce= edings/interim-2020-core-11/slides/slides-interim-2020-core-11-sessa-coap= -block-wise-transfer-options-for-faster-transmission-draft-ietf-core-new-= block-01-00

[2] https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-01=

 

------=_NextPart_000_1183_01D6A960.BC8D26D0-- From nobody Fri Oct 23 09:42: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 5A7213A100C for ; Fri, 23 Oct 2020 09: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, 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 bC2L_NGTsOrS for ; Fri, 23 Oct 2020 09:42:34 -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 CE2D33A100A for ; Fri, 23 Oct 2020 09:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C9199389A9; Fri, 23 Oct 2020 12:48:56 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WwB7zDCB5Gks; Fri, 23 Oct 2020 12:48:56 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C04338991; Fri, 23 Oct 2020 12:48:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9C15570D; Fri, 23 Oct 2020 12:42:32 -0400 (EDT) From: Michael Richardson To: supjps-ietf@jpshallow.com cc: core@ietf.org In-Reply-To: <118201d6a958$5ac8bed0$105a3c70$@jpshallow.com> References: <118201d6a958$5ac8bed0$105a3c70$@jpshallow.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Fri, 23 Oct 2020 12:42:32 -0400 Message-ID: <4020.1603471352@localhost> Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Congestion Control 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, 23 Oct 2020 16:42:36 -0000 If I understood yesterday, it is possible to send a single package asking for a specific offset of data, and then get 10 packets worth of reply? Is that correct? From nobody Fri Oct 23 10:03:27 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 545C93A102F for ; Fri, 23 Oct 2020 10:03:26 -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 NzGQZ1xH3hjx for ; Fri, 23 Oct 2020 10:03:24 -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 D0D363A102E for ; Fri, 23 Oct 2020 10:03:21 -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 1kW0TF-0000kX-M6; Fri, 23 Oct 2020 18:03:17 +0100 From: "Jon Shallow" To: "'Michael Richardson'" , References: <118201d6a958$5ac8bed0$105a3c70$@jpshallow.com> <4020.1603471352@localhost> In-Reply-To: <4020.1603471352@localhost> Date: Fri, 23 Oct 2020 18:03:04 +0100 Message-ID: <119e01d6a95e$5f8acc00$1ea06400$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWlqb2iKC3R3viCvjymGPo29qZmgHUEiDOqRbp6EA= Content-Language: en-gb Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Congestion Control 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, 23 Oct 2020 17:03:26 -0000 Hi Michael, The original concept of Quick-Block2 was to get all of the data over in an efficient manner (subject to congestion control) and reduce the number of requests needed as a part of that process. An Observe trigger just needed to send over all of the data within the body. "Selective" access to resource data was not required but is provided by Block2 (but missing blocks can be re-requested using Quick-Block2). When asked yesterday, I knew that there were likely to be issues in this area and my answer was not well thought through - hence what you picked up. It is possible to ask for a specific offset and the blocks following as the Quick-Block2 option can be used multiple times in a single GET request - they would be the base offset (as indicated by block.num and block.szx) and the remaining options used for block.num+1, block.num+2 etc. If more than MAX_PAYLOAD options were defined, the first MAX_PAYLOAD would come back, then an ACK_TIMEOUT pause and then the next blocks etc. Regards Jon > -----Original Message----- > From: Michael Richardson [mailto: mcr@sandelman.ca] > Sent: 23 October 2020 17:43 > To: jon@jpshallow.com > Cc: core@ietf.org > Subject: Re: [core] draft-ietf-core-new-block: Congestion Control > > If I understood yesterday, it is possible to send a single package asking for > a specific offset of data, and then get 10 packets worth of reply? > > Is that correct? From nobody Fri Oct 23 14:19:55 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 DD5DB3A0EE6; Fri, 23 Oct 2020 14:16:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348777889.5087.13954749917338449918@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:18 -0700 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 109 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:16:22 -0000 Dear Marco Tiloca, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (1:00 requested) Tuesday, 17 November 2020, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- core Session 2 (2:00 requested) Friday, 20 November 2020, Session III 1600-1800 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: ace cbor t2trg cose lake artarea Technology Overlap: teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw Key Participant Conflict: irtfopen rats suit dnssd netconf netmod emu dots anima asdf People who must be present: Barry Leiba Jaime Jimenez Marco Tiloca Resources Requested: Special Requests: Plse also avd any potntlly IoT reltd BOFs&amp;PRGs tht mght cme up. Prefer some time between the two meetings (48 h or more). Second meeting often is 40 people. --------------------------------------------------------- From nobody Fri Oct 23 14:56: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 95DFD3A096B; Fri, 23 Oct 2020 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS5aT5_cwUgt; Fri, 23 Oct 2020 14:55:59 -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 DDE2B3A0969; Fri, 23 Oct 2020 14:55:58 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CHyj80bmnzyQH; Fri, 23 Oct 2020 23:55:56 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 625182955.352785-88957ab6bab68974b1cdf3ee5b0db56d Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 23 Oct 2020 23:55:55 +0200 Message-Id: <15D90A88-9959-4417-8F87-1C8A35E9DC0A@tzi.org> To: Ace Wg , "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF109: "FINAL" AGENDA 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, 23 Oct 2020 21:56:02 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF109. Remember that further agenda changes can still happen. Very little has changed with respect to the draft agenda. WEBTRANS does meet, and CFRG and IRTFOPEN have been moved around (CFRG now on top of CORE, unfortunately). All times *on my agenda* are in UTC (the default page is UTC+0700). https://datatracker.ietf.org/meeting/agenda-utc might be handy. Note that both EU and US are on winter time (standard time) then. Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 9, 2020 0500-0700 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, November 13, 2020 0500-0700 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, November 16, 2020 0500-0700 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 3 IRTF qirg Quantum Internet Research Group Rm 5 RTG raw Reliable and Available Wireless WG Rm 6 SEC *** lake Lightweight Authenticated Key Exchange WG 0730-0830 Session II Rm 2 INT add Adaptive DNS Discovery WG Rm 3 IRTF maprg Measurement and Analysis for Protocols Rm 6 SEC *** cose CBOR Object Signing and Encryption WG 0900-1100 Session III Rm 1 ART jsonpath JSON Path WG Rm 2 ART webtrans WebTransport WG Rm 7 SEC secdispatch Security Dispatch WG Rm 8 TSV tsvwg Transport Area Working Group WG TUESDAY, November 17, 2020 0500-0700 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF cfrg Crypto Forum Rm 7 SEC gnap Grant Negotiation and Authorization Protocol WG 0730-0830 Session II Rm 5 RTG babel Babel routing protocol WG Rm 6 SEC tls Transport Layer Security WG 0900-1100 Session III Rm 1 ART *** asdf A Semantic Definition Format for Data and = Interactions of Things WG Rm 5 RTG apn Application-aware Networking BOF Rm 8 SEC *** rats Remote ATtestation ProcedureS WG WEDNESDAY, November 18, 2020 0500-0700 Session I Rm 3 INT madinas MAC Address Device Identification for Network = and Application Services BOF Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 7 SEC *** ace Authentication and Authorization for Constrained = Environments WG Rm 8 TSV quic QUIC WG 0730-0830 Session II Rm 3 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes = WG Rm 4 INT *** drip Drone Remote ID Protocol WG Rm 7 SEC *** teep Trusted Execution Environment Provisioning WG Rm 8 TSV tsvwg Transport Area Working Group WG THURSDAY, November 19, 2020 0500-0700 Session I Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC saag Security Area Open Meeting 0730-0830 Session II Rm 1 ART *** cbor Concise Binary Object Representation Maintenance = and Extensions WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 RTG detnet Deterministic Networking WG Rm 5 SEC acme Automated Certificate Management Environment WG 0900-1100 Session III Rm 4 OPS v6ops IPv6 Operations WG Rm 6 RTG *** roll Routing Over Low power and Lossy networks WG Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG FRIDAY, November 20, 2020 0500-0700 Session I Rm 2 INT add Adaptive DNS Discovery WG Rm 6 RTG rift Routing In Fat Trees WG Rm 7 SEC emu EAP Method Update WG 0730-0830 Session II Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 INT *** lwig Light-Weight Implementation Guidance WG Rm 3 OPS anima Autonomic Networking Integrated Model and = Approach WG Rm 6 SEC *** suit Software Updates for Internet of Things WG Rm 7 TSV tsvarea Transport Area Open Meeting 0900-1100 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT 6man IPv6 Maintenance WG Rm 5 IRTF irtfopen IRTF Open Meeting Rm 8 TSV masque Multiplexed Application Substrate over QUIC = Encryption WG From nobody Sat Oct 24 13:46:56 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936A23A10E9 for ; Sat, 24 Oct 2020 13:46:55 -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 Fk5I2Y7iWlSD for ; Sat, 24 Oct 2020 13:46:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3528B3A10E6 for ; Sat, 24 Oct 2020 13:46:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F1A98389A0; Sat, 24 Oct 2020 16:53:18 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EuGTkolJyQqa; Sat, 24 Oct 2020 16:53:16 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1FAC43899F; Sat, 24 Oct 2020 16:53:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EF5696E2; Sat, 24 Oct 2020 16:46:47 -0400 (EDT) From: Michael Richardson To: "Jon Shallow" cc: core@ietf.org In-Reply-To: <119e01d6a95e$5f8acc00$1ea06400$@jpshallow.com> References: <118201d6a958$5ac8bed0$105a3c70$@jpshallow.com> <4020.1603471352@localhost> <119e01d6a95e$5f8acc00$1ea06400$@jpshallow.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Congestion Control 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, 24 Oct 2020 20:46:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jon Shallow wrote: > The original concept of Quick-Block2 was to get all of the data over = in > an efficient manner (subject to congestion control) and reduce the > number of requests needed as a part of that process. An Observe > trigger just needed to send over all of the data within the body. > "Selective" access to resource data was not required but is provided = by > Block2 (but missing blocks can be re-requested using Quick-Block2). > When asked yesterday, I knew that there were likely to be issues in > this area and my answer was not well thought through - hence what you > picked up. I'm asking if a return reachability check is needed before the multiple packet reply. That is, is there an amplication attack possible here is one can forge the source address. It might be that nobody will never use *-Block[12] (I also like Robust) without an OSCORE context, in which case there is probably enough security = to prevent abuse by forged source address. > It is possible to ask for a specific offset and the blocks following = as > the Quick-Block2 option can be used multiple times in a single GET > request - they would be the base offset (as indicated by block.num and > block.szx) and the remaining options used for block.num+1, block.num+2 > etc. If more than MAX_PAYLOAD options were defined, the first > MAX_PAYLOAD would come back, then an ACK_TIMEOUT pause and then the > next blocks etc. So, given a Christmas-Tree-Packet (largest packet, every possible option space used, every extension turned on...) how much data can I get back? :-) If it is legit to include multiple copies of the options, can I ask for the same offset to be sent to me multiple times? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+UkrcACgkQgItw+93Q 3WVObQf7BsfNL+mEHJd3reJ/wVowk4xPgmQxFAQEyaciTJbnmmF/arsNCgGx9JIu b7v0GHIFT7PxIdH+jEKwvZN7tNrT+yrgBouvwDbLmNlLWLBEks8xvcE+G6rgOPxS nqGyY2MrUZ3sLoymqxMN+9E65ldSpe9JOaLVnkQb+m6F+bxZzsNUhbSr7T2ScQQ2 3NQcj367i/EEYpfBchxCWaR1Zx5alEfgM8G1Y/Hjd8oIaoot1ItFv2nXwULDQbYY N5AL9X1Eo+zyKeiWpatBT68Ze6k5OUgopl2sjz2LFYA5u3DyDW8JwJE2GrySTIbM nSvWRYvrWy+1BufOK5GpnHMNUlc8Lg== =NA46 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 26 02:28:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACC43A1A02 for ; Mon, 26 Oct 2020 02:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIrtyq8lj9n6 for ; Mon, 26 Oct 2020 02:28:47 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2118.outbound.protection.outlook.com [40.107.21.118]) (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 299E63A19FF for ; Mon, 26 Oct 2020 02:28:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R6gvlzBaPsk/FncpHoJIUaszk4eNHLMLT3/11V/pNNrg5So3uYgJKarX+yO00bp7WklU6qrECScVUx9VZi4sus8H8GsxNeUUcoGyUZJb6gh44s+g4HgqUrb4hyITPc/PtB9cFKC+0JBirRUIEAhf3rk+It9Pfvp9OS+qxdiCGLLG6c4KAL90Dz4TZqsiZyI/c4nAbRcOAEJFfDnDjlxlkczWSlRIp/xaB7LTWLp3mFMnNf4kH9roHBk5QxccFmLDaXSppRJRut0p1ofi918oqJfCalHxw2PnKbP9h/atD5GGg1Xpb8n8DrZmcZDCrXbSqSkeb0sgXBA1GAo86rDLEA== 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=1R/zcy4BxX+5+tpsx42MzSujh5KbyZivXlMfKF0RRVY=; b=Z85qs1ySoAPnDKtvON3SsFUNSfCFT6HBK/v607rPpYUBDgkzcuq0B3WwOdql1T1BOCOMZE1XYmH8B9H/gE8d9/UTehy+GQCkrnj0ljCDqchZJzBU6+fOPi3f52lLvANQUpSDNTitq0ChrRwENkxG3lnEss7w53D00KeXEH9AgOgodol0wpWgnZtd3cCDNu5wdtRmMVBGNjcnih2U1YSUEilEl1VzST8E/V/0aOTVoN9xZo9F9rA96DaKG7wvTb7Bdu6IRH4PpU0DU+BMmdA4N5HatU+vXme3mMuogS1gmbS5L3O63YvxZ94MMQpgfJj0pHHOtN8lSGZncDDWKlxopA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1R/zcy4BxX+5+tpsx42MzSujh5KbyZivXlMfKF0RRVY=; b=EbxEmZ61xfEqJ2LhsGSDMCtlBv6Paw7I4zrU1xQiGLh2P3Dj6i2xakpbjBoc4xrxsq68sBNuLDYVUVAt8R1qyT+oMB/YO9F40Z7iDTTM7gG7JUA37gWfXhcnMFaZYblQmCVqzqtoKBS6f5vamprEzp/nQWtcf7D3feCmW7U32+4= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0035.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:59::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.23; Mon, 26 Oct 2020 09:28:43 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3499.018; Mon, 26 Oct 2020 09:28:43 +0000 From: Esko Dijk To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "core@ietf.org" Thread-Topic: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? Thread-Index: AdagiZ7ddTpjV6VySOOkvoVV5WS9KQGQp6uAAC9rtEAABSmPAAABpo/AAAGlLiAAALQfgADxGRJw Date: Mon, 26 Oct 2020 09:28:43 +0000 Message-ID: References: <20201020103159.GA311699@hephaistos.amsuess.com> <20201021113736.GC303030@hephaistos.amsuess.com> <20201021133207.GD303030@hephaistos.amsuess.com> In-Reply-To: <20201021133207.GD303030@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:831:730a:9dc6:3ef3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc948f16-1f72-450b-7ede-08d87991880c x-ms-traffictypediagnostic: AM4P190MB0035: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2+tGl9ls2HJ8qNw98yg/CI4SLeEIIev/6BjCV2EO77CWBZWnrjoRmZc/EVJE3iCI9ie+zWU2wYkkCN4jhIAFyzrqPwmK1j64IHd1ywAooPwkHFa/CWTVfHfxVkZeHixlTJnZfrzCDW7QNcF4O6GU4ZRVuHaKTI/HZjlaNpTju9Zelf24nY4AUSS59NAbkSY8WBeqg0Ti2TU7B4w8rvI6o0cY7MtJtIovLtFsYgT+EHbLjy7zDKFBCDYyD3ybTj57rX7kCDzHh/AyxUUDGhOSHePFsDVs/Txh2+5iEhoGUBVwXtqAS5FzoPiKwffv8l8cqgHo44cDHvaLT7a124S9hA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(396003)(39830400003)(136003)(6506007)(66446008)(7696005)(55016002)(53546011)(8936002)(8676002)(52536014)(6916009)(66946007)(66476007)(76116006)(44832011)(66556008)(64756008)(5660300002)(2906002)(71200400001)(83380400001)(316002)(4326008)(33656002)(186003)(9686003)(66574015)(478600001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: UAAhl0X61WALayNrWUBAw6X9Wg+cn5xShxz5nG2hX0eVTm6FW2ops4cUrPQPfWR42QkBrvoNdGZxWh4IlKw0UDluzfl4v0I7KTDS7l2l4+cp7X7g9XUU0DcNUUkDyT2fmWABVKCl39jX2XEJ2ot7uKt42WizcUAdJBI+upbxLyf5tgCyPqF44FJEruIOTUDp415jJ7xnS9/hME9B+rFdhpB8/oLOk+eHvGQz5lSDTaAQ3O7PxKqTzdEzH9g3mxmbVD7kO/fstXV+bbYsAPUFi7wrIqs2KktSN9oBByZzlpUdqciVuqt1LjlqNpqSQOCWTOFlOv7bOVH/5NgefqTMNf7QBHkb+9qg2Rg5yvZyr/ba6zKpxPibauyq23JGyYXwt//RFssl/p1PxdQ0TIJbj6WQiHwDQRchzHzfCv0AVxZciSTk1NFTxZX1/vOavjWJ/tHmOjmj75ddWT3FDFHJBbOTdprF8V8r+sMgnXAHjPl/z3lpC1vDBHGM1o27uiltnVtPDyQpTckO1bPPRz9CkNh2kpvKdyXlwSP61aaVNfX0ywgAcn9GVaupWgCgfsFOcb7pdLjaivrhP4Qpb8mAa5BOhWQ299IegF/Gdftqy0knmVvHv5AiIB6mWskqBNRPs9EZYd8YHnLmmhFslU+9o6UYaflVM5w5XyxVPb9zK/J8MsUN5uysCqOqCudgIW4GMfOc8LP2TCDwblr9PudTzg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fc948f16-1f72-450b-7ede-08d87991880c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2020 09:28:43.1449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zH/G78oOWVUNEhHnWFJr/4sCMJsMR61sgL4o3GtYIQxzgCvPbpCoCPuZVDO9RVHXbWUQr2//LOglLliMH17922GXfl64hB1Z6DJoMI38LRo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0035 Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 09:28:50 -0000 SGVsbG8gQ2hyaXN0aWFuLA0KDQo+IHN0YXRlbWVudCBsaWtlIGNvYXA6Ly9zZXJ2ZXIxIGhvc3Rz IGNvYXArc21zOi8vKzE1NTUxMjM0NTY3LyBtaWdodCBtYWtlDQo+IGEgYml0IG1vcmUgc2Vuc2Us IGFuZCB0aGUgdGF1dG9sb2dpY2FsIGRlZmluaXRpb24gb2YgdGhlIHJlbGF0aW9uDQoNClRvIG1l IHRoaXMgbG9va3MgYXMgaWYgbm90IGludGVuZGVkIGJ5IFJGQyA2NjkwICwgYmVjYXVzZSB0aGUg c2VydmVyIGNvYXA6Ly9zZXJ2ZXIxIGlzIGEgZGlmZmVyZW50IHNlcnZlciB0aGFuIHRoZSBvbmUg b24gY29hcCtzbXM6Ly8rMTU1NTEyMzQ1NjcgLiAgQXQgbGVhc3QgcGVyIFJGQyA3MjUyLCBvbmUg c2VydmVyIGlzIG9uZSBlbmRwb2ludC4gU28gZGlmZmVyZW50IGVuZHBvaW50IGlzIGFsd2F5cyBh IGRpZmZlcmVudCBzZXJ2ZXIsIG9yIG5vdD8NCihJbnRlcmVzdGluZyB0byBub3RlIGlzIHRoYXQg Zm9yIGNsaWVudHMgaXQgaXMgc2ltaWxhcmx5IGRlZmluZWQgaW4gUkZDIDcyNTIsIGlmIGEgQ29B UCBjbGllbnQgY2hhbmdlcyBpdHMgb3V0Z29pbmcgVURQIHBvcnQgaXQgYmVjb21lcyBhIGRpZmZl cmVudCBjbGllbnQuKQ0KDQo+IFRoZSBkZXNjcmlwdGlvbiBpbiBSRkM2NjkwIFNlY3Rpb24gMi4y IGRvZXNuJ3QgaGVscCBlaXRoZXI7IGl0DQo+IHBvdGVudGlhbGx5IG1ha2VzIGl0IHdvcnNlIGJ5 IGNsYWltaW5nIHRoYXQgaG9zdHMgb25seSB3b3JrcyB3aXRoDQo+IHJlbGF0aXZlIHJlZmVyZW5j ZXMgaW4gdGhlIHRhcmdldC4gVGhhdCBzdGF0ZW1lbnQgaXMgcHJvYmFibHkgd2hhdA0KDQpBZ3Jl ZSB0aGF0IHRoZSBNVVNUIHN0YXRlbWVudCB0aGVyZSBpcyBwcm9ibGVtYXRpYyAtIEkgaW5pdGlh bGx5IGludGVycHJldGVkIGl0IGFzICMxIGJlbG93OiANCg0KKiogSW50ZXJwcmV0YXRpb24gIzEN CiJyZXNvdXJjZSBpbmRpY2F0ZWQgYnkgdGhlIHRhcmdldCBVUkkgTVVTVCBiZSBhIFVSSSB0aGF0 IGNhbiBiZSBwb3RlbnRpYWxseSBkZXNjcmliZWQgYXMgYSByZWxhdGl2ZSByZWZlcmVuY2Ugd2l0 aCByZXNwZWN0IHRvIGNvbnRleHQtVVJJIHVzZWQgYXMgYmFzZSBVUkkiDQotPiB0aGVuICdjb2Fw Oi8vc2VydmVyMSBob3N0cyAvdGVzdCcgd291bGQgYmUgdmFsaWQuDQotPiB0aGVuICdjb2FwOi8v c2VydmVyMSBob3N0cyBjb2FwOi8vc2VydmVyMS90ZXN0JyB3b3VsZCBiZSB2YWxpZC4NCi0+IHRo ZW4gJ2NvYXA6Ly9zZXJ2ZXIyIGhvc3RzIGNvYXA6Ly9zZXJ2ZXIxL3Rlc3QnIHdvdWxkIGJlIGlu dmFsaWQuDQoNCioqIEludGVycHJldGF0aW9uICMyDQpCdXQgaXQgY291bGQgYWxzbyBiZSBpbnRl cnByZXRlZCBhcw0KInRhcmdldCBVUkkgTVVTVCBiZSBhIFVSSSBvZiB0aGUgQUJORiBmb3JtICdy ZWxhdGl2ZS1yZWYnICwgYW5kIHRoZSB0YXJnZXQgVVJJIE1VU1QgYmUgYSByZWxhdGl2ZSByZWZl cmVuY2Ugd2l0aCByZXNwZWN0IHRvIGNvbnRleHQtVVJJIHVzZWQgYXMgYmFzZSBVUkkiDQotPiB0 aGVuICdjb2FwOi8vc2VydmVyMSBob3N0cyAvdGVzdCcgd291bGQgYmUgdmFsaWQuDQotPiB0aGVu ICdjb2FwOi8vc2VydmVyMSBob3N0cyBjb2FwOi8vc2VydmVyMS90ZXN0JyB3b3VsZCBiZSBpbnZh bGlkLg0KLT4gdGhlbiAnY29hcDovL3NlcnZlcjIgaG9zdHMgY29hcDovL3NlcnZlcjEvdGVzdCcg d291bGQgYmUgaW52YWxpZC4NCg0KSWYgYSBtYWpvcml0eSBvZiBwZW9wbGUgaW50ZXJwcmV0cyBs aWtlICMxLCB0aGVuIHdlIGRvbid0IGhhdmUgdG8gdXBkYXRlL2NvcnJlY3QgUkZDIDY2OTAgYW5k IHdlIGNhbiBkZWZpbmUgYSBwcm9maWxlIG9mIExpbWl0ZWQgTGluayBGb3JtYXQuIEFuZCBjbGFy aWZ5IGEgYml0IGhvdyB3ZSBzaG91bGQgcmVhZCA2NjkwLg0KSWYgaG93ZXZlciBtb3N0IHBlb3Bs ZSBpbnRlcnByZXQgYXMgIzIsIHRoZW4gY3VycmVudCBSRCB1c2FnZSBvZiByZWw9aG9zdHMgZm9y IGFic29sdXRlIHRhcmdldCBVUkkgaXMgaW5jb3JyZWN0IGFuZCB3ZSB3b3VsZCBuZWVkIHRvIGZv cm1hbGx5IHVwZGF0ZSBSRkMgNjY5MCBJIHRoaW5rIHRvIG1ha2UgdGhhdCBwb3NzaWJsZS4NCg0K PiBmdWVsZWQgbXkgKHByb2JhYmx5IG1pcz8pY29uY2VwdGlvbiBhYm91dCB0aGUgdGFyZ2V0IGJl aW5nIHJlc29sdmVkDQo+IHJlbGF0aXZlIHRvIHRoZSBhbmNob3IsIGFzIG9ubHkgdGhlbiBpdCBt YWtlcyBzZW5zZS4gKFNhbHZhZ2luZyBpdCBieQ0KDQpJIGFzc3VtZSBmb3IgdGhlIG1vbWVudCB0 aGUgaW50ZXJwcmV0YXRpb24gIzEgYXMgYWJvdmUuIFRoZSB0YXJnZXQgbmVlZHMgdG8gYmUgcmVz b2x2ZWQgcmVsYXRpdmUgdG8gdGhlIGNvbnRleHQgVVJJIGFzIHBlciB0aGUgU2VjdGlvbiAyLjIg TVVTVCByZXF1aXJlbWVudC4gVGhlDQpjb250ZXh0IFVSSSBjb3VsZCBiZSBhbiBleHBsaWNpdCBV UkkgZ2l2ZW4gYnkgdGhlICdhbmNob3InIGF0dHJpYnV0ZSBidXQgaXQgbWF5IGFsc28gdXNlIHRo ZSBkZWZhdWx0LCBpZiB0aGF0J3Mgbm90IGdpdmVuLiAgSWYgdGhlIHRhcmdldCBVUkkgaXMgYW4g YWJzb2x1dGUgVVJJDQpmb3JtIHRoZW4gdGhlIGRlZmF1bHQgY29udGV4dCBVUkkgYmVjb21lcyB0 aGUgb3JpZ2luIG9mIHRoYXQgdGFyZ2V0IFVSSS4gU28gdGhlIE1VU1QgcmVsYXRpb24gYWx3YXlz IGhvbGRzIHRydWUgaWYgdGhlIHRhcmdldCBVUkkgaXMgd3JpdHRlbiBpbg0KYW4gYWJzb2x1dGUg VVJJIGZvcm0uICAgU28gaW4gdGhpcyBjYXNlIGl0ICh0byBtZSkgbWFrZXMgc2Vuc2UgdGhhdCBp bmNsdWRpbmcgYW55IGFuY2hvciBwYXJhbWV0ZXIgaXMgbm90IG5lY2Vzc2FyeSBpbiB0aGF0IGNh c2UsIGV2ZW4gc3VwZXJmbHVvdXMuDQoNCkhvdyB0byBwcm9jZWVkIHdpdGggdGhlIGlzc3VlIG9m IHRoZSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zICMxLyMyPw0KDQpCZXN0IHJlZ2FyZHMNCkVz a28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGlhbiBBbXPDvHNz IDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+IA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAy MDIwIDE1OjMyDQpUbzogRXNrbyBEaWprIDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+DQpD YzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBVbm5lY2Vzc2FyeSAiYW5jaG9y IiBhdHRyaWJ1dGVzIGluIGRyYWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMjUgPw0K DQpPbiBXZWQsIE9jdCAyMSwgMjAyMCBhdCAwMToyMTo0MlBNICswMDAwLCBFc2tvIERpamsgd3Jv dGU6DQo+IFRoYXQgc2VlbXMgY2xlYXI7IGZyb20gdGhpcyBhbnN3ZXIgLSBob3cgY291bGQgYW55 b25lIGJlIG1pc3Rha2VuDQo+IGFib3V0IHRoZSBhbmNob3IgaS5lLiB3aGljaCBzZXJ2ZXIgaXMg aG9zdGluZyB0aGUgJy90ZW1wJyByZXNvdXJjZSA/DQo+IFRoZXJlJ3Mgb25seSBvbmUgc2VydmVy IG1lbnRpb25lZCBzbyB0aGF0J3MgdGhlIG9uZSByaWdodCA6KSAgICANCj4NCj4gQW5kIGZvciB0 aGUgcmVsPWhvc3RzIHJlbGF0aW9uIGl0IHdvdWxkIG5vdCBtYWtlIG11Y2ggc2Vuc2UgdG8NCj4g cHJvY2xhaW0gZS5nLiAiY29hcDovL3NlcnZlcjEgIGhvc3RzICBjb2FwOi8vc2VydmVyMi9yZXNv dXJjZSIgIC4uLiANCg0KVGhhdCdzIGludHVpdGl2ZWx5IGNsZWFyIGZvciBjb2FwOi8vc2VydmVy MSBhbmQgY29hcDovL3NlcnZlcjIsIGJ1dCBhDQpzdGF0ZW1lbnQgbGlrZSBjb2FwOi8vc2VydmVy MSBob3N0cyBjb2FwK3NtczovLysxNTU1MTIzNDU2Ny8gbWlnaHQgbWFrZQ0KYSBiaXQgbW9yZSBz ZW5zZSwgYW5kIHRoZSB0YXV0b2xvZ2ljYWwgZGVmaW5pdGlvbiBvZiB0aGUgcmVsYXRpb24NCmRv ZXNuJ3QgaGVscCBtdWNoIHRoZXJlLiBBcyB0aGUgbWVhbmluZyBpcyBzbyB2YWd1ZSwgSSdtIGxv YXRoZSB0byBtYWtlDQpwcmVjaXNlIHJ1bGVzIGRlcGVuZCBvbiBpdC4NCg0KVGhlIGRlc2NyaXB0 aW9uIGluIFJGQzY2OTAgU2VjdGlvbiAyLjIgZG9lc24ndCBoZWxwIGVpdGhlcjsgaXQNCnBvdGVu dGlhbGx5IG1ha2VzIGl0IHdvcnNlIGJ5IGNsYWltaW5nIHRoYXQgaG9zdHMgb25seSB3b3JrcyB3 aXRoDQpyZWxhdGl2ZSByZWZlcmVuY2VzIGluIHRoZSB0YXJnZXQuIFRoYXQgc3RhdGVtZW50IGlz IHByb2JhYmx5IHdoYXQNCmZ1ZWxlZCBteSAocHJvYmFibHkgbWlzPyljb25jZXB0aW9uIGFib3V0 IHRoZSB0YXJnZXQgYmVpbmcgcmVzb2x2ZWQNCnJlbGF0aXZlIHRvIHRoZSBhbmNob3IsIGFzIG9u bHkgdGhlbiBpdCBtYWtlcyBzZW5zZS4gKFNhbHZhZ2luZyBpdCBieQ0Kc2F5aW5nIHRoZXJlIGNh bid0IGJlIGFuIGFuY2hvciB3aXRoIGEgaG9zdHMgcmVsYXRpb24gd291bGQganVzdCBtYWtlIGl0 DQp3b3JzZSBieSBicmVha2luZyBSRCkuDQoNCktSDQpjDQoNCi0tIA0KVG8gdXNlIHJhdyBwb3dl ciBpcyB0byBtYWtlIHlvdXJzZWxmIGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVhdGVyIHBv d2Vycy4NCiAgLS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0K From nobody Mon Oct 26 03:01: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 EF2D83A1A56 for ; Mon, 26 Oct 2020 03:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5LEyPPciokH for ; Mon, 26 Oct 2020 03:01:17 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80097.outbound.protection.outlook.com [40.107.8.97]) (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 742BC3A1A55 for ; Mon, 26 Oct 2020 03:01:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I+rUYAaPE8GZ9TDaaDHpkXiNNaH7SXd3Ka10TE19ipRD6xEQK/jB7fsjwsj6HlKV07HYgRtnjRlBcp3rY5YwJ11VanCU3Ws8NIWO+KZ6XaCywyJFThrFOtO/AYwFnWWMr3UvHJ80yeCoLh8UIXW5yKrX+kHClsvCcKsvjhYJpuHf46Zu0kTpvMSPBiiP1whZOUMxicVC/WesyyVSvU33WrWlcmawcRE8XGGlWaAwy4RGtwJholV4gH9ZtAZA0PTEMxz9IQs2SnUbypnV45p9P0OJS1wi97xnSc6In20mguh5x2uZQxhvFYPA310BsEtV8ggGNRyQVNc3wp8YzENpCQ== 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=SLBeRSJI2ClIqPhMSiP9wGqr9i1uhXuHiY8DTPCW9G0=; b=oEPIIMImbTEA/+r+NiG/SmHy/fK/3exdpO5SFObLVlwqidMvrIoJy8aU52ABkYNzx0u3tLCjP03BsbxIpByIU8eSzLTXK/1I+9L1E2CnqnZYLkafrut7JaZurNrOYk8OOjAlOU2+3OfXSup9VkEtLCHnDtzhsZy7NWKycy6sLrjhYsQ+wV/07or2ZdvCaI3HJ35U0NxjtRiYmU811BEIvfN9GfZDysMLkf0kTHDAu7LmpfnUmRb9cIMC1FQp/0XPpPQOyrO84JH/fVW8B91yM5qQgWz3uC73mfOKpAbxALmvOLiAZFF1ZAaPmirr2bOZ2a6Llz56jdWqsXkOCox5eQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SLBeRSJI2ClIqPhMSiP9wGqr9i1uhXuHiY8DTPCW9G0=; b=Xt1h12ZRQGunP0adnL2BbGjpBU/tbzwS/hzQd5Te1UoCYrhKMTcKuQLciY7hxakHfP/mfhoicmXytkJR+l16NuZaf2D1/adfXvxHZ6h213Ic92rIEqKysfN53tqUFU5PVZabs/F6hxrJu1heU/IYPN/NRjnofL8mJ1QJsDFl0e0= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0020.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:61::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Mon, 26 Oct 2020 10:01:09 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3499.018; Mon, 26 Oct 2020 10:01:09 +0000 From: Esko Dijk To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "core@ietf.org" Thread-Topic: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? Thread-Index: AdagiZ7ddTpjV6VySOOkvoVV5WS9KQGQp6uAAC9rtEAABSmPAAABpo/AAANQggAA8gL0EA== Date: Mon, 26 Oct 2020 10:01:09 +0000 Message-ID: References: <20201020103159.GA311699@hephaistos.amsuess.com> <20201021113736.GC303030@hephaistos.amsuess.com> <20201021135946.GE303030@hephaistos.amsuess.com> In-Reply-To: <20201021135946.GE303030@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:831:730a:9dc6:3ef3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69460107-e37f-4231-a6e1-08d879961039 x-ms-traffictypediagnostic: AM4P190MB0020: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wXlavlzN5l+to39j8jLjJ+ANa30MREDH2nFbeHTMhJueLmiu0+lqHR0QZUFjUZ3UYg/dV5hW5Hi7yIe9WbrzM0weKJZjVzb5bPbthu9NuR4qxnE3f4g5zoATU4Fr7Rbt7NUQsfFK9bLhRL7QtSG0hOgh5BtL1lK90QGMJoi1ETPRcknFFVHuwKXaXLEnM5cNS7cQgkiTloRuvE59E5sFaXDE9gS+ZtySoeogeRHjlpqTQSsbfCYR90xu3L5Oft1lvTXTzDO4aqiv0YmMB+n7Pmqv5ixMS3cadxjwbmyPOv4DpmIR3OIR5bhQVG/j1bcNdUtQg5whlboeOkCadFcfGg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(346002)(396003)(376002)(366004)(39830400003)(44832011)(66574015)(8936002)(53546011)(4326008)(6916009)(7696005)(2906002)(8676002)(9686003)(478600001)(86362001)(6506007)(83380400001)(186003)(64756008)(66476007)(55016002)(71200400001)(33656002)(5660300002)(76116006)(66946007)(66556008)(52536014)(316002)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: WbndlY2MaXMdOJ644SmPNF34qU0Id/jeGewzqGkY4OUCDCdoc3+CDAhrUlZVMIHX6clIewGTuHurCW5BcTItEgQCs/kgbvuepz+QDAvY73/UnpvKezBc6OnIjK4qN4fLPxjLkiqnYQn2PK6cXk84YpO3++4FHhiZjTH38diruiqxoq0INkgS2aRNc1nQUXuHMnaNGIaLDycmcoBwIIY1diuwow1bpwJgBbYevwiHy9bpnEJpfJyPKGm15VAVTFd1ncAxh/kOsrjo4BkGuF13wONKtpuWnjR1gY9ElxXai0c0F5RQ3GYMZS6Pk9+iGcfW+0sYOJOT+ItKFGSDf9+8b4U56lJ6fXr5VYkZe7vDwn0XQ9LE+WAw4Nqfxx+SojmiWXC1Wgq3avbo9DSo5m/7xcTwrwoA2KJ6rtxk4ciQs4rNJvJMTjb88JY5rzH3xFwpAOrXvRvHW6AS+kyAku2NDYfTehm6ETy8mR1z6bz6aBJtX9GZgUgJNUiTSZiwZXv7jOUpPxJ4INMO6h78WtE9GlEJFitDfJuES21HEgbLkGZV4/HIhgxS/quwQFrQtTdmni+ykEePS9YAiddVQ/kpVJxvovmQL9mV6rKt8yRhdE6NMG/DYCFRlKHXzaUau+27/z+eANmX4G3qhUGq7rWOdW345mDQ82GqH6jP5WSEnQlP4zBSvAc1/l+ftSheUJKGdTe9mlvP2Boap0aomfg9/A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 69460107-e37f-4231-a6e1-08d879961039 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2020 10:01:09.6636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q9jJ8rQDL94s8AYU12N6WdD+ifgQEFGcZFmyJS/h7sSqgvIpZGTRoFCKh8Ff2n5TCRrtdld5A6/47SbtqvVo3aSl7vAVWU3bOOJTvJ/AnR4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0020 Archived-At: Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 10:01:20 -0000 PiBJdCB0aGUgYWJvdmUgcmVhZGluZyBpcyBhZ3JlZWQgb24sIHRoZSBydWxlIGNhbiBldmVuIGJl IHNpbXBsZXI6ICJJZg0KPiBhbmNob3Igd2FzIGFic2VudCBvcmlnaW5hbGx5LCBpdCBjYW4gc3Rh eSBhYnNlbnQiLiBUaGF0IHdvdWxkIGNhdGNoIHRoZQ0KPiBzYW1lIGNhc2VzIGFuZCBzb21lIG1v cmUsIG5vdCBkZXBlbmQgb24gdW5kZXJzdGFuZGluZyByZWwsIGFuZCB1cHNldCB0aGUNCj4gc2Ft ZSBzZXQgb2YgaW1wbGVtZW50YXRpb25zICh0aG9zZSBiYXNlZCBvbiB0aGUgMjAxOCB1bmRlcnN0 YW5kaW5nLCBhbmQNCj4gQUZBSUsgdGhhdCBtZWFucyBpdCdzIG9ubHkgbWluZSkuDQoNClRoZSBw cm9wb3NlZCBydWxlIHNvdW5kcyBnb29kLiBJdCdzIGVhc2llciB0byB1bmRlcnN0YW5kIGFuZCBh cHBseSBmb3IgaW1wbGVtZW50ZXJzIHRoYW4gd2hhdCBJIHByb3Bvc2VkLg0KU28gaWYgdGhlIHJl Z2lzdGVyaW5nIGNsaWVudCBzZW5kcyBpdHMgbGlzdCBvZiByZWxhdGl2ZSBsaW5rcyB3aXRob3V0 IGFueSAncmVsJyBhdHRyaWJ1dGUgaW4gdGhlcmUgbm9yICdhbmNob3InLCB0aGUgUkQgc2VydmVz IHRoZW0gYmFjayB0byBsb29rdXAgY2xpZW50cyBhcyBhYnNvbHV0ZSBVUklzIHdpdGhvdXQgYW55 ICdyZWwnIG5vciAnYW5jaG9yJyAtIHVubW9kaWZpZWQgc3RhdGVtZW50cywgZXhjZXB0IGZvciB0 aGUgY2hhbmdlIG9mIHJlbGF0aXZlIFVSSSB0byBhYnNvbHV0ZSBVUkkuDQoNCj4gVGhlIG1haW4g b2ZmZW5kZXIgdGhhdCBuZWNlc3NpdGF0ZWQgdGhlIGZ1bGwtYW5jaG9yLWV2ZXJ5d2hlcmUgd2Fz IG15DQo+IDIwMTggdW5kZXJzdGFuZGluZy4gVGhlIGNoYW5nZSB3b3VsZCBiZSB0byByZWl0ZXJh dGUgaW4gTGltaXRlZCBMaW5rDQo+IEZvcm1hdCB0aGF0IHVubGlrZSBpbiB0aGUgTGluayBoZWFk ZXIsIGFuIGFic2VudCBhbmNob3IgbWVhbnMgdGhlDQo+IGNvbnRleHQgaXMgb3JpZ2luLW9mKHJl c29sdmVkLXRhcmdldCksIGFuZCB0aGVuIG5vIGZ1cnRoZXIgY29uZGl0aW9ucyBvbg0KPiByZWwg bmVlZCBhcHBseS4NCg0KWWVzLCBhZ3JlZS4gIFRoYXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5 L3Byb2ZpbGUuDQoNCj4gU28gcHJvYmFibHkgaXQnZCBiZSBlaXRoZXIgbGVhdmUtaXQtYW5kLXNh eS13aHktaXQncy1saWtlLXRoYXQsIG9yIGdvaW5nDQo+IGV2ZW4gYSBzdGVwIGZ1cnRoZXIgdGhh biB5b3UgYXJlIHN1Z2dlc3RpbmcuDQoNCk9rYXksIEknbSBob3BpbmcgdGhlIG91dGNvbWUgd291 bGQgYmUgdGhlIG9uZSB3aGVyZSB0aGUgJ2FuY2hvcicgYXR0cmlidXRlcyBhcmUgbm90IGFkZGVk IGJ5IHRoZSBSRC4gKFBlciBhYm92ZSB0ZXh0KQ0KDQo+IEkgZGlzYWdyZWUgaGVyZSAtLSBqdXN0 IGJlY2F1c2Ugd2Ugbm9ybWF0aXZlbHkgdXNlIDY2OTAgZG9lc24ndCBtZWFuIHdlDQo+IGNhbid0 IHByb2ZpbGUgaXQgYW5kIHByZXNjcmliZSB0aGF0IGEgcGFydGljdWxhciBzZXJpYWxpemF0aW9u IG5lZWRzIHRvDQo+IGJlIHVzZWQuDQoNCkFncmVlIHRoYXQgd2UgY2FuIG1ha2UgYSBwcm9maWxl IG9mIFJGQyA2NjkwIGFuZCBub3QgdXBkYXRlIGl0ISAgKGFzIGxvbmcgYXMgd2UgZG9uJ3Qgdmlv bGF0ZSBhbnkgZXhpc3RpbmcgNjY5MCBydWxlcykuDQpTb3JyeSBpZiBJIHdhc24ndCBmdWxseSBj bGVhciBoZXJlLiAgSW4gdGhlIGNhc2Ugb2YgdGhlIGN1cnJlbnQgUkQgZHJhZnQgdGV4dCwgdGhl IHByb2ZpbGUgd291bGQgbmVlZCB0byBzYXkgZS5nLiAidGhlIExpbWl0ZWQgTGluayANCkZvcm1h dCBzZXJpYWxpemF0aW9uIGNyZWF0ZWQgYnkgUkQtbG9va3VwIHJlc3BvbnNlIG11c3QgaW5jbHVk ZSB0aGUgJ2FuY2hvcicgYXR0cmlidXRlIGluIGVhY2ggbGluayIuDQpUaGlzIGlzIG5lZWRlZCB0 byBjbGFyaWZ5IHdoeSBhbGwgdGhlIGV4YW1wbGVzIHVzZSB0aGUgJ2FuY2hvcicgd2hpbGUgNjY5 MCBkb2Vzbid0IHJlcXVpcmUgaXQuIEFuZCBhbHNvIHRvIGNsYXJpZnkgdGhhdA0KUkQgaW1wbGVt ZW50YXRpb25zIGNhbm5vdCB1c2UgdGhlIHNob3J0ZXIgdmFyaWFudCB3aXRob3V0ICdhbmNob3In IGV2ZW4gdGhvdWdoIDY2OTAgd291bGQgYWxsb3cgaXQuDQoNCkJlc3QgcmVnYXJkcw0KRXNrbw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hyaXN0aWFuIEFtc8O8c3MgPGNo cmlzdGlhbkBhbXN1ZXNzLmNvbT4gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjEsIDIwMjAg MTY6MDANClRvOiBFc2tvIERpamsgPGVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubD4NCkNjOiBj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFVubmVjZXNzYXJ5ICJhbmNob3IiIGF0 dHJpYnV0ZXMgaW4gZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0yNSA/DQoNCkhl bGxvIEVza28sDQoNCk9uIFdlZCwgT2N0IDIxLCAyMDIwIGF0IDEyOjU5OjU5UE0gKzAwMDAsIEVz a28gRGlqayB3cm90ZToNCj4gSSd2ZSBzd2FwcGVkIHR3byBsaW5lcyBpbiB5b3VyIGl0ZW0gWzJd IHBsdXMgYWRkZWQgc29tZSBjb21tZW50cyBmb3INCj4gY2xhcmlmaWNhdGlvbg0KDQpUaGUgc3dh cHBpbmcgcmVzb2x2ZWQgYSByZWZhY3RvcmluZyBlcnJvciBvZiBtaW5lIC0tIHNvIHdlIGFyZSBh bGlnbmVkDQp0aGVyZS4NCg0KPiBCZWNhdXNlIHRoaXMgbWF5IGJlIG11bHRpLWludGVycHJldGFi bGUsIG15IGlkZWEgZm9yIExpbWl0ZWQgTGluaw0KPiBGb3JtYXQgd2FzIHRvIHNpbXBsaWZ5IHRo ZSBwYXJzaW5nIGJ5IHNwbGl0dGluZyBpbnRvIHR3byBwb3NzaWJsZQ0KPiBjYXNlczogMSkgaW1w bGljaXQgcmVsPWhvc3RzIHdpdGhvdXQgJ2FuY2hvcicgOyBhbmQgMikgYW55IG90aGVyIGxpbmsN Cj4gd2l0aCAnYW5jaG9yJy4NCg0KSXQgdGhlIGFib3ZlIHJlYWRpbmcgaXMgYWdyZWVkIG9uLCB0 aGUgcnVsZSBjYW4gZXZlbiBiZSBzaW1wbGVyOiAiSWYNCmFuY2hvciB3YXMgYWJzZW50IG9yaWdp bmFsbHksIGl0IGNhbiBzdGF5IGFic2VudCIuIFRoYXQgd291bGQgY2F0Y2ggdGhlDQpzYW1lIGNh c2VzIGFuZCBzb21lIG1vcmUsIG5vdCBkZXBlbmQgb24gdW5kZXJzdGFuZGluZyByZWwsIGFuZCB1 cHNldCB0aGUNCnNhbWUgc2V0IG9mIGltcGxlbWVudGF0aW9ucyAodGhvc2UgYmFzZWQgb24gdGhl IDIwMTggdW5kZXJzdGFuZGluZywgYW5kDQpBRkFJSyB0aGF0IG1lYW5zIGl0J3Mgb25seSBtaW5l KS4NCg0KPiAxKiAiYW5jaG9yIiBhdHRyaWJ1dGUgTVVTVCBOT1QgYmUgcHJlc2VudCBmb3IgYW55 IGxpbmsgd2l0aG91dCB0aGUgInJlbCIgYXR0cmlidXRlICAgKHRoaXMgaW1wbGllcyB0aGF0IHRo aXMgbGluayB1c2VzIHRoZSBpbXBsaWNpdCByZWw9aG9zdHMgc2VtYW50aWNzIG9ubHkpDQo+IDIq ICJhbmNob3IiIGF0dHJpYnV0ZSBNVVNUIGJlIHByZXNlbnQgZm9yIGFueSBsaW5rIHdpdGggdGhl ICJyZWwiIGF0dHJpYnV0ZSAgICAgICAgICAgICAgICAgICh0aGlzIGNvdWxkIGJlIGFueSB0eXBl IG9mIGxpbmssIHBvc3NpYmx5IHVzaW5nIHJlbD0ibWFuYWdlZC1ieSBob3N0cyIgb3IgcmVsPSJo b3N0cyIgb3IgcmVsPWhvc3RzICkNCg0KSWYgd2UgZ28gdGhhdCByb3V0ZSAoYW5kIGF0IGxlYXN0 IGEgYnJpZWYgY2hhaXIgY2hhdCBlYXJsaWVyIHRvZGF5DQpzb3VuZGVkIGEgYml0IHJlbHVjdGFu dCksIEknZCByZXZpc2l0IHRoZSBrbm93biBpbXBsZW1lbnRhdGlvbnMuIE15DQpleHBlY3RhdGlv biBpcyB0aGF0IHRoZXNlIHJlc3RyaWN0aW9ucyB3b24ndCBldmVuIGJlIG5lY2Vzc2FyeS4NCg0K VGhlIG1haW4gb2ZmZW5kZXIgdGhhdCBuZWNlc3NpdGF0ZWQgdGhlIGZ1bGwtYW5jaG9yLWV2ZXJ5 d2hlcmUgd2FzIG15DQoyMDE4IHVuZGVyc3RhbmRpbmcuIFRoZSBjaGFuZ2Ugd291bGQgYmUgdG8g cmVpdGVyYXRlIGluIExpbWl0ZWQgTGluaw0KRm9ybWF0IHRoYXQgdW5saWtlIGluIHRoZSBMaW5r IGhlYWRlciwgYW4gYWJzZW50IGFuY2hvciBtZWFucyB0aGUNCmNvbnRleHQgaXMgb3JpZ2luLW9m KHJlc29sdmVkLXRhcmdldCksIGFuZCB0aGVuIG5vIGZ1cnRoZXIgY29uZGl0aW9ucyBvbg0KcmVs IG5lZWQgYXBwbHkuDQoNClNvIHByb2JhYmx5IGl0J2QgYmUgZWl0aGVyIGxlYXZlLWl0LWFuZC1z YXktd2h5LWl0J3MtbGlrZS10aGF0LCBvciBnb2luZw0KZXZlbiBhIHN0ZXAgZnVydGhlciB0aGFu IHlvdSBhcmUgc3VnZ2VzdGluZy4NCg0KPiBUaGVyZSBpcyBvbmUgbW9yZSBjb25zaWRlcmF0aW9u IGZvciB0aGUgY3VycmVudCBSRCBkcmFmdCAtIGluIGNhc2Ugd2UNCj4gZGVjaWRlIHRvIGtlZXAg dGhlIGV4cGxpY2l0ICJhbmNob3IiIGF0dHJpYnV0ZSBpbiBhbGwgdGhlIGV4YW1wbGVzLg0KPiBC ZWNhdXNlIFJGQyA2NjkwIGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgdGhlIGFzc3VtcHRpb24g b2YgdGhlDQo+IHJlYWRlciBjdXJyZW50bHkgc2hvdWxkIHN0aWxsIGJlIHRoYXQgdGhlICJhbmNo b3IiIGF0dHJpYnV0ZSB0aGF0J3MNCj4gYWRkZWQgaW4gYWxsIHRoZSBleGFtcGxlIGlzIGp1c3Qg c3VwZXJmbHVvdXMgaS5lLg0KPg0KPiAqIGFuIFJEIGltcGxlbWVudGF0aW9uIG1heSBlbGlkZSBp dCAsIGZvbGxvd2luZyBSRkMgNjY5MCBydWxlcyAgKGluDQo+ICAgdGhlIGludGVycHJldGF0aW9u IGFzIGNvZGVkIGF0IHRoZSB0b3Agb2YgdGhpcyBlbWFpbC4pIGFuZCBTZWN0aW9uDQo+ICAgMi4z IG9mIDY2OTANCg0KSSBkaXNhZ3JlZSBoZXJlIC0tIGp1c3QgYmVjYXVzZSB3ZSBub3JtYXRpdmVs eSB1c2UgNjY5MCBkb2Vzbid0IG1lYW4gd2UNCmNhbid0IHByb2ZpbGUgaXQgYW5kIHByZXNjcmli ZSB0aGF0IGEgcGFydGljdWxhciBzZXJpYWxpemF0aW9uIG5lZWRzIHRvDQpiZSB1c2VkLg0KDQo+ ICogYW4gUkQgY2xpZW50IGRvaW5nIGxvb2t1cHMgbWF5IGlnbm9yZSBpdCwgZm9sbG93aW5nIFJG QyA2NjkwIHJ1bGVzDQo+IGluIFNlY3Rpb24gMi4zDQoNCi4uLiBhbmQgaGVyZTogNjY5MCBzYXlz IHRoYXQgIkEgY29uc3VtaW5nIGltcGxlbWVudGF0aW9uIGNhbiwgaG93ZXZlciwNCmNob29zZSB0 byBpZ25vcmUgc3VjaCBsaW5rcy4iIChhbmQgbm90IHN1Y2ggYXR0cmlidXRlcykuIFRoZSBjbGll bnQgd291ZA0KanVzdCBpZ25vcmUgYWxsIHJlc291cmNlIGxvb2t1cCByZXN1bHRzLCBhbmQgdGhl IGltcGxlbWVudGVyIHdvdWxkIHRodXMNCm5lZWQgdG8gaW1wbGVtZW50IChhdCBsZWFzdCBydWRp bWVudGFyeSkgc3VwcG9ydCBmb3IgdGhlIGFuY2hvcg0KYXR0cmlidXRlLg0KDQpLUiwgYW5kIHRo YW5rcyBmb3IgYWxsIHlvdXIgaW5wdXQNCkNocmlzdGlhbg0KDQotLSANClRvIHVzZSByYXcgcG93 ZXIgaXMgdG8gbWFrZSB5b3Vyc2VsZiBpbmZpbml0ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlciBw b3dlcnMuDQogIC0tIEJlbmUgR2Vzc2VyaXQgYXhpb20NCg== From nobody Mon Oct 26 07:42:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2C3A0BE6 for ; Mon, 26 Oct 2020 07:42: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 BjYLWRFkzDBQ for ; Mon, 26 Oct 2020 07:42:45 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C7A3A0BE3 for ; Mon, 26 Oct 2020 07:42:43 -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 1kX3hn-0002qg-So; Mon, 26 Oct 2020 14:42:39 +0000 From: "Jon Shallow" To: "'Michael Richardson'" , References: <118201d6a958$5ac8bed0$105a3c70$@jpshallow.com> <4020.1603471352@localhost> <119e01d6a95e$5f8acc00$1ea06400$@jpshallow.com> <14157.1603572407@localhost> In-Reply-To: <14157.1603572407@localhost> Date: Mon, 26 Oct 2020 14:42:26 -0000 Message-ID: <001c01d6aba6$38ff3ae0$aafdb0a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWlqb2iKC3R3viCvjymGPo29qZmgHUEiDOAbf7AU8C2VqRFaj26jyA Content-Language: en-gb Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Congestion Control 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, 26 Oct 2020 14:42:47 -0000 Hi Michael, It is good to have these thought provoking questions. See inline. Regards Jon > -----Original Message----- > From: Michael Richardson [mailto:ietf-supjps-mcr+ietf@sandelman.ca] > Sent: 24 October 2020 21:47 > To: Jon Shallow > Cc: core@ietf.org > Subject: Re: [core] draft-ietf-core-new-block: Congestion Control >=20 >=20 > Jon Shallow wrote: > > The original concept of Quick-Block2 was to get all of the data = over in > > an efficient manner (subject to congestion control) and reduce = the > > number of requests needed as a part of that process. An Observe > > trigger just needed to send over all of the data within the = body. >=20 > > "Selective" access to resource data was not required but is = provided by > > Block2 (but missing blocks can be re-requested using = Quick-Block2). > > When asked yesterday, I knew that there were likely to be issues = in > > this area and my answer was not well thought through - hence = what you > > picked up. >=20 > I'm asking if a return reachability check is needed before the = multiple > packet reply. There is none at present. This is only an issue if using NoSec security = mode as any other mode implies reachability is there. >=20 > That is, is there an amplication attack possible here is one can forge = the > source address. Yes. This is covered in part by = https://tools.ietf.org/html/rfc7252#section-11.3 . If a security mode = other than NoSec, then this should not be an issue as it becomes very = difficult to spoof a source address. In the case of the DOTS protocol which triggered this draft,, Security = is a requirement https://tools.ietf.org/html/rfc8782#section-10 . That = said, it is worth adding something to = https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-01#sectio= n-11 to recommend a security mode other than NoSec as picked up from = https://tools.ietf.org/html/rfc7252#section-11.4 . >=20 > It might be that nobody will never use *-Block[12] (I also like = Robust) > without an OSCORE context, in which case there is probably enough = security > to prevent abuse by forged source address. Agreed. >=20 > > It is possible to ask for a specific offset and the blocks = following as > > the Quick-Block2 option can be used multiple times in a single = GET > > request - they would be the base offset (as indicated by = block.num and > > block.szx) and the remaining options used for block.num+1, > block.num+2 > > etc. If more than MAX_PAYLOAD options were defined, the first > > MAX_PAYLOAD would come back, then an ACK_TIMEOUT pause and then > the > > next blocks etc. >=20 > So, given a Christmas-Tree-Packet (largest packet, every possible = option > space used, every extension turned on...) how much data can I get = back? :-) If the server is unable to use the smallest block size (16) (lack of PDU = space) and there is 16 or more bytes, then no data will get transferred = back. This issue is the same as for the regular Block2.=20 I believe that this should generate a 4.13 (Request Entity Too Large), = but am open to other suggestions. >=20 > If it is legit to include multiple copies of the options, can I ask = for the same > offset to be sent to me multiple times? Good catch. No as there is no point in supporting this. The text will = get updated to indicate this is invalid and will get rejected. =20 >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 From nobody Mon Oct 26 09:22: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 5C7E53A0CE5 for ; Mon, 26 Oct 2020 09:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hRljrIQratP for ; Mon, 26 Oct 2020 09:22:00 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70137.outbound.protection.outlook.com [40.107.7.137]) (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 633FC3A0CE1 for ; Mon, 26 Oct 2020 09:21:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NcK91hYOfrKifAd/r7xTOJr71DkBn0R58msO/CaGFU5UkUI835kAlSQ6pbn6qzz7h5c8P/9vKnSjXxUFAIXG7/V7U1D8FCok540cp4M8VZpqJSIOcRSWTZwj/Xc3PFCP/wW5c/jMqPuB/8+rnry3I0CfwpSSIyTQt9bip8o6/q6bojnUveZtMItFwBRePQEdwVypP8ggiE1LduZf/LaShYbK6jk6RrcB9wg5jnCk84+0N92yJRobxcAuC/amawtqTYn2/ce5zSa34SIod5Eruz6HtDJA5gl3K5RwLjjPRB0HXVzEpQW31uTWzu1oTJWCHNqiz3bDkYOfbPC9KkbRYg== 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=NcXpZIqILkGWtGmViSmtSObSKufpouKhDUAnsOBB/FU=; b=dpzFU4hmMq91pANM+31Bm8Ez+qJ1P1EOnle7Z63W77rTEi9AY0WwvVDlWrukV71Zt7iyyejHMhmQ/yoNnZWcwdYTIoG6B6FJfOwQCnNhtEj+m2wnKjUc97jgF/Re9d8eX6+UAeir1ghSqQNOJG+2/XIbHm8UUitPU8pk3cdk8ky9uhaWRBRc0xxkRloGOp0VjdKKSzs+1APPiTshonnmq9vG3eIyEcJIzswYSry/He0n0jUAc8Q8QHUcM4Uh6ZYD0aPQpcFmybq1clWptbUOMIq7+FXZ2+nviB8RywgcDr7tynISre1VCXqWEZDTD/Bbxg+ELtunJXuWN7xb6+Veaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NcXpZIqILkGWtGmViSmtSObSKufpouKhDUAnsOBB/FU=; b=F38nUmdaF8v++fqYVCb69jMnQzNeD8wKx9I/NH3sEsTMjyG74vSi2USrwyZSFpK92Ld81SQoz3eMZB9ryvG3JjelLau1uuepgn9Yrs4rmG8f8b0oEra2WJWsn/tnGBZ/GgUHLMdWudF0HxEHROkWFOqRCH2CZ69FXKF0svXuY0o= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM8P190MB0916.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1da::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19; Mon, 26 Oct 2020 16:21:56 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3499.018; Mon, 26 Oct 2020 16:21:56 +0000 From: Esko Dijk To: Michael Richardson , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Core WG mailing list Thread-Topic: [core] (not only) RD: Authorized servers Thread-Index: AQHWpz2tZ9UsC287L0y3UyBO7I+WM6mkNQOAgAXircA= Date: Mon, 26 Oct 2020 16:21:56 +0000 Message-ID: References: <20201021000327.GB303030@hephaistos.amsuess.com> <25374.1603405315@localhost> In-Reply-To: <25374.1603405315@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:831:730a:9dc6:3ef3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fd3d9770-7367-4ebe-886e-08d879cb41f9 x-ms-traffictypediagnostic: AM8P190MB0916: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YNiG+qFU3ezWS9V1ZHP/X6hsgD0MR8BG83djYnD/P85eQgrJCWc8mQ7GD1378cWXG4ulUHdBZzOuQRXD3HUG61ED25r0v3SHR2Xz5BMCUkr2vjOIwFWs3B0y+h9tj7l4yg2zIYss91dJvJ2cmqy7lPRe1KWU/TKeL67huXRC099vs73kvRTqBV79j5XCFJZLoX544aHlanRqibFhVpQOmfSfryMOmnslxiNvxqljOCxZTYQ7XI9g5jeL1XzPWi2WNJzWWPr2bPWYpJeHGOCNAtvAdAJ4wSqqgTBhm18aZ+6juugfxsfp6LYkz4zTJNesqIFzeJbjv4G/om5AseKXCE19NMqoGo2ToqZUUWvfS8FrnXO6HAjYSyjzm6xXR/uyRF83ABs3dp8+kr4IwWRWnA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(376002)(346002)(136003)(39830400003)(366004)(966005)(2906002)(33656002)(478600001)(7696005)(55016002)(86362001)(66476007)(66556008)(76116006)(83380400001)(66574015)(64756008)(66946007)(52536014)(71200400001)(5660300002)(110136005)(316002)(66446008)(9686003)(8936002)(186003)(44832011)(6506007)(53546011)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: iEIMZqujiNSDxZvboAfdI7LDtJ1NHCamIakJDX1UjuyfNtv9pX7YknhQ6qtYUnJPnJmm8FKbGvylDRSBibemEdqgIOk9sCxIL7tUitfA7pv2xy7MxUZZPyKmNWQDDZi3SLXZeFRuJFDsb0pqJFwfqlhSl1s+PvZwx83f/Ki98pP+op59BGTcZpco+vBjB9IQ7XrRzbHJlyRTB7MYeddwCi3lTuJV1zKzRTRw3eQ9eUDWutCrgCX4truGZGSJGuaa6a4rhOHCFTiJ8uAa08RdQkwFmr9jYBnWqm+pbhkpsuVq8+0anCRI2PCk/5kGEYeM5fpSNyi5jUxSLJpIoAVBQqZxOmGiyMM/j4XhULUkJUSASDRpqa2VHyoYnba7/mEK4xY8hs8ecXGmIv5mmQYno6plaZ6IXgMI7850YnfFShUDeLa+ccwg7HeXMs3Nv1XN/nvEtqJjyyRmsGJ5Z6po8MXheLs8uBcSkzhbWKe8js1PM9VzIeVsZw42TUQqk6f6fBwK1KTHCV7lGWygXeoepAJq7GzYYcJHsKk4ZcQGDBtLq/PKcSj5385+cNxKoZkhAHIQFfFHTzXG3up/H/KwAY/Lauz2mvh26HAD2ys2vsF9AnN2gWaoCQdemjtLp6Lghlibj7hpTMlL/D116EhPSBJJjj7l1mlkqrNvw2KPLygukahmdSX86bSxcv/wHDgbGjvg/U012r0JM++N7lhimg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fd3d9770-7367-4ebe-886e-08d879cb41f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2020 16:21:56.4044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UmffNDBwWFe6H/bEcSXcECTYJ64AxjkP8y0KKgnHm7n5aJDlZW7MfO563OMCU5KY2T/OFC/YU/GeXMyNzGzpkYomMkZ419sTWIgz0QM4MR4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0916 Archived-At: Subject: Re: [core] (not only) RD: Authorized servers 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, 26 Oct 2020 16:22:03 -0000 InByaW5jaXBhbCBYIiBtYXliZSBkb2VzIG5vdCBuZWVkIHRvIGJlIGV4cGxpY2l0bHkgbmFtZWQu IE9yIG1heWJlIGl0IGNvdWxkIG5hbWUgaXRzZWxmIGFzIGN1cnJlbnRseSBkb25lIHVzaW5nIHRo ZSAnZXAnIGVuZHBvaW50IG5hbWUuDQpGb3IgcmVmZXJlbmNlIGhvdyBzdWNoIHNlY3VyaXR5IGNv dWxkIGJlIGFjY29tcGxpc2hlZCwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRuc3NkLXNycC0wNA0KDQpUaGlzIGlzIHRoZSBETlMtU0QgZXF1aXZhbGVudCBvZiBD b1JFIFJEIGFuZCBpdCB1c2VzIGEgcHVibGljL3ByaXZhdGUga2V5IHNpZ25pbmcgc29sdXRpb24g dG8gcHJldmVudCBvdGhlciBkZXZpY2VzIG1vZGlmeWluZyBhIGRldmljZSdzIGVudHJpZXMuIFRo ZSByZWdpc3RyYXRpb24gaXMgb24gYSBmaXJzdC1jb21lLWZpcnN0LXNlcnZlZCBuYW1pbmcgcHJp bmNpcGxlLg0KTm90IHN1cmUgaWYgdGhpcyB3b3VsZCBmaXQgd2l0aCBDb1JFLVJELCB3aGljaCBt YXkgbmVlZCB0byBkZWFsIHdpdGggbXVsdGlwbGUgQ29SRSBzZWN1cml0eSBzb2x1dGlvbnMgb3V0 IHRoZXJlLCBidXQgYXQgbGVhc3QgdGhlIGFkdmFudGFnZSBvZiB3aGF0IEROUy1TRCBTUlAgcHJv cG9zZXMgaXMgYSBzaW5nbGUgc2VjdXJpdHkgbWV0aG9kIHRoYXQgYWxsIGRldmljZXMgY2FuIHVz ZSwgc28gaW50ZXJvcGVyYWJpbGl0eSBiZWNvbWVzIGZhciBlYXNpZXIgdG8gYWNoaWV2ZS4NCg0K RXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSA8Y29yZS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiBGcmlk YXksIE9jdG9iZXIgMjMsIDIwMjAgMDA6MjINClRvOiBDaHJpc3RpYW4gPT9pc28tODg1OS0xP0I/ VFM0Z1FXMXovSE56Pz0gPGNocmlzdGlhbkBhbXN1ZXNzLmNvbT47IENvcmUgV0cgbWFpbGluZyBs aXN0IDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSAobm90IG9ubHkpIFJEOiBB dXRob3JpemVkIHNlcnZlcnMNCg0KDQpIaSwgSSdtIG5vdCB2ZXJ5IHdlbGwgaW5mb3JtZWQgYWJv dXQgdGhlIFJEIGRvY3VtZW50Lg0KSSBoYXZlIHNraW1tZWQgdGhlIGRvY3VtZW50IGF0IHZhcmlv dXMgaW50ZXJ2YWxzLg0KQW5kIHRoZXNlIGNvbW1lbnRzIGFyZSByYXRoZXIgbGF0ZSwgSSBhZ3Jl ZS4NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBhIGZ1bmRhbWVudGFsIHByb2JsZW0gd2l0aCB0aGUg d2hvbGUgUkQgY29uY2VwdCBpcyB0aGF0DQppdCBtdXN0IG1ha2UgdGhlIHNlY3VyZSBpZGVudGl0 aWVzIHBhcnQgb2YgdGhlIHJlc3VsdC4NCg0KSXQncyBub3QgcmVhbGx5IGludGVyZXN0ZWQgdG8g c2F5IHRoYXQgMjAwMTpkYjg6Mzo6MTI3IGhhcyBhIG9pYy5kLnNlbnNvci4NCldoYXQncyBpbnRl cmVzdGluZyBpcyB0byBzYXkgdGhhdCBwcmluY2lwYWwgWCwgKHdobyB3YXMgc2VlbiBhdCBhZGRy ZXNzIDIwMDE6ZGI4OjM6OjEyNyksDQpoYXMgYW4gb2ljLmQuc2Vuc29yLg0KDQpTZWN0aW9uIDcu MSBoYXMgcGxhY2VkIHRoZSBSRCBpbiB0aGUgcGxhY2Ugb2YgdHJ5aW5nIHRvIGJlIGEgZ2F0ZSBr ZWVwZXIgZm9yDQphY2N1cmF0ZSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMganVzdCBjYW4ndCBkbyBp biBhIGdlbmVyYWwgd2F5IGZvciBhcmJpdHJhcnkNCmNsaWVudHMgd2l0aCBhYml0cmFyeSBwb2xp Y2llcy4NCg0KSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIG11Y2ggc2ltcGxlciBhbmQgbW9yZSBz ZWN1cmUgaWYgd2UgcmVzdGFydGVkIGFuZCBkaWQNCnRoZSBzZWN1cml0eSBmaXJzdCByYXRoZXIg dGhhbiBsYXN0LiAgVGhhdCBkb2VzIG1lYW4gdGhhdCBvbmUgaGFzIHRvIHBpY2sgb25lDQoob3Ig YSB2ZXJ5IHNtYWxsIG51bWJlcikgb2Ygc2VjdXJpdHkgc3lzdGVtcyB0byB3b3JrIHdpdGguICBU aGlzIGlzIG5vdCBhDQpwbGFjZSB3ZXJlIHdlIGNhbiBvciBzaG91bGQgYXR0ZW1wdCB0byBnZW5l cmFsaXplLg0KDQpJJ20gc29ycnkgaWYgdGhpcyBpcyBhIHJhdGhlciBkZXByZXNzaW5nIHN1Z2dl c3Rpb24uDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4g ICAuIG8gTyAoIElQdjYgScO4VCBjb25zdWx0aW5nICkNCiAgICAgICAgICAgU2FuZGVsbWFuIFNv ZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCg0KDQoNCg0K From nobody Mon Oct 26 10:56:15 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 D03053A0E05 for ; Mon, 26 Oct 2020 10:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q8bTxoDCpHS for ; Mon, 26 Oct 2020 10:56:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57783A100E for ; Mon, 26 Oct 2020 10:55:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B74A53899E for ; Mon, 26 Oct 2020 14:02:18 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QRC8Bqpv19bO for ; Mon, 26 Oct 2020 14:02:18 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51B603899D for ; Mon, 26 Oct 2020 14:02:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 193C8493 for ; Mon, 26 Oct 2020 13:55:43 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] stateless --- advice on replay windows 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, 26 Oct 2020 17:56:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In pull request: https://github.com/core-wg/stateless/pull/11/files#diff-cf7b3529858e66fc= ec2a75824b625d78d48be9aec680e404c6ed6aa3e4bfce0fR909 At line 901: https://github.com/core-wg/stateless/pull/11/files#diff-cf7b3529858e66fc= ec2a75824b625d78d48be9aec680e404c6ed6aa3e4bfce0fR909 I suggest: This size of the replay window depends upon the number of outstanding requests that need to be outstanding. This can be determined from the rate at which new ones are made, and the expected duration in which responses are expected. For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate = of 10 requests/second, any request that is not answered within 2s wi= ll be considered to have failed. Thus at most 20 request can be outstanding at a time, and any convenient replay window larger th= an 20 will work. As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient. I am looking for some review of this text as to sanity. Is it good advice? are my assumption reasonable? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+XDZ4ACgkQgItw+93Q 3WXV1ggAnyEnhI4XZ4CfoTA20piFui1LyzdAEtVMhgjbxuT/3l9gGUydxk+acgWc Wkdk6Pxk7YZ359wwcKDP7rlnLMYVEw6cf44ou3a9zDNO+Ht62L4wLISwnW5R9f1O nNDh0QWC5MXtpsiPBQ4ZZQcoumqE+nPy5eo31NnsrfN0BWH8ADK1bsyz4l3jxYet ftiacw75lRxfYwRJUtFR5Kr5+t3Sk4x0sTjGl8XJwuJptI/ocJDf/VFg8sevISYT EaYxjH2Dp4uGcXmfEJVKq8htNGNAvlfLxx35jygG3zZu4QL9DiT58K1669lMmHvI GnB3rNH4jPHUk2AXX5suIN525Wx3sw== =qlZJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 29 01:38:23 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 0C9B03A0BF3; Thu, 29 Oct 2020 01:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H3=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 qWXK7hlEO6Ek; Thu, 29 Oct 2020 01:38:19 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1AE3A0BF2; Thu, 29 Oct 2020 01:38:19 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4CMJk16mCrzBrx4; Thu, 29 Oct 2020 09:38:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603960697; bh=32wuY9ORnLlB90huSEOPUYReFW7H7W4+OMH5ZVqdXhM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=EJB2Sl8R9NsEf7pveUrD0wyyS4zDE3WsjY9dfCKBJ469UOdpzgLhrHFUFCIall0LV 3uZEWWLGsA3t6xLvHolkCh3rV0FE6GJl25rdEX+9JycCHoUQyJGDp82dstIzNdRRJN i+8KjS6TE5STxsN9uByQVQEE2hotfX2Twy0INN+6ZjsXxhrjf05WtGZuE/NnDN5SL2 bF5qRnzO9sZm51ne9qVmYK8FpK1tlIi5pqlw4IjNacj6EJxrpw+mbbHGZfFLnATWj5 90M20/44dORbeJx1Ja565SsScQFkNyB9izUV7UuMDjEG4foLaH6h8iRmS/XUtLbloz WxrOQSIw6uykg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4CMJk15d75zCqjy; Thu, 29 Oct 2020 09:38:17 +0100 (CET) From: To: "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" Thread-Topic: draft-ietf-core-new-block: Find a better name for the options Thread-Index: AdapCRjyPLyqWm4UTi2bgt6a6EIumwExPfGw Date: Thu, 29 Oct 2020 08:38:16 +0000 Message-ID: <22718_1603960697_5F9A7F79_22718_215_1_787AE7BB302AE849A7480A190F8B933031568EFF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031568EFFOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Find a better name for the options 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, 29 Oct 2020 08:38:21 -0000 --_000_787AE7BB302AE849A7480A190F8B933031568EFFOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Thanks for those of you who replied to the poll. So far, we have 4 proposals with the same preference. We will proceed with = Q-Block (less changes to the figures :-)) in the next iteration, but we are= open to change if we got more inputs. All other proposals are added as keywords in the xml version. Cheers, Jon & Med De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Envoy=E9 : vendredi 23 octobre 2020 09:05 =C0 : core@ietf.org Cc : draft-ietf-core-new-block@ietf.org Objet : draft-ietf-core-new-block: Find a better name for the options Hi all, As a follow-up to the interim meeting, we listed some proposals in https://= doodle.com/poll/2uv4vfez9sq77fa9. Please indicate your preferred one by the= end of next week so that this change can be included in -02. Please note that: =B7 Q: Quick =B7 LL: L(arge amounts of data with)L(ess packet interchanges) =B7 FLLF: F(aster transmission rates for)L(arge amounts of data wit= h)L(ess packet interchanges as well as)F(aster recovery) If we don't have sufficient input or none of the proposals are acceptable, = we will maintain the current names. Thank you. Cheers, Jon & Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_787AE7BB302AE849A7480A190F8B933031568EFFOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Thanks for those of you who replied to the poll.

 

So far, we have 4 proposals with the same prefer= ence. We will proceed with Q-Block (less changes to the figures :-)) in the= next iteration, but we are open to change if we got more inputs.

 

All other proposals are added as keywords in the= xml version.

 

Cheers,

Jon & Med

 

De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Envoy=E9 : vendredi 23 octobre 2020 09:05
=C0 : core@ietf.org
Cc : draft-ietf-core-new-block@ietf.org
Objet : draft-ietf-core-new-block: Find a better name for the o= ptions

 

= Hi all,

=  

As a follow-up to the interim meeting, we listed some propos= als in https://doodle.com/pol= l/2uv4vfez9sq77fa9. Please indicate your preferred one by the end of ne= xt week so that this change can be included in -02.

 

Please note that:

=B7         Q: Quick

=B7  &n= bsp;      LL: L(arge amounts of data with)L(ess p= acket interchanges)

=B7         FLLF: F(aster transmission rates for)L(ar= ge amounts of data with)L(ess packet interchanges as well as)F(aster recove= ry) 

If we don’t have sufficient input or none of the propo= sals are acceptable, we will maintain the current names.

 

Thank you.

 

Cheers,

Jon & Med

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_787AE7BB302AE849A7480A190F8B933031568EFFOPEXCAUBMA2corp_-- From nobody Thu Oct 29 02:01:26 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0623A097F; Thu, 29 Oct 2020 02:01:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160396208446.12555.831863472742513@ietfa.amsl.com> Date: Thu, 29 Oct 2020 02:01:24 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-02.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: Thu, 29 Oct 2020 09:01:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-02.txt Pages : 25 Date : 2020-10-29 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 29 02: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 BEFFA3A0BAD; Thu, 29 Oct 2020 02:19:18 -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 GKLRqxrLPEBd; Thu, 29 Oct 2020 02:19:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC483A07A0; Thu, 29 Oct 2020 02:19:16 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4CMKdH52wcz8t7w; Thu, 29 Oct 2020 10:19:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603963155; bh=LxRIeh7c6jJhDJaoicXzmuGS78Cd3SQI6G2XEoNqvfM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=twOzH0iY8CIFZorXQcsX47T8mv/VFDXhtfrvOjL2JoxdhL59uVp8nyCH1D9tKgqKl 0h+TzMTK2fGEDv8pJJMEXV5mXintf0NFjZ7kGWSoosV5cwVcODVDwF33trStcbW4F1 zkbqXd66VsLV/ee2QJsxMqKBBq753MjjbiOsVwEIzd1BKTBJ7cYkGNn6dDBboOG0oQ VCRD83e3X/Hg30NUtMu/qwyBf2Uj8cylx3LQ2Do5VqRgT7LycUIPzWusmcIjLwJDn6 PFOMg0wp/RCe3s97U+yqwY75BHOvX9fiGpGM9lQ5FEx8LX4D05exYUoVp+xjDfcnK+ mcQyuY2df/kew== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4CMKdH47HKz5vN9; Thu, 29 Oct 2020 10:19:15 +0100 (CET) From: To: "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-new-block-02.txt Thread-Index: AQHWrdIa8yVLED9E30qpUa9+hbqji6muSJ2g Date: Thu, 29 Oct 2020 09:19:14 +0000 Message-ID: <8668_1603963155_5F9A8913_8668_225_1_787AE7BB302AE849A7480A190F8B933031568F6C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160396208446.12555.831863472742513@ietfa.amsl.com> In-Reply-To: <160396208446.12555.831863472742513@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.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-02.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, 29 Oct 2020 09:19:19 -0000 Hi all,=20 We published the -02 as per the plan presented in the interim. The main cha= nges are to reflect the outcomes of the interim: (1) Add a statement that either both or neither options can be supported. (2) Add an implementation note about how tokens are handled.=20 (3) Change the name of the options. (4) Add a clarification about the behaviour when multiple instances of Q-Bl= ock2 are included.=20 (5) Remove the "MUST NOT" restriction on 2.31 (Continue) as a provision to = (9).=20 (6) Clarify what is meant by "repeat request". Marco, please check if the N= EW wording is better.=20=20 (7) Overflow discussion. Michael, please check and let us know if we need t= o say more.=20 (8) Update the CDDL and add an implementation note to suggest the use of in= definite-length arrays. (9) Add a note about the ACK_TIMEOUT delay after MAX_PAYLOADS.=20 We are waiting for the feedback from the WG whether (9) is worth to be solv= ed at the CoAP level. This is the main pending issue that we would like to = fix before asking for the WGLC (https://mailarchive.ietf.org/arch/msg/core/= uoXMI8vcsGoto6fa1GpgftXS-cU/).=20 Please review and share your comments. Cheers, Jon & Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 29 octobre 2020 10:01 > =C0=A0: i-d-announce@ietf.org > Cc=A0: core@ietf.org > Objet=A0: [core] I-D Action: draft-ietf-core-new-block-02.txt >=20 >=20 > 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. >=20 > Title : Constrained Application Protocol (CoAP) > Block-Wise Transfer Options for Faster Transmission > Authors : Mohamed Boucadair > Jon Shallow > Filename : draft-ietf-core-new-block-02.txt > Pages : 25 > Date : 2020-10-29 >=20 > Abstract: > This document specifies alternative Constrained Application > Protocol > (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 > Options. >=20 > These options are similar to the CoAP Block1 and Block2 Options, > not > a replacement for them, but do enable faster transmission rates > for > large amounts of data with less packet interchanges as well as > supporting faster recovery should any of the blocks get lost in > transmission. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-new-block-02 > https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-new-block-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 29 04:46: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 1FE563A0B9F; Thu, 29 Oct 2020 04:46:15 -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 wY5sA9Kuf1Rg; Thu, 29 Oct 2020 04:46:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BA33A0B92; Thu, 29 Oct 2020 04:46:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D34E7389E3; Thu, 29 Oct 2020 07:52:56 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S2zF1WDb16W1; Thu, 29 Oct 2020 07:52:56 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80CD5389E1; Thu, 29 Oct 2020 07:52:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E8853439; Thu, 29 Oct 2020 07:46:10 -0400 (EDT) From: Michael Richardson To: mohamed.boucadair@orange.com cc: "core\@ietf.org" , "draft-ietf-core-new-block\@ietf.org" In-Reply-To: <22718_1603960697_5F9A7F79_22718_215_1_787AE7BB302AE849A7480A190F8B933031568EFF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <22718_1603960697_5F9A7F79_22718_215_1_787AE7BB302AE849A7480A190F8B933031568EFF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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] draft-ietf-core-new-block: Find a better name for the options 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, 29 Oct 2020 11:46:15 -0000 --=-=-= Content-Type: text/plain wrote: > Thanks for those of you who replied to the poll. > So far, we have 4 proposals with the same preference. We will proceed > with Q-Block (less changes to the figures :-)) in the next iteration, > but we are open to change if we got more inputs. Tough-Block is better, I think. If you like, "T-Block" -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+aq4IACgkQgItw+93Q 3WUoJwf7BqPLFvffZkAM5rARPtrMZn31OX8AdhPZwhiX9p6Hi5x0767wQ4S3R2cc SzQF9dUNwGmcIAbCLs036CC9/0WqgJrTgBNWcYFvpQxDv09pJdA4ODPiZ+7FJLIl M9F8qVydrn+Tr5cIGLIKHBVD/uRszWzqDoZNusX/WFCLUmiFe75w5SlfSzxTCUyx h4Nf4x95cmgSyhjjL2eS2p6nwCYuInql/cPCVwKKmmo7wU/oAMo4ZhrSj0GDe8Jb syuqTzd+Z4dt8Xp1g/+p0ftvA1dJCFLWcZms30tRdwU2GrZXGMxyrBW04zvMFtY4 MmZkCWseuEuzmt3qCmidAUSHTaZSmw== =LNIK -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 29 05:01: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 2E1FE3A0C82; Thu, 29 Oct 2020 05:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de7jpVJKLfFt; Thu, 29 Oct 2020 05:01: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 546553A0C81; Thu, 29 Oct 2020 05:01:26 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CMPDN2rzLzyy0; Thu, 29 Oct 2020 13:01:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <32754.1603971970@localhost> Date: Thu, 29 Oct 2020 13:01:24 +0100 Cc: mohamed.boucadair@orange.com, "draft-ietf-core-new-block@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 625665683.979172-45859c609f41137b1359c2c71819753b Content-Transfer-Encoding: quoted-printable Message-Id: <195AF3F7-802E-46D2-B522-C2408E392DCB@tzi.org> References: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <22718_1603960697_5F9A7F79_22718_215_1_787AE7BB302AE849A7480A190F8B933031568EFF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <32754.1603971970@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Find a better name for the options 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, 29 Oct 2020 12:01:29 -0000 On 2020-10-29, at 12:46, Michael Richardson wrote: >=20 >> Q-Block I don=E2=80=99t think you can use words that start with Q-dash in the US = right now. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 29 06:48:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E133A0658; Thu, 29 Oct 2020 06:48:27 -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 n4Yl3NzeWMvj; Thu, 29 Oct 2020 06:48:26 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1C43A02C1; Thu, 29 Oct 2020 06:48:25 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4CMRbr3ZHNz2xds; Thu, 29 Oct 2020 14:48:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603979304; bh=hJpBm3253PGMzYrGstqbLoPHyQ1kjDvoqTyMMOvFGmU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tYmT21VaZb12a2TC1GWfZSyHC0ufIT0ReC3DeD1Y8Td+Vf6uwNkXs4ZGP8c1bNXYC /y3PXXznzVtOSUMDVZ80VhCRiTCGHHE/enpB4uCDYYDmOh4/qp8lBIz6rwIWrU6dcn MRqrajw0WUCPcvo/W200vxZJKGRB4GN3qWlGzqnn3qJbJK+CdGQ3D25oNTAo927JLh F1fG4cweIdIYJquUBXWLGJUic2m3QetqKd4ygBZ44Ch3YcJDtCaEdGUg6G43c9HOAV vAtJnsaTQlUSF4N9zY40g/i4ytJ1sTyVcuJsyMBQ9oz+382tXPpSv7rbrOx3DVZ3yA mXZ0TvI/3+fOA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4CMRbr2dpszBrLH; Thu, 29 Oct 2020 14:48:24 +0100 (CET) From: To: Michael Richardson CC: "core@ietf.org" , "draft-ietf-core-new-block@ietf.org" Thread-Topic: [core] draft-ietf-core-new-block: Find a better name for the options Thread-Index: AQHWreklQlhAf8YgJE6pFEGteuH4U6mulYig Date: Thu, 29 Oct 2020 13:48:23 +0000 Message-ID: <7349_1603979304_5F9AC828_7349_92_1_787AE7BB302AE849A7480A190F8B9330315692E0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <17641_1603436697_5F928099_17641_177_5_787AE7BB302AE849A7480A190F8B9330315657B6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <22718_1603960697_5F9A7F79_22718_215_1_787AE7BB302AE849A7480A190F8B933031568EFF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <32754.1603971970@localhost> In-Reply-To: <32754.1603971970@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-new-block: Find a better name for the options 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, 29 Oct 2020 13:48:28 -0000 Hi Michael, I know that you prefer that one as I have access to the anonymous poll :-) Let's see if we can have more voters. Who knows we may end having T-Block o= r even (the new added one) A-Block (Alternative Block). Cheers, Med > -----Message d'origine----- > De=A0: Michael Richardson [mailto:mcr@sandelman.ca] > Envoy=E9=A0: jeudi 29 octobre 2020 12:46 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: core@ietf.org; draft-ietf-core-new-block@ietf.org > Objet=A0: Re: [core] draft-ietf-core-new-block: Find a better name for > the options >=20 >=20 > wrote: > > Thanks for those of you who replied to the poll. >=20 > > So far, we have 4 proposals with the same preference. We will > proceed > > with Q-Block (less changes to the figures :-)) in the next > iteration, > > but we are open to change if we got more inputs. >=20 > Tough-Block is better, I think. > If you like, "T-Block" >=20 > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 29 07:44:26 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19563A0115; Thu, 29 Oct 2020 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, 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 hSs_nm1-4csJ; Thu, 29 Oct 2020 07:44:19 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30067.outbound.protection.outlook.com [40.107.3.67]) (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 26EC03A0141; Thu, 29 Oct 2020 07:44:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YfFf0BF+XHPNXEuF5432zcAAuaHeQiguDtpfGUQ9D+n279avsfvcE85dyjJusp9HcZqgerJl2IIuGvi0lVrvW5pfTOJ52L6N3edDilTL8wtRxaIiYyjzYXY1jur/eUJQU69TRoHt6vDPXcZBLTx4632nyasXnGPUAaNjx3i/vrH8sBJohm/1QBy1ulvzkJJVbW8OEcKieEiqghF8IRe4r5S5hFJo4G4UWT64pEUTPbajcfCWsX0lIGwPZCPAafnFYbMmzOqh8F6t+YhayzMAnFf/e3Fioqsn77zOuG9Y17sCQ+/LoB5OOM/o6XT0USxkI+yY1aM4eaNUQmUv8LWolQ== 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=n1IzE5wOKAqIj2G6NMH31/PGRfm+1Qp4akBktvlHjms=; b=PpWf45BUTuf4hbLAARny/UpLZymdL0iUIabrVWfniYLhGsaaNpFwdyIQBUhyniYeV9x2PMwE5V5y/fXFZnEFyCr8XtW/ydZ65RNxhXKx0qvmxOOi48CZ6D/f5Zn79akoRAveF0j46nAUFRvox0oyLOXKcVlDc2+klH7u/0XgopQNwzn9D+wF2sxiXOLQ0SDEBCkLOJEj3AyAa+ZlOTHSOBUlq5fhkbN/MRnE8AVI7dnzVEZdQEMyAiGk03lbFgmNkYtWe/iDyqHWCct/riG0/jy7IYQhDrku7rkXGiM24s29DgTs/0ZuLKFruGp1QIFy8E/G4/OuYla/fwqc+4ZlJg== 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=n1IzE5wOKAqIj2G6NMH31/PGRfm+1Qp4akBktvlHjms=; b=QwCnDQVuB13ef/gqbw9BcUYkmsatSfmh8EnGVin+a7Y6tEGjUJtQK/Qp5LlHBla68oPtI8WC5/8RDvVzVcfCxpv6QFp5LeHfXP86dV+488grbRTlF1gDkJzA76nSVUrgYEeFgzUZ3uoU6L9OOfnuEb2GM/40b93yHEqE/SkQDWQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0618.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:129::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 29 Oct 2020 14:44:01 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%8]) with mapi id 15.20.3499.019; Thu, 29 Oct 2020 14:44:00 +0000 To: mohamed.boucadair@orange.com, "core@ietf.org" Cc: "draft-ietf-core-new-block@ietf.org" References: <160396208446.12555.831863472742513@ietfa.amsl.com> <8668_1603963155_5F9A8913_8668_225_1_787AE7BB302AE849A7480A190F8B933031568F6C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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: <6cb3e1ee-5484-f83e-98d4-f611e6635eda@ri.se> Date: Thu, 29 Oct 2020 15:43:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <8668_1603963155_5F9A8913_8668_225_1_787AE7BB302AE849A7480A190F8B933031568F6C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BWn9MHJkBuw6hwljITN1J45MzhqICvhQW" X-Originating-IP: [45.83.91.180] X-ClientProxiedBy: HE1PR0301CA0023.eurprd03.prod.outlook.com (2603:10a6:3:76::33) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.3] (45.83.91.180) by HE1PR0301CA0023.eurprd03.prod.outlook.com (2603:10a6:3:76::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19 via Frontend Transport; Thu, 29 Oct 2020 14:44:00 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8ca5d450-0d7c-4eb2-db99-08d87c1912ba X-MS-TrafficTypeDiagnostic: DB8P189MB0618: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rXd+un2Kzm9MgwecCY4vDhilRC0XO0aHRz5V2d+/Uxf+TAE7mAE3mxLCN0JY/I/AoDhfm0PA/2BVhboobG7PhHV8nF35AAcdibRpt6hgyJM40wZMWz/n6WyHjDtPq4HU4aWvkd/7JzfmnYfZDir6HoM2KSHKDcS3y0BgfJnPYzwjtQsXyKmvmRleuREK/0xDpobrXOARG6labNIDt8dFDrteG4AU9T6lf+lgoRm7d93mTlFRLXMK5fKzRrp3nz0acLhD0uAas0d3n1uPgFThaklDUFLde+86v4dhZL5oRcpmmNf6i/g5q7dThmbOP8IomA46N5f4Oismy4tgmisGT0TQyGn8cX7XOluqZpiV4Om67JLyO4fjSH8+HPgST6EKGOto+df5EZOw33dHosBBi6HqbY4Q8zJGk5Y3U96zCWmQGrbDf0l5UQjFyREQ24erX8gnXVjby/T2lHRBe+IYsA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(136003)(376002)(346002)(396003)(16526019)(478600001)(2616005)(235185007)(21480400003)(956004)(83380400001)(4326008)(4001150100001)(6666004)(5660300002)(31686004)(66556008)(45080400002)(26005)(66476007)(36756003)(31696002)(66946007)(8936002)(2906002)(44832011)(316002)(52116002)(186003)(16576012)(966005)(53546011)(66574015)(8676002)(6916009)(86362001)(33964004)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: BbQTy+nk/W9NRmjd4t9q3FlCNs+gWWJUaYoMUWmuJisKeu+OLFvcs78A8nonZPgoaAIPUmRpofodf3d9zDO7pkuanp8gvqGhX/8fRMfcI+Gd7JG38say5rTMODrXVOmnxlqsLORsfbnoGySdrKGrqwdUkS7w8hU+2mCrOpPgbMOijoyX/a3a9vCqUs6xNktFt2KOoAovMRLG2uU1unBKZviRvwSp8jvMQ8zwG7z0qGFDbqDNuuf7ORJx9abRFmEeilQ0cRBo02pEGxejuqkRPuujUEpRrpb+0JebBIm6GSEcxOndtrnm31e4RRTMk3tAbwM4ICW9g1sjdutOOV/PGfvkj/huG1lImqXRR1+1vNi5/51q+NyEygY5jXMqNSKHJev0G+p8l+bx+1RlTZOgGNOF8R0OiC4kxAj9hBrD15jMQOFucQTDblZVr7suUwJIB+yFm/vNOf1L/mg5Qnth4GfU7oVrtLsQnpNUfo/7BkTtXRoyXrh8wf79hCMigOTg9cXQRX2WFenHDlw4zKueqFhO6CfaGcKjuMX9BQDYLR178VcNX00O874uLoGQUqv/x7uDoTa2S8Omkavj8it4XZMRw+6AX5Zu9oWv6Y3MHyDqdXsar/A5gF+4b+EewzvmjTiiO2Gd0KOuUVSccvcLGw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 8ca5d450-0d7c-4eb2-db99-08d87c1912ba X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2020 14:44:00.7399 (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: 8DaMMv0wubT7wo//7smDhn6+F5f74bMec1deB5ueZotuRv3KATxlrDjTnCX68evkhaXzdW++GVolqHMOb91imA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0618 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-02.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, 29 Oct 2020 14:44:23 -0000 --BWn9MHJkBuw6hwljITN1J45MzhqICvhQW Content-Type: multipart/mixed; boundary="q7Ko4JlwxpZHdip2BnVUqP6ytzdafqeGx" --q7Ko4JlwxpZHdip2BnVUqP6ytzdafqeGx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Med, On 2020-10-29 10:19, mohamed.boucadair@orange.com wrote: > Hi all,=20 > > We published the -02 as per the plan presented in the interim. The main= changes are to reflect the outcomes of the interim: > (1) Add a statement that either both or neither options can be supporte= d. > (2) Add an implementation note about how tokens are handled.=20 > (3) Change the name of the options. > (4) Add a clarification about the behaviour when multiple instances of = Q-Block2 are included.=20 > (5) Remove the "MUST NOT" restriction on 2.31 (Continue) as a provision= to (9).=20 > (6) Clarify what is meant by "repeat request". Marco, please check if t= he NEW wording is better. =20 =3D=3D>MT Yes, the new text looks good, as well as having flipped the meaning of the M bit. Thanks for this update! Best, /Marco <=3D=3D > (7) Overflow discussion. Michael, please check and let us know if we ne= ed to say more.=20 > (8) Update the CDDL and add an implementation note to suggest the use o= f indefinite-length arrays. > (9) Add a note about the ACK_TIMEOUT delay after MAX_PAYLOADS.=20 > > We are waiting for the feedback from the WG whether (9) is worth to be = solved at the CoAP level. This is the main pending issue that we would li= ke to fix before asking for the WGLC (https://eur02.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore= %2FuoXMI8vcsGoto6fa1GpgftXS-cU%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.= se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf0bcb413a838a09ecc40cc9e8%= 7C0%7C0%7C637395600621436441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DnUjooRk= YtNoo1QpHPEK0D4kc7%2FLg0fexRtTKkjI55Oc%3D&reserved=3D0).=20 > > Please review and share your comments. > > Cheers, > Jon & Med > >> -----Message d'origine----- >> De=C2=A0: core [mailto:core-bounces@ietf.org] De la part de internet- >> drafts@ietf.org >> Envoy=C3=A9=C2=A0: jeudi 29 octobre 2020 10:01 >> =C3=80=C2=A0: i-d-announce@ietf.org >> Cc=C2=A0: core@ietf.org >> Objet=C2=A0: [core] I-D Action: draft-ietf-core-new-block-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Constrained RESTful Environments WG >> of the IETF. >> >> Title : Constrained Application Protocol (CoAP) >> Block-Wise Transfer Options for Faster Transmission >> Authors : Mohamed Boucadair >> Jon Shallow >> Filename : draft-ietf-core-new-block-02.txt >> Pages : 25 >> Date : 2020-10-29 >> >> Abstract: >> This document specifies alternative Constrained Application >> Protocol >> (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 >> Options. >> >> These options are similar to the CoAP Block1 and Block2 Options, >> not >> a replacement for them, but do enable faster transmission rates >> for >> large amounts of data with less packet interchanges as well as >> supporting faster recovery should any of the blocks get lost in >> transmission. >> >> >> The IETF datatracker status page for this draft is: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&data=3D04%7C0= 1%7Cmarco.tiloca%40ri.se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf0bc= b413a838a09ecc40cc9e8%7C0%7C0%7C637395600621436441%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10= 00&sdata=3DYf5B9lJU%2BBWrBgdJSFhW5%2F9l0V8Odn0iKhW2rU4jMkU%3D&res= erved=3D0 >> >> There are also htmlized versions available at: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= ols.ietf.org%2Fhtml%2Fdraft-ietf-core-new-block-02&data=3D04%7C01%7Cm= arco.tiloca%40ri.se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf0bcb413a= 838a09ecc40cc9e8%7C0%7C0%7C637395600621436441%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am= p;sdata=3Dg85ezNcVn2V6V0xITw8St63XNgpjnWukJjjAeztWVIw%3D&reserved=3D0= >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-new-block-02&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637395600621436441%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&sdata=3DyrDMk6%2FDGoB5nEO8b2DVLXNtZwhRkWcSUinZiK7eJaQ%3D&= ;reserved=3D0 >> >> A diff from the previous version is available at: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-new-block-02&data=3D04%= 7C01%7Cmarco.tiloca%40ri.se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf= 0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637395600621436441%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C1000&sdata=3DRN5bhbD%2F0pQAOd%2BEhFv5DKocLx4Bsl2t1WypWecSHnc%3D&= reserved=3D0 >> >> >> 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: >> https://eur02.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.= ietf.org%2Finternet-drafts%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7= Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%= 7C0%7C637395600621436441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D2cL6qRL19Cs= eFZzpgCxEDDnlBKRnYQ2pagIplFw7kkU%3D&reserved=3D0 >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca%= 40ri.se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf0bcb413a838a09ecc40c= c9e8%7C0%7C0%7C637395600621436441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA= wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3De4= YPV08wXZ7GBH%2BhcSv7PccpxzIuri%2Fe0s34H2qd6g4%3D&reserved=3D0 > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > > _______________________________________________ > core mailing list > core@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca= %40ri.se%7Cda58ad6f454847d9eb6308d87bebc107%7C5a9809cf0bcb413a838a09ecc40= cc9e8%7C0%7C0%7C637395600621436441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3De= 4YPV08wXZ7GBH%2BhcSv7PccpxzIuri%2Fe0s34H2qd6g4%3D&reserved=3D0 --=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 --q7Ko4JlwxpZHdip2BnVUqP6ytzdafqeGx-- --BWn9MHJkBuw6hwljITN1J45MzhqICvhQW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+a1S4ACgkQ7iZktA5Y 2kNViwf/Usk7ziZP8shRMI6F5xrYXMni+uVIBPLvuvrB42hotBNCRzFJgfxjcd1Q 7ykTsDBfAoH/7o4hXDSOXhfBT/qHWAI7AmIejE3sax46Z48NlmbjEfY8ue5GMIn1 JxRDlz2gIkzBKqZTIx1OG4pgPbf7LvQau5/CBW22s/uh7jwvplS9XMPwowJNOndO Ij4wBb3OnhOEMMSQV73ey40oIW2mlgIlRhqqwJZiBzONnDmHudV6F3lqgRcw5qIO V/FatSBD0KfPQqnA0QfErzl3IwpC1PAOM4Et4uP52NRWs+cqTdwdMrFVafdgHg/s 5PtDuDoHgCT4vE8WQF2cH3A54PUAtw== =YLJv -----END PGP SIGNATURE----- --BWn9MHJkBuw6hwljITN1J45MzhqICvhQW--