From nobody Fri Jun 7 09:37:33 2019 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 D6B4F1200DE; Fri, 7 Jun 2019 09:37:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155992545080.19503.729822851599577261.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2019 09:37:30 -0700 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 105 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, 07 Jun 2019 16:37:31 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor cose ace suit lwig artarea t2trg rats Second Priority: saag secdispatch sacm teep irtfopen 6tisch 6lo paw roll httpbis lpwan Third Priority: coinrg dinrg cfrg icnrg detnet dnssd netconf netmod emu dots anima People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Plse also avd any potntlly IoT reltd BOFs&PRGs (e.g., coin) tht mght cme up; also "loops". Prefer some time between the two meetings (48 h or more). Second meeting often is 40 people. --------------------------------------------------------- From nobody Tue Jun 11 07:17:28 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CE4120147; Tue, 11 Jun 2019 07:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ern6IcnakG7; Tue, 11 Jun 2019 07:17:20 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382BA1201A3; Tue, 11 Jun 2019 07:16:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 2BD4F805A0; Tue, 11 Jun 2019 16:16:54 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id B0uFa5nm3X8k; Tue, 11 Jun 2019 16:16:52 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 9FF3C807D0; Tue, 11 Jun 2019 16:16:52 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 9FF3C807D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1560262612; bh=v/2diIhPP4XtEcD5akVN7Gb6tjCW27jDNn9Bc4QThKA=; h=MIME-Version:From:Date:Message-ID:To; b=LZOxHUsa26d0PU0QZyQTFc/soIRXw+RP1U7ThcP818pVZVba/90sJAjPYteSiMDqe iU0q1jt+IUAW+m2ICiorPVJ5bcHTy3qrXrbIimSq03OXBcZF1q8jGYD3yYtjcj+9wR fFYvqFG4eDYN5BHMpANIYJEPco+a/rezSNppofYk= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 5L_bK78ocnwI; Tue, 11 Jun 2019 16:16:52 +0200 (CEST) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 4A5BF805A0; Tue, 11 Jun 2019 16:16:52 +0200 (CEST) Received: by mail-it1-f171.google.com with SMTP id m3so5193471itl.1; Tue, 11 Jun 2019 07:16:52 -0700 (PDT) X-Gm-Message-State: APjAAAXkp/twgMYzCfWaKCt7o+vL9IbU4weFF1iqOi/HTp4USqM0JpYI dUraP0t62l1W0/dbWMHtEojR5j0cIamH8cVWnlM= X-Google-Smtp-Source: APXvYqw4o4nS0nv00cqENoybgXihQfcj3fGy8T55tzGxcD0iJnXHj3onRSc2xaglOxVpzmVBSqhs4sanaEj+3K+wQVU= X-Received: by 2002:a02:b10b:: with SMTP id r11mr46788584jah.140.1560262610880; Tue, 11 Jun 2019 07:16:50 -0700 (PDT) MIME-Version: 1.0 References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> In-Reply-To: From: Laurent Toutain Date: Tue, 11 Jun 2019 16:16:13 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Thomas Fossati Cc: lp-wan , "core@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000ad8e45058b0cf255" Archived-At: Subject: Re: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.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: Tue, 11 Jun 2019 14:17:26 -0000 --000000000000ad8e45058b0cf255 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, Thank you for your comments and changes in the github. On Thu, May 30, 2019 at 1:53 PM Thomas Fossati wrote: > Hi Laurent, > > On Wed, May 29, 2019 at 6:56 PM Laurent Toutain > wrote: > > We have issued a new version of the SCHC coap compression > > to remove an artifact due to a bad github manipulation. > > I have taken a look at the draft but since I cannot claim compression > expertise I will only provide a couple of high level comments: > - Sec 3: "a proxy placed before the compressor may change some field > value". You should qualify the "proxy" as a "CoAP proxy, explicitly > selected by the client" to avoid any ambiguity -- we certainly don't > want to recommend middle-box interference :-) > Yes CoAP proxy. > - Sec 4.1: "This field is bidirectional and MUST be elided during the > SCHC compression". This is a dangerous statement as it leads us > straight into CoAP ossification territory. If you want SCHC to work > with CoAP v1 only what you really want to say here is "SHCH > compression MUST NOT be applied to CoAP packets with version different > from v1". Granted that, a SCHC box deployed today could sit in the > field happily ever after. If not, when a new CoAP version is rolled > out, endpoints wouldn=E2=80=99t be able to use this new version on any pa= th > crossing an SCHC box. > We don't think this will create ossification. The rule is very flexible and do not force to elide this field at any time. For instance, if you have a device that is CoAP v1 only, then you can elide the field. During a transition period if the device accepts CoAP v1 and v2, then the rule can be set to MO=3Dignore and CDA=3Dvalue-sent. Or a rule for v1 and a rule for v2= can be used. In anycase the device will receive the appropriate CoAP version after decompression. Laurent and Ana > > Cheers! > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --000000000000ad8e45058b0cf255 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,


Thank you for your comments and changes in the github.

<= div class=3D"gmail_quote">
On Thu, May= 30, 2019 at 1:53 PM Thomas Fossati <tho.ietf@gmail.com> wrote:
Hi Laurent,

On Wed, May 29, 2019 at 6:56 PM Laurent Toutain
<= laurent.toutain@imt-atlantique.fr> wrote:
> We have issued a new version of the SCHC coap compression
> to remove an artifact due to a bad github manipulation.

I have taken a look at the draft but since I cannot claim compression
expertise I will only provide a couple of high level comments:
- Sec 3: "a proxy placed before the compressor may change some field value".=C2=A0 You should qualify the "proxy" as a "CoAP= proxy, explicitly
selected by the client" to avoid any ambiguity -- we certainly don'= ;t
want to recommend middle-box interference :-)

Yes CoAP proxy.
=C2= =A0
- Sec 4.1: "This field is bidirectional and MUST be elided during the<= br> SCHC compression". This is a dangerous statement as it leads us
straight into CoAP ossification territory.=C2=A0 If you want SCHC to work with CoAP v1 only what you really want to say here is "SHCH
compression MUST NOT be applied to CoAP packets with version different
from v1".=C2=A0 Granted that, a SCHC box deployed today could sit in t= he
field happily ever after.=C2=A0 If not, when a new CoAP version is rolled out, endpoints wouldn=E2=80=99t be able to use this new version on any path=
crossing an SCHC box.

We don't= think this will create ossification. The rule is very flexible and = do not force to elide this field at any time. For instance, if you have a=20 device that is CoAP v1 only, then you can elide the field.
<= br>
During a transition period if the device accepts CoAP v1 and = v2, then the rule can be
set to MO=3Dignore and CDA=3Dvalue-= sent. Or a rule for v1 and a rule for v2 can be used.
In anycase = the device will receive the appropriate CoAP version after decompression.

Laurent and Ana
=C2=A0

Cheers!

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan
--000000000000ad8e45058b0cf255-- From nobody Tue Jun 11 11:17:28 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DE7120048 for ; Tue, 11 Jun 2019 11:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 yt7rgMezjgyz for ; Tue, 11 Jun 2019 11:17:25 -0700 (PDT) Received: from smtp.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 C6DD5120074 for ; Tue, 11 Jun 2019 11:17:24 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45NdWk6trBzyyH; Tue, 11 Jun 2019 20:17:22 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 581969840.89281-0c199097a590b9e618cacba386d749bc Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 11 Jun 2019 20:17:22 +0200 Message-Id: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 11 Jun 2019 18:17:27 -0000 During the last interim, we said we want to run a Working Group last = call on https://tools.ietf.org/html/draft-ietf-core-hop-limit-03 When we discussed this at the interim, we said that, apart from the = overall state of the document, we would like to address two questions in = this WGLC: (1) With a way to perform proxy loop mitigation now available, what is = our recommendation for usage? Is this something that is (a) specific to = DOTS, something that (b) it would now be reasonable to expect a proxy to = add, or (c) something that every CoAP implementation should do? (At the = interim, we were leaning towards (b).) (2) The HTTP world has a concurrent document addressing the same issue,=20= https://tools.ietf.org/html/rfc8586 The technical approach is different here (based on leaving breadcrumbs = in the requests), so it acts as a true loop prevention mechanism, not = just mitigation. It also is more expensive, adding dozens of bytes to = each request passing a proxy. Still, we want to make sure the = difference in approaches is well justified. The WGLC will end in exactly 336 hours so we can discuss the outcome at = the CoRE WG Interim meeting on 2019-06-26. Please indicate your = position in a message to the CoRE mailing list (core@ietf.org) or, = exceptionally, to the chairs (core-chairs@ietf.org). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 11 15:12:13 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4212009C; Tue, 11 Jun 2019 15:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRh5pSebQiNn; Tue, 11 Jun 2019 15:12:10 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 3E08E12006A; Tue, 11 Jun 2019 15:12:10 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id m3so7644846itl.1; Tue, 11 Jun 2019 15:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U2nPoBHf6/4YKlDy9C0w2G0ypXvNLqLWVu7EmUpv7II=; b=VvzIQjZJUyccyOw8BPc7wKoqw427Kb4lkL1eRlrsXyYdKsImi3JABvVCDEe1Z4BvPK mCkLwPl4tFTzXNuU39i63YPA6tJefxO0/IriFygsUoiTfyPj9OCUvfAdU3fzugBU79th biwogDlRV0otXQMS5kn1YClq2VVM/tYRXJ2ACiPRZcWaEVX2e2uFVtCO5svnPR+y3qi5 PzN6G6MuYAUnRsD7iMTfc1Vb3rnOJvhgIKVFHIjpeDUDksMLdhuGXmXFDlekG37fnBDK lcO9TXvAxzGCbTyn0Rv9JopI4Owqg1cttec5BfVE7YaMAwZyuKbWx5mSZIWrtzMxvoK5 K6CA== 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:content-transfer-encoding; bh=U2nPoBHf6/4YKlDy9C0w2G0ypXvNLqLWVu7EmUpv7II=; b=lShXss61KXL/TEP0GKgwnnYBGXUlJeXIuBrflY8ggSgQoQPmxysD34Nk1J2cSMlTyw /VhMSA4YmAODeQdDa1z9GbT/dVUlDe0EAYFEoyOw8Qj2aiamTSc0iVb0oG1z4v1W/VQo l+uG78oHynVM+X6AdVBDfEEcboTt2HDMsjCw0y0hgV3J68yYjDZfGl270CkWz2AetmK8 zsbOYnzM9EVp1RWnK60tZJwBtf6aSIBrgaGpmJfZ4jpp5n1MsfdfGV4askmHSa89lzPT BS4Sk7llYlkbVG51dm4uiqGaPtEytYRWgAnFRoMZOTIgF512XAzZZFGm9prPe+tV3f6p 7qKw== X-Gm-Message-State: APjAAAUV5CxW7/8SLVEZwuHVBc0Z9SVMoTFxtqQx6r+WGAcik3aZ4hC/ /zVvWkPp8Y067yKVA81pWToZL0p44INTuB01E0GA4Hyp+0U= X-Google-Smtp-Source: APXvYqy15qZR1j+W33Pau5dMi2aOU9nIUA/zsvcQ8/UEp55FAvF9I6aUO9f/KjoMzq0j2Z4cnqfX9xAI+IzIDxE2Fo8= X-Received: by 2002:a24:db06:: with SMTP id c6mr22317927itg.47.1560291129524; Tue, 11 Jun 2019 15:12:09 -0700 (PDT) MIME-Version: 1.0 References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> In-Reply-To: From: Thomas Fossati Date: Tue, 11 Jun 2019 23:11:58 +0100 Message-ID: To: Laurent Toutain Cc: lp-wan , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.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: Tue, 11 Jun 2019 22:12:12 -0000 Hi Laurent, Ana, On Tue, Jun 11, 2019 at 3:16 PM Laurent Toutain wrote: > On Thu, May 30, 2019 at 1:53 PM Thomas Fossati wrote= : > > - Sec 4.1: "This field is bidirectional and MUST be elided during > > the SCHC compression". This is a dangerous statement as it leads us > > straight into CoAP ossification territory. If you want SCHC to work > > with CoAP v1 only what you really want to say here is "SHCH > > compression MUST NOT be applied to CoAP packets with version > > different from v1". Granted that, a SCHC box deployed today could > > sit in the field happily ever after. If not, when a new CoAP > > version is rolled out, endpoints wouldn=E2=80=99t be able to use this n= ew > > version on any path crossing an SCHC box. > > We don't think this will create ossification. The rule is very > flexible and do not force to elide this field at any time. For > instance, if you have a device that is CoAP v1 only, then you can > elide the field. > > During a transition period if the device accepts CoAP v1 and v2, then > the rule can be set to MO=3Dignore and CDA=3Dvalue-sent. Or a rule for v1 > and a rule for v2 can be used. In anycase the device will receive the > appropriate CoAP version after decompression. Thanks for taking the time to explain. However, I'm still a bit unsure about what is story for supporting protocol upgrade / evolution, so please let me rephrase my concern and you can clear all my doubts :-) Does the spec in its current form provide the guarantee that a middlebox that is deployed today and never updated (or updated on a different time scale with respect to the endpoints) will not interfere with versions of the protocol it doesn't understand? Otherwise said: what is the default behaviour of a SCHC entity when handling unknown semantics? cheers, thanks, t From nobody Wed Jun 12 06:03:21 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7B1120115 for ; Wed, 12 Jun 2019 06:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 e5R9eJxTmT7G for ; Wed, 12 Jun 2019 06:03:19 -0700 (PDT) Received: from smtp.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 D9DF51200E9 for ; Wed, 12 Jun 2019 06:03:18 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45P6Vr5mblzymB; Wed, 12 Jun 2019 15:03:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <880105127.785171559138207866.JavaMail.nobody@rva2rmd101.webex.com> Date: Wed, 12 Jun 2019 15:03:16 +0200 X-Mao-Original-Outgoing-Id: 582037394.633148-4c2d60bcecac32a0acad4cb02f28a55e Content-Transfer-Encoding: quoted-printable Message-Id: References: <880105127.785171559138207866.JavaMail.nobody@rva2rmd101.webex.com> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Webex meeting info: CoRE Virtual Interim X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 13:03:21 -0000 Hi, The meeting details for the CoRE Virtual Interim that starts in 2 hours = at 1500Z haven=E2=80=99t changed from last time; see below for = reference. The provisional agenda we are proposing is: =E2=80=94 (10) status CoRECONF documents =E2=80=94 (30) handling outstanding errata vs. = corrections/clarifications document =E2=80=94 (up to 50) a few CoRAL issues If you have other items that should be discussed today, please send a = message to core-chairs@ietf.org so we can update the agenda. Gr=C3=BC=C3=9Fe, Carsten Virtual Interim Hosted by CORE Working Group Wednesday, 12 Jun, 2019 15:00 | 1 hour 30 minutes | (UTC+00:00) = Monrovia, Reykjavik Occurs every 2 week(s) on Wednesday effective 5/29/2019 until 11/13/2019 = from 3:00 PM to 4:30 PM, (UTC+00:00) Monrovia, Reykjavik Meeting number: 648 636 609 Password: constrained https://ietf.webex.com/ietf/j.php?MTID=3Dm4f01e31ccd50d241bcf796aed4bf46d4= Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 636 609 > On May 29, 2019, at 15:56, CORE Working Group = wrote: >=20 > Hello, > CORE Working Group changed the Webex meeting information. > =20 > Virtual Interim > Occurs every 2 week(s) on Wednesday effective Wednesday, 29. May 2019 = until Wednesday, 13. November 2019 from 15:00 to 16:30, (UTC+00:00) = Monrovia, Reykjavik > 15:00 | Greenwich Time (Reykjavik, GMT) | 1 hr 30 mins > Meeting number (access code): 648 636 609 > Meeting password: constrained >=20 >=20 > =20 > Add to Calendar > When it's time, join the meeting. > =20 > Join by phone > 1-650-479-3208 Call-in toll number (US/Canada) > =20 > Can't join the meeting? > =20 > IMPORTANT NOTICE: Please note that this Webex service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jun 12 06:10:26 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF393120121 for ; Wed, 12 Jun 2019 06:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 5kOTlxC33aqr for ; Wed, 12 Jun 2019 06:10:23 -0700 (PDT) Received: from smtp.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 DCDEF12011A for ; Wed, 12 Jun 2019 06:10:22 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45P6g05RGYz104y; Wed, 12 Jun 2019 15:10:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> Date: Wed, 12 Jun 2019 15:10:20 +0200 X-Mao-Original-Outgoing-Id: 582037818.524159-143167973b72c27ce23a4c2542ace186 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-se?= =?utf-8?q?nml-etch-03=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 13:10:25 -0000 It seems we have received no (zero, nada) responses to this. We do need a few voices from people who have read it. =20 Please speak up if you did! It=E2=80=99s a short document, so you can read it right now as well: https://tools.ietf.org/html/draft-ietf-core-senml-etch-03 Gr=C3=BC=C3=9Fe, Carsten > On Mar 11, 2019, at 23:40, Carsten Bormann wrote: >=20 > On Mar 6, 2019, at 00:40, Ari Ker=C3=A4nen = wrote: >>=20 >> If there are no further comments on these, I could merge the PR and=20= >> submit a new version. >=20 > =E2=80=A6 which the authors did (see below). >=20 > This starts a working group last call for = draft-ietf-core-senml-etch-03.txt, > ending on >=20 > 24:00 CET on Monday, March 25, 2019. >=20 > Please start a new email thread for each major issue that will need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) >=20 > If you read the draft and think it looks fine, please send a one line=20= > email to the list or to the chairs letting us know that so we can get=20= > a feel of how broad the review has been. >=20 > (To reviewers and authors:) If you are aware of any patent claims = that > might apply to systems that implement these drafts, please review BCP = 78 > and BCP 79 and make any appropriate IPR declaration before the = last-call > ends. If you are not sure whether you need to make a declaration or = not,=20 > please talk to the chairs and we will help. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >>=20 >> Cheers, >> Ari >>=20 >> On 20/02/2019 17.00, Carsten Bormann wrote: >>> In preparation for the impending working-group last call, I have >>> reviewed draft-ietf-core-senml-etch-02.txt. Substantive comments = are >>> below; a set of small editorial comments is going to the authors in >>> parallel. >>>=20 >>> # Minor >>>=20 >>> 1. The text of the draft does not contain an argument that the >>> application of Patch Packs is idempotent. It probably should. >>>=20 >>> 2. The text sometimes says "iPATCH" where it probably should be = saying >>> "PATCH and iPATCH". This should be checked throughout. >>>=20 >>> 3. The term "resource" is sometimes used in lieu of "subset of SenML >>> records that, when resolved, match a given name". >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 From nobody Wed Jun 12 06:39:53 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D381201DD for ; Wed, 12 Jun 2019 06:39:46 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 59WFbFc3GsdR for ; Wed, 12 Jun 2019 06:39: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 7836A1201D8 for ; Wed, 12 Jun 2019 06:39:44 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0223943867; Wed, 12 Jun 2019 15:39:40 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B63CE36; Wed, 12 Jun 2019 15:39:39 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:29f8:74e:8203:f574]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 407DB37; Wed, 12 Jun 2019 15:39:39 +0200 (CEST) Received: (nullmailer pid 28958 invoked by uid 1000); Wed, 12 Jun 2019 13:39:11 -0000 Date: Wed, 12 Jun 2019 15:39:11 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: core Message-ID: <20190612133909.GA27857@hephaistos.amsuess.com> References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-se?= =?utf-8?q?nml-etch-03=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 13:39:52 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, On Wed, Jun 12, 2019 at 03:10:20PM +0200, Carsten Bormann wrote: > It seems we have received no (zero, nada) responses to this. > We do need a few voices from people who have read it. =20 > Please speak up if you did! I've read the latest version now. My concerns of -01 have been either resolved in full or discussed to the point where I'm happy to accept the decision taken on them. +1 on going forward. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl0BAHoACgkQOY0REtOk veEWiA//fORAcvEhNVx2LJAIhA06wutoCaYtcuvBhkfOrOQiYkMvloGBenxRhL1t lsI2di5+cPxp+yhtMONyOsbhZOQ3wuyP6J4b+nUm3U0s3lIzgB/JVI4IkPv7+lj5 DkHm7fgltYciRnSH9uYDV2JNab1KM7B+WQa6VjCq8Y3nHaFYMGIntpCidGgy+kTT igX5KdbwB9lcF6wWugErxKuyE+RmbuOwsJMGiSp/kHdm+sc5axWdyzGOpcDAO8PP 1ZYzlvNc60i9WaoiDyHNO/2EdzjVErHJwHNfBCYOwzzqIIEOLLwvBysnkOykuwwM CIxpdFiggPXFUQrKNJ/XFpDCE/hBNc9eYucWrtzyq8/BuzJ41TVBw98hAHKbXbLO dV1rRNokdGa1z0jOITCkic+aDfGH+2OfJ1sA4uqN8FaAMoiFT4hlEPlHnqiPMIRh 2N9HQM/zVBwq7ubr6CGcQLo6pLinTDxAb8QP3dMAEaFAw6iyU9MYltOsCNIi1e1T nJjc9D4PYhyxhcN6eehjj8XPqBQXlCrjae8QxRcvcy/r4IJvyoIoKbT487pNd80n hqQhTcsT123zvhxG8BbETCRZosrWw2ZsHQM2xsxCesQ9hi9aBdc/0LSxP1+Ndlel gtmw9PrpYdQy3/070gxGilEFNu1bKNA210Loq/S/bLa43J4tzto= =iTdB -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From nobody Thu Jun 13 00:08:13 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F47120098 for ; Thu, 13 Jun 2019 00:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 Zo5y2ztzDV2u for ; Thu, 13 Jun 2019 00:08:09 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7E5120044 for ; Thu, 13 Jun 2019 00:08:09 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 297F77FD; Thu, 13 Jun 2019 03:08:08 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute6.internal (MEProxy); Thu, 13 Jun 2019 03:08:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=KfGeCH qIl+//bQXSSEsgyw7VmuyhhLQvV4kGWpI/Yyk=; b=FoOeHmy7teyMgaqBYUhfsi jPJJijg67ZEYAFJ9kswMtl0UkdO8BmCPsYsgVVlei4oDk73cIerjzz/eI4IwS2md YXWwgrSr6xjw6f2lQkvrSMC/SqjdXbqWxXLLNS82BWvsqkNRmhwFa5z5CepHH8yW rAl8k8pDGVHOcpPZzlzasL6fefZrRyScMJVH5ICLWWr1MTXZvSNR2snvPy4cU9u9 okMWEyfYApo1T5D1E4Xa/0V7mgUcRdJo2XMkCsvJkQD6uWqJ6Gtykm1gMKe2TFrK ajxy91LW6GHfIiWbggo6kObI+JUYg8yjfcN0wSYI2kseQtKu9GleP6mX0S95PJvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehkedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqh ertderreejnecuhfhrohhmpeflrghimhgvuceojhgrihhmvgesihhkihdrfhhiqeenucfr rghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfhhinecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D57B54E009F; Thu, 13 Jun 2019 03:08:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: Date: Thu, 13 Jun 2019 10:08:05 +0300 From: Jaime To: core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] Looking for Reviewers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 07:08:12 -0000 Dear CoRE members, I have sent few email reminders to some of you who volunteered during la= st IETF to do reviews. There are several mature documents that would be = going to WGLC soon and it'd be great if we got more reviews. Similarly,= there are some new documents that would benefit from some attention fro= m the group. So, if you are thinking of providing feedback on a draft, now is the tim= e. Thanks! --=20 Jaime Jim=C3=A9nez From nobody Thu Jun 13 02:14:39 2019 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 B0BD81200BA; Thu, 13 Jun 2019 02:14:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <156041726963.12443.10176924236224495709@ietfa.amsl.com> Date: Thu, 13 Jun 2019 02:14:29 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-21.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, 13 Jun 2019 09:14:30 -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 : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-21.txt Pages : 74 Date : 2019-06-13 Abstract: In many IoT applications, 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. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-21 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-21 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 Jun 13 02:21:15 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67005120291; Thu, 13 Jun 2019 02:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.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 aGVjVAl7L3Ee; Thu, 13 Jun 2019 02:21:11 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298151200D8; Thu, 13 Jun 2019 02:21:10 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id C2BAC1803D424; Thu, 13 Jun 2019 09:21:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=nXahk6HBJ77LEGuUaw n2iFTpaoQu+8cR9qFU9Sa79Oc=; b=dfzIhrA25K6krFJwj9COogKmVP4YlScUau 97d3AiFj9A6xJEXcD7jUflVdeHXZjNAQMblARyc27tUcmQy8IBxZd27l8shjFk8I nfs02POngiVrUkxwiCn0ADqJsrgxB0kZAFpxnENw978EGXBdsGE5sNPvB7O4I3BB UB327fDq4= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -8.5, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:2:41:72:152:355:379:582:599:800:962:967:968:973:983:988:989:1049:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1575:1588:1589:1592:1594:1606:1730:1776:1792:2068:2069:2198:2199:2288:2328:2525:2528:2553:2559:2568:2570:2633:2682:2685:2703:2741:2771:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3353:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4120:4250:4321:4605:4860:5007:6117:6119:6261:6298:7464:7875:7903:8603:9010:9025:9177:10004:11658:12379:12740:13139:30056, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: honey59_61422722ab632 X-Filterd-Recvd-Size: 9094 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf14.hostedemail.com (Postfix) with ESMTPA; Thu, 13 Jun 2019 09:21:08 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1b09ad08b22331bb24db3b2e1b3e0aba" Date: Thu, 13 Jun 2019 11:21:07 +0200 From: Peter van der Stok To: core@ietf.org, core-chairs@ietf.org Cc: i-d-announce@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <156041726963.12443.10176924236224495709@ietfa.amsl.com> References: <156041726963.12443.10176924236224495709@ietfa.amsl.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.37.118.174] Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-21.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, 13 Jun 2019 09:21:14 -0000 --=_1b09ad08b22331bb24db3b2e1b3e0aba Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Core and chairs, A new version of the resource directory is submitted incorporating the discussion results generated during the WGLC of the RD document (RD discovery recommendations). IMO all WGLC comments have been incorporated. @chairs, looking forward to the next phase. Greetings, peter internet-drafts@ietf.org schreef op 2019-06-13 11:14: > 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 : CoRE Resource Directory > Authors : Zach Shelby > Michael Koster > Carsten Bormann > Peter van der Stok > Christian Amsüss > Filename : draft-ietf-core-resource-directory-21.txt > Pages : 74 > Date : 2019-06-13 > > Abstract: > In many IoT applications, 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. The input to an RD is composed > of links and the output is composed of links constructed from the > information stored in the RD. This document specifies the web > interfaces that a Resource Directory supports for web servers to > discover the RD and to register, maintain, lookup and remove > information on resources. Furthermore, new target attributes useful > in conjunction with an RD are defined. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-resource-directory-21 > https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-21 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-21 > > 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/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=_1b09ad08b22331bb24db3b2e1b3e0aba Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Core and chairs,

A new version of the resource directory is s= ubmitted incorporating the discussion results generated during the WGLC of = the RD document (RD discovery recommendations).

IMO all WGLC com= ments have been incorporated.

@chairs, looking forward to the ne= xt phase.

Greetings,

peter

internet-drafts@ietf.org schreef op 2019-06-13 11:14:

=
A New Internet-Draft is available from the on-line Internet-Drafts d= irectories.
This draft is a work item of the Constrained RESTful Envi= ronments WG of the IETF.

      &= nbsp; Title          &nbs= p;: CoRE Resource Directory
       = ; Authors         : Zach Shelb= y
           &= nbsp;           &nbs= p;  Michael Koster
      &nbs= p;            &= nbsp;      Carsten Bormann
  =             &nb= sp;           Peter = van der Stok
         &n= bsp;            = ;    Christian Amsüss
   &nbs= p;Filename        : draft-ietf-core-reso= urce-directory-21.txt
    Pages    = ;       : 74
   &nb= sp;Date            := 2019-06-13

Abstract:
   In many IoT appl= ications, direct discovery of resources is not
   prac= tical due to sleeping nodes, disperse networks, or networks where
&nb= sp;  multicast traffic is inefficient.  These problems can b= e solved by
   employing an entity called a Resource D= irectory (RD), which contains
   information about res= ources held on other servers, allowing lookups
   to b= e performed for those resources.  The input to an RD is composed
=    of links and the output is composed of links constructed= from the
   information stored in the RD.  This = document specifies the web
   interfaces that a Resour= ce Directory supports for web servers to
   discover t= he RD and to register, maintain, lookup and remove
   = information on resources.  Furthermore, new target attributes useful    in conjunction with an RD are defined.

=
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-iet= f-core-resource-directory/

There are also htmlized version= s available at:
https://tools= =2Eietf.org/html/draft-ietf-core-resource-directory-21
https://datatracker.ietf.org/doc/ht= ml/draft-ietf-core-resource-directory-21

A diff from the p= revious version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-resource-di= rectory-21


Please note that it may take a couple of= minutes from the time of submission
until the htmlized version and d= iff are available at tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

_______________________________________________ core mailing list
core@ietf.org
https://www.ietf.org/mailman/= listinfo/core
--=_1b09ad08b22331bb24db3b2e1b3e0aba-- From nobody Fri Jun 14 07:40:53 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60712024F for ; Fri, 14 Jun 2019 07:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lULva-yc9LSu for ; Fri, 14 Jun 2019 07:40:46 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130081.outbound.protection.outlook.com [40.107.13.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBBE120270 for ; Fri, 14 Jun 2019 07:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iyQXkX/Gr0mbAUY3phs6WgvRi37xcE7Hi2V4lWX4HRo=; b=2V87tzMLClsPTmi8VUVvWnjEbx8kBdl+Rc8ae4RntCFGnXtENEeadtBrjlbqUibEBAZ5/7M4Gf0zOI5VqwUB/tegGB9B6qX8Lx5zzvXYLE872VzAkgA9TXEGMpNPW/QmQbJKD9hDGgGsDwmHFexfOsvkerCuovCacQRnd1Xim9c= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.4.202) by AM6PR08MB3623.eurprd08.prod.outlook.com (20.177.115.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Fri, 14 Jun 2019 14:40:41 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::3d83:d73e:b0ff:b8fd]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::3d83:d73e:b0ff:b8fd%5]) with mapi id 15.20.1987.013; Fri, 14 Jun 2019 14:40:41 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: Review of draft-dijk-core-groupcomm-bis-00 Thread-Index: AQHVIr8jP6uKhGeBB0e+2ld05f5wFg== Date: Fri, 14 Jun 2019 14:40:40 +0000 Message-ID: <509FFE7D-1F4E-4E9B-9BA1-DFC82BB3E85B@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [217.140.106.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 522af898-526d-4c58-1b6d-08d6f0d64652 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3623; x-ms-traffictypediagnostic: AM6PR08MB3623: x-ms-exchange-purlcount: 16 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 0068C7E410 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(376002)(366004)(39860400002)(40434004)(189003)(199004)(15374003)(2501003)(68736007)(6512007)(72206003)(8676002)(81166006)(305945005)(53936002)(1730700003)(81156014)(6916009)(2351001)(14444005)(5024004)(4326008)(66066001)(66574012)(6306002)(36756003)(53946003)(86362001)(30864003)(71200400001)(71190400001)(6486002)(256004)(478600001)(2616005)(486006)(476003)(6116002)(14454004)(64756008)(316002)(5660300002)(25786009)(33656002)(8936002)(99286004)(7736002)(76116006)(91956017)(966005)(3846002)(6436002)(186003)(73956011)(66446008)(26005)(2906002)(66476007)(66946007)(66556008)(102836004)(6506007)(5640700003)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3623; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GsEl/FCjLccP2sIFV3WMfn8z5hGRuXyVsSJ7IB4jC8u8HJJ9X270aNSRo20Qb50zFyXLO8Zzoj6CelMHZ244afCPyKLP3ICUg+zbwD2Jqq5tg6jBJko23XrODIGSl+rzahEJ0AQNkjn8p8JzuUtq7K1PO4gc2aEbJIuey4pAtCjh41dvJ++aXDxEMdVTkr/WAZElSx4AamM3ZysrzDbEKECY+aloq+ep9ciV2Bw8K8tUnPQY+gHdd2cK6K7T+z+UcDVHt0C7GH0xy0sJ9S9tx+3P8DR32KJQPe40Hmy5RdWiYIVDd9V/oRJ3P8R2/r6BWdhIe7vlp5cmn5C6iYcsWxgWmLhMGDdPXVSo6AeflLylqhhGlcqYOcDemscFjTlQQcz9CCrgogaJSmpscwNvgvVH5wMcjy5fQ0R35ph+Xdk= Content-Type: text/plain; charset="utf-8" Content-ID: <1C7A220467396B4EB348D59E9247BA3C@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 522af898-526d-4c58-1b6d-08d6f0d64652 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 14:40:41.1668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Thomas.Fossati@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3623 Archived-At: Subject: [core] Review of draft-dijk-core-groupcomm-bis-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 14:40:52 -0000 SGkgRXNrbywgTWFyY28gYW5kIENob25nZ2FuZywNCg0KSSBoYXZlIHJldmlld2VkIGdyb3VwY29t bS1iaXMtMDAgYXMgYXJyYW5nZWQgYXQgbGFzdCBJRVRGIChzb3JyeSBmb3IgdGhlDQpkZWxheSwg bHVja2lseSBKYWltZSBzZW50IGEgdGltZWx5IHJlbWluZGVyKS4NCg0KSSBhZ3JlZSB3aXRoIHRo ZSBjb21tZW50IEppbSBtYWRlIGluIGhpcyByZXZpZXc6IHRoZSBkb2Mgc2hvdWxkIGJlIG1vcmUN CmNsZWFyIG9uIHdoYXQgaXMgcHJvbW90ZWQgdG8gU1REIGFuZCB3aGF0IHBhcnRzIG9mIHRoZSA3 MzkwIGV4cGVyaW1lbnQNCmhhdmUgYmVlbiB0cmFzaGVkLg0KDQpGb3IgZXhhbXBsZSwgaW4gU2Vj dGlvbiAzLjEuMzoNCg0KICAgWy4uLl0gIFtSRkM3MzkwXSBkZWZpbmVzIGFuIGV4cGVyaW1lbnRh bCBwcm90b2NvbCBmb3INCiAgIGNvbmZpZ3VyYXRpb24gb2YgZ3JvdXAgbWVtYmVyc2hpcCBmb3Ig bm9uLXNlY3VyZWQgZ3JvdXANCiAgIGNvbW11bmljYXRpb24sIGJhc2VkIG9uIEpTT04tZm9ybWF0 dGVkIGNvbmZpZ3VyYXRpb24gcmVzb3VyY2VzLg0KDQpJcyB0aGUgY29uZmlndXJhdGlvbiBwcm90 b2NvbCBpbiA3MzkwIHN0aWxsIGNvbnNpZGVyZWQgZXhwZXJpbWVudGFsIG9yDQpub3Q/DQoNCkkg dGhpbmsgaGF2aW5nIHRoaXMgaW5mb3JtYXRpb24gZGlzdGlsbGVkIGF0IHRoZSB2ZXJ5IGJlZ2lu bmluZyBvZiB0aGUNCmRvY3VtZW50IHdvdWxkIGdyZWF0bHkgaGVscC4gIEl0IHJlYWxseSBkb2Vz bid0IG5lZWQgdG8gYmUgYQ0KYmxvdy1ieS1ibG93IGFjY291bnQgb2YgZWFjaCBmZWF0dXJlIC0t IGZvciBleGFtcGxlLCB5b3UgY291bGQganVzdCBzYXkNCiJldmVyeXRoaW5nIGlzIHByb21vdGVk IGV4Y2VwdCB0aGlzIGFuZCB0aGF0LiIgcGx1cyAobWF5YmUpIHNvbWUgZXZpZGVuY2UNCnRoYXQg dGhlIGV4cGVyaW1lbnQgd2FzIHN1Y2Nlc3NmdWwgYW5kLCBmb3IgdGhlIGZlYXR1cmVzIHRoYXQg aGF2ZSBiZWVuDQphYmFuZG9uZWQsIHdoYXQgYXJlIHRoZSBsZXNzb25zIGxlYXJuZWQuDQoNClRo ZSB0aGluZyB0aGF0IGZ1cnRoZXIgY29tcGxpY2F0ZXMgdGhlIGludGVuZGVkIGRvY3VtZW50IHN0 YXR1cyBpcyB0aGUNCmZhY3QgdGhhdCBhdCB0aGUgc2FtZSB0aW1lIHRoZSBzY29wZSBpcyBzdHJl dGNoZWQgYnkgaW50cm9kdWNpbmcNCk9ic2VydmUsIEJsb2NrIGFuZCBncm91cGNvbW0gT1NDT1JF Lg0KDQpEbyB3ZSBuZWVkIGZ1cnRoZXIgZXhwZXJpbWVudGF0aW9uIHdpdGggdGhvc2UgZmVhdHVy ZSBpbiBtdWx0aWNhc3Qgb3INCmFyZSB3ZSBPSyB0byBtb3ZlIHRoZW0gc3RyYWlnaHQgdG8gU1RE PyAgSWYgdGhlIGZvcm1lciwgd2Ugc2hvdWxkDQpwcm9iYWJseSBzcGxpdCB0aG9zZSBmcm9tIHRo ZSAicHJvbW90ZWQiIHBhcnRzIG9mIDczOTAgaW50byBhIHNlcGFyYXRlDQpkb2N1bWVudC4NCg0K QWxzbywgSSBzdWdnZXN0IHRvIG1vdmUgdGhlIHdob2xlICJVc2UgY2FzZSIgc2VjdGlvbiB0byBh biBhcHBlbmRpeDogd2UNCmRvbid0IG5lZWQgdG8gbWFrZSB0aGUgY2FzZSBmb3IgbXVsdGljYXN0 IGluIENvUkUsIGl0J3MgaW4gdGhlIGNoYXJ0ZXINCigiW3RoZSB3b3JraW5nIGdyb3VwXSB3aWxs IGNvbnRpbnVlIHRvIGV2b2x2ZSB0aGUgZXhwZXJpbWVudGFsIGdyb3VwDQpjb21tdW5pY2F0aW9u cyBzdXBwb3J0IChSRkMgNzM5MCkiKSwgYW5kIHRoZSBjdXJyZW50IHBsYWNlbWVudCB0ZW5kcyB0 bw0Kc3RhbmQgaW4gdGhlIHdheSBvZiB0aGUgaW5mb3JtYXRpb25hbCBjb3JlIG9mIHRoZSBkb2N1 bWVudC4NCg0KQSBmaW5hbCBzZW1pLXJhbmRvbSB0aG91Z2h0LiAgSSB3YXMgd29uZGVyaW5nIHdo ZXRoZXIgeW91IGhhZCBsb29rZWQNCmludG8gTUxTIChtZXNzYWdpbmcgbGF5ZXIgc2VjdXJpdHkp IGFscmVhZHk/ICBUaGUgY2hhcnRlciBzYXlzIHRoZSBnb2FsDQoiWy4uLl0gaXMgdG8gZGV2ZWxv cCBhIHN0YW5kYXJkIG1lc3NhZ2luZyBzZWN1cml0eSBwcm90b2NvbCBmb3INCmh1bWFuLXRvLWh1 bWFuKHMpIGNvbW11bmljYXRpb24iLCBidXQgdGhlIHNlY3VyaXR5LCBzY2FsYWJpbGl0eSBhbmQN CmFzeW5jaHJvbmljaXR5IHJlcXVpcmVtZW50cyBsb29rIHZlcnkgd2VsbCBhbGlnbmVkIHdpdGgg SW9ULg0KDQpPSywgdGhhdCdzIGl0LiAgVGhlcmUgYXJlIGEgYnVuY2ggb2YgY29tbWVudHMgaW5s aW5lIChncmVwIGZvciAnXiMnIHRvDQpmaW5kIHRoZW0pLg0KDQpDaGVlcnMsIHRoYW5rcyENCg0K PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tDQoNCkNvUkUgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRS4gRGlqaw0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElvVGNvbnN1bHRhbmN5Lm5sDQpVcGRh dGVzOiA3MzkwLCA3NjQxIChpZiBhcHByb3ZlZCkgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEMuIFdhbmcNCkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEludGVyRGlnaXRhbA0KRXhwaXJlczogU2VwdGVtYmVyIDExLCAyMDE5 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gVGlsb2NhDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJJ U0UgQUINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNYXJjaCAxMCwgMjAxOQ0KDQoNCiAgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgdGhl IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKQ0KICAgICAgICAgICAgICAg ICAgICBkcmFmdC1kaWprLWNvcmUtZ3JvdXBjb21tLWJpcy0wMA0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgdXNlIG9mIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNh dGlvbg0KICAgUHJvdG9jb2wgKENvQVApIGZvciBncm91cCBjb21tdW5pY2F0aW9uLCB1c2luZyBV RFAvSVAgbXVsdGljYXN0IGFzDQogICB0aGUgdW5kZXJseWluZyBkYXRhIHRyYW5zcG9ydC4gIEJv dGggdW5zZWN1cmVkIGFuZCBzZWN1cmVkIENvQVAgZ3JvdXANCiAgIGNvbW11bmljYXRpb24gYXJl IHNwZWNpZmllZC4gIFNlY3VyaXR5IGlzIGFjaGlldmVkIGJ5IHRoZSBHcm91cA0KDQojIHMvYWNo aWV2ZWQgYnkvYWNoaWV2ZWQgYnkgdXNlIG9mLw0KDQogICBPYmplY3QgU2VjdXJpdHkgZm9yIENv bnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIChHcm91cCBPU0NPUkUpDQogICBwcm90b2Nv bC4gIFRoZSB0YXJnZXQgYXBwbGljYXRpb24gYXJlYSBvZiB0aGlzIHNwZWNpZmljYXRpb24gaXMg YW55DQogICBncm91cCBjb21tdW5pY2F0aW9uIHVzZSBjYXNlcyB0aGF0IGludm9sdmUgcmVzb3Vy Y2UtY29uc3RyYWluZWQNCiAgIG5ldHdvcmsgbm9kZXMuICBUaGUgbW9zdCBjb21tb24gb2Ygc3Vj aCB1c2UgY2FzZXMgYXJlIGxpc3RlZCBpbiB0aGlzDQogICBkb2N1bWVudC4NCg0KU3RhdHVzIG9m IFRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5 Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy bmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQogICBEcmFmdHMgaXMg YXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50 ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDExLCAyMDE5Lg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMNCiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZl Y3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJl IHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQogICB0byB0aGlzIGRv Y3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVz dA0KICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNC5lIG9mDQogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHBy b3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZS4NCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlv biAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzDQog ICAgIDEuMS4gIFNjb3BlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDMNCiAgICAgMS4yLiAgVGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgMi4gIFVzZSBDYXNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQogICAgIDIu MS4gIERpc2NvdmVyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDQNCiAgICAgICAyLjEuMS4gIERpc3RyaWJ1dGVkIERldmljZSBEaXNjb3ZlcnkgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAgIDIuMS4yLiAgRGlzdHJpYnV0ZWQgU2Vy dmljZSBEaXNjb3ZlcnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQogICAgICAgMi4xLjMu ICBEaXJlY3RvcnkgRGlzY292ZXJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDUNCiAgICAgMi4yLiAgT3BlcmF0aW9uYWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAgIDIuMi4xLiAgQWN0dWF0b3IgR3JvdXAgQ29udHJv bCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQogICAgICAgMi4yLjIuICBEZXZp Y2UgR3JvdXAgU3RhdHVzIFJlcXVlc3QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYNCiAg ICAgICAyLjIuMy4gIE5ldHdvcmstd2lkZSBRdWVyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgNg0KICAgICAyLjMuICBTb2Z0d2FyZSBVcGRhdGUgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQogICAzLiAgR2VuZXJhbCBHcm91cCBDb21t dW5pY2F0aW9uIE9wZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgICAgMy4x LiAgR3JvdXAgQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNw0KICAgICAgIDMuMS4xLiAgR3JvdXAgRGVmaW5pdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3DQogICAgICAgMy4xLjIuICBHcm91cCBOYW1pbmcgKERO UykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgICAgICAzLjEuMy4g IEdyb3VwIENyZWF0aW9uIGFuZCBNZW1iZXJzaGlwIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg OA0KICAgICAgIDMuMS40LiAgR3JvdXAgTWFpbnRlbmFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA4DQogICAgIDMuMi4gIENvQVAgVXNhZ2UgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkNCiAgICAgICAzLjIuMS4gIFJlcXVl c3QvUmVzcG9uc2UgTW9kZWwgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQ0KICAg ICAgIDMuMi4yLiAgUG9ydCBhbmQgVVJJIFBhdGggU2VsZWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEwDQogICAgICAgMy4yLjMuICBQcm94eSBPcGVyYXRpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTENCiAgICAgICAzLjIuNC4gIENvbmdlc3Rpb24g Q29udHJvbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQ0KICAgICAgIDMu Mi41LiAgT2JzZXJ2aW5nIFJlc291cmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDExDQogICAgICAgMy4yLjYuICBCbG9jay1XaXNlIFRyYW5zZmVyIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTENCiAgICAgMy4zLiAgVHJhbnNwb3J0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgICAgIDMuMy4xLiAg VURQL0lQdjYgTXVsdGljYXN0IFRyYW5zcG9ydCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEy DQogICAgICAgMy4zLjIuICBVRFAvSVB2NCBNdWx0aWNhc3QgVHJhbnNwb3J0ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTINCiAgICAgICAzLjMuMy4gIDZMb1dQQU4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgICAzLjQuICBJbnRlcndvcmtp bmcgd2l0aCBPdGhlciBQcm90b2NvbHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDQogICAg ICAgMy40LjEuICBNTEQvTUxEdjIvSUdNUCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTINCiAgICAgICAzLjQuMi4gIFJQTCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgICAgIDMuNC4zLiAgTVBMIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDQogICA0LiAgVW5z ZWN1cmVkIEdyb3VwIENvbW11bmljYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTINCiAgIDUuICBTZWN1cmVkIEdyb3VwIENvbW11bmljYXRpb24gdXNpbmcgR3JvdXAgT1ND T1JFICAuIC4gLiAuIC4gLiAuICAxMw0KICAgICA1LjEuICBTZWN1cmUgR3JvdXAgTWFpbnRlbmFu Y2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0DQogICA2LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUN CiAgICAgNi4xLiAgQ29BUCBOb1NlYyBNb2RlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxNQ0KICAgICA2LjIuICBHcm91cCBPU0NPUkUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1DQogICAgIDYuMy4gIDZMb1dQQU4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYNCiAgICAg Ni40LiAgV2ktRmkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxNg0KICAgICA2LjUuICBNb25pdG9yaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3DQogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgIDguICBSZWZl cmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNw0KICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE3DQogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgIEFja25vd2xlZGdtZW50 cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQ0K ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE5DQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgdGhlIHVzZSBvZiB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24NCiAgIFByb3Rv Y29sIChDb0FQKSBbUkZDNzI1Ml0gZm9yIGdyb3VwIGNvbW11bmljYXRpb24gW1JGQzczOTBdLiAg Q29BUCBpcw0KICAgYSBSRVNUZnVsIGNvbW11bmljYXRpb24gcHJvdG9jb2wgdGhhdCBpcyBzdWl0 ZWQgZm9yIHVzYWdlIGluDQogICByZXNvdXJjZS1jb25zdHJhaW5lZCBub2RlcywgYW5kIGluIHJl c291cmNlLWNvbnN0cmFpbmVkIG5ldHdvcmtzLg0KICAgVGhpcyBhcmVhIG9mIHVzZSBpcyBzdW1t YXJpemVkIGFzIENvbnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzDQogICAoQ29SRSkuDQoN CiAgIE9uZS10by1tYW55IGdyb3VwIGNvbW11bmljYXRpb24gaXMgYWNoaWV2ZWQgaW4gQ29BUCBi eSB1c2luZyBVRFAvSVANCiAgIG11bHRpY2FzdCwgYXMgdGhlIHVuZGVybHlpbmcgZGF0YSB0cmFu c3BvcnQgdG8gc2VuZCBtdWx0aWNhc3QgcmVxdWVzdA0KICAgbWVzc2FnZXMuICBNdWx0aXBsZSBy ZXNwb25zZSBtZXNzYWdlcyB0byBhIHNpbmdsZSBtdWx0aWNhc3QgcmVxdWVzdA0KICAgbWVzc2Fn ZSBhcmUgc2VudCBvdmVyIFVEUC9JUCB1bmljYXN0LiAgTm90YWJsZSBDb0FQIGltcGxlbWVudGF0 aW9ucw0KICAgc3VwcG9ydGluZyBncm91cCBjb21tdW5pY2F0aW9uIGluY2x1ZGUgdGhlIGZyYW1l d29yayAiRWNsaXBzZQ0KICAgQ2FsaWZvcm5pdW0iIDIuMC54IFtDYWxpZm9ybml1bV0gZnJvbSB0 aGUgRWNsaXBzZSBGb3VuZGF0aW9uIGFuZCB0aGUNCiAgICJJbXBsZW1lbnRhdGlvbiBvZiBDb0FQ IFNlcnZlciAmIENsaWVudCBpbiBHbyIgW0dvLU9DRl0gZnJvbSB0aGUgT3Blbg0KICAgQ29ubmVj dGl2aXR5IEZvdW5kYXRpb24gKE9DRikuDQoNCiAgIFRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZXMg Zm9yIGdyb3VwIGNvbW11bmljYXRpb24gaW4gcmVzb3VyY2UtDQogICBjb25zdHJhaW5lZCBuZXR3 b3JrcyBhcmUgbGlzdGVkIGZpcnN0LCBpbiBTZWN0aW9uIDIuICBCb3RoIHVuc2VjdXJlZA0KICAg YW5kIHNlY3VyZWQgQ29BUCBncm91cCBjb21tdW5pY2F0aW9uIGFyZSBzcGVjaWZpZWQgaW4gdGhp cyBkb2N1bWVudC4NCg0KICAgU2VjdXJpdHkgaXMgYWNoaWV2ZWQgYnkgdXNpbmcgR3JvdXAgT2Jq ZWN0IFNlY3VyaXR5IGZvciBDb25zdHJhaW5lZA0KICAgUkVTVGZ1bCBFbnZpcm9ubWVudHMgKEdy b3VwIE9TQ09SRSkgW0ktRC5pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbV0sDQogICB3aGljaCBp biB0dXJuIGJ1aWxkcyBvbiBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0cmFpbmVkIFJlc3RmdWwN CiAgIEVudmlyb25tZW50cyAoT1NDT1JFKSBbSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHld LiAgVGhpcyBtZXRob2QNCiAgIHByb3ZpZGVzIGVuZC10by1lbmQgYXBwbGljYXRpb24tbGF5ZXIg c2VjdXJpdHkgcHJvdGVjdGlvbiBvZiBDb0FQDQogICBtZXNzYWdlcywgYnkgdXNpbmcgQ0JPUiBP YmplY3QgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkNCiAgIFtSRkM4MTUyXSBbUkZDNzA0 OV0uDQoNCjEuMS4gIFNjb3BlDQoNCiAgIFRoZSBndWlkZWxpbmVzIGFuZCBleHBlcmltZW50YWwg cHJvdG9jb2wgb2YgW1JGQzczOTBdIGFyZSB1cGRhdGVkIGJ5DQogICB0aGlzIGRvY3VtZW50IHdp dGggdGhlIGFib3ZlbWVudGlvbmVkIHNlY3VyaXR5IHNvbHV0aW9uLCBhbmQgd2l0aA0KICAgb3Ro ZXIgcmVjZW50IHByb3RvY29sIGRldmVsb3BtZW50cyBhcm91bmQgQ29BUCBzdWNoIGFzIE9ic2Vy dmUNCiAgIFtSRkM3NjQxXSBhbmQgQmxvY2stV2lzZSBUcmFuc2ZlcnMgW1JGQzc5NTldLg0KICAg Rm9yIGdyb3VwIGNvbW11bmljYXRpb24sIG9ubHkgc29sdXRpb25zIHRoYXQgdXNlIENvQVAgb3Zl ciBVRFAvDQogICBtdWx0aWNhc3QgKGJvdGggSVB2NiBhbmQgSVB2NCkgYXJlIGNvbnNpZGVyZWQu ICBTZWN1cml0eSBzb2x1dGlvbnMNCiAgIGZvciBncm91cCBjb21tdW5pY2F0aW9uIG90aGVyIHRo YW4gR3JvdXAgT1NDT1JFIGFyZSBub3QgaW4gc2NvcGUuDQogICBHZW5lcmFsIHByaW5jaXBsZXMg Zm9yIHNlY3VyZSBncm91cCBjb25maWd1cmF0aW9uIGFyZSBpbiBzY29wZSwNCiAgIGhvd2V2ZXIg YSBzcGVjaWZpYyBwcm90b2NvbCBmb3Igc2VjdXJlIGdyb3VwIGNvbmZpZ3VyYXRpb24gaXMgbm90 DQogICBtYW5kYXRlZCBiZWNhdXNlIHRoaXMgaXMgb2Z0ZW4gYXBwbGljYXRpb24tc3BlY2lmaWMu DQoNCjEuMi4gIFRlcm1pbm9sb2d5DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hP VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kDQog ICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRl c2NyaWJlZCBpbiBCQ1ANCiAgIDE0IFtSRkMyMTE5XSBbUkZDODE3NF0gd2hlbiwgYW5kIG9ubHkg d2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsDQogICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4NCg0K ICAgVGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHJlYWRlcnMgdG8gYmUgZmFtaWxpYXIgd2l0 aCBDb0FQDQogICBbUkZDNzI1Ml0gdGVybWlub2xvZ3kuICBTZWN0aW9uIDUgcmVxdWlyZXMgcmVh ZGVycyB0byBiZSBmYW1pbGlhcg0KICAgd2l0aCBjb25jZXB0cyBhbmQgdGVybWlub2xvZ3kgZnJv bSBPU0NPUkUNCiAgIFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0gYW5kIEdyb3VwIE9T Q09SRQ0KICAgW0ktRC5pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbV0uDQoNCjIuICBVc2UgQ2Fz ZXMNCg0KICAgVG8gaWxsdXN0cmF0ZSB3aGVyZSBhbmQgaG93IENvQVAtYmFzZWQgZ3JvdXAgY29t bXVuaWNhdGlvbiBjYW4gYmUNCiAgIHVzZWQsIHRoaXMgc2VjdGlvbiBzdW1tYXJpemVzIHRoZSBt b3N0IGNvbW1vbiB1c2UgY2FzZXMuICBUaGVzZSB1c2UNCiAgIGNhc2VzIGluY2x1ZGUgYm90aCBz ZWN1cmVkIGFuZCBub24tc2VjdXJlZCBDb0FQIHVzYWdlLiAgRWFjaA0KICAgc3Vic2VjdGlvbiBi ZWxvdyBjb3ZlcnMgb25lIHBhcnRpY3VsYXIgdGVjaG5pY2FsIGNhdGVnb3J5IG9mIHVzZQ0KICAg Y2FzZXMgZm9yIENvUkUuICBXaXRoaW4gZWFjaCBjYXRlZ29yeSwgYSB1c2UgY2FzZSBtYXkgY292 ZXIgbXVsdGlwbGUNCiAgIGFwcGxpY2F0aW9uIGFyZWFzIHN1Y2ggYXMgaG9tZSBJb1QsIGNvbW1l cmNpYWwgYnVpbGRpbmcgSW9UIChzZW5zaW5nDQogICBhbmQgY29udHJvbCksIGluZHVzdHJpYWwg SW9UL2NvbnRyb2wsIG9yIGVudmlyb25tZW50YWwgc2Vuc2luZy4NCg0KMi4xLiAgRGlzY292ZXJ5 DQoNCiAgIERpc2NvdmVyeSBvZiBwaHlzaWNhbCBkZXZpY2VzIGluIGEgbmV0d29yaywgb3IgZGlz Y292ZXJ5IG9mDQogICBpbmZvcm1hdGlvbiBlbnRpdGllcyBob3N0ZWQgb24gbmV0d29yayBkZXZp Y2VzLCBhcmUgb3BlcmF0aW9ucyB0aGF0DQogICBhcmUgcGFydGljdWxhcmx5IHJlcXVpcmVkIGlu IGEgc3lzdGVtIGR1cmluZyB0aGUgcGhhc2VzIG9mIHNldHVwIG9yDQoNCiMgcy9wYXJ0aWN1bGFy bHkvdXN1YWxseSxnZW5lcmFsbHksY29tbW9ubHkvDQoNCiAgIChyZSljb25maWd1cmF0aW9uLiAg V2hlbiBhIGRpc2NvdmVyeSB1c2UgY2FzZSBpbnZvbHZlcyBkZXZpY2VzIHRoYXQNCiAgIG5lZWQg dG8gaW50ZXJhY3Qgd2l0aG91dCBoYXZpbmcgYmVlbiBjb25maWd1cmVkIHByZXZpb3VzbHkgd2l0 aCBhDQogICBjb21tb24gc2VjdXJpdHkgY29udGV4dCwgdW5zZWN1cmVkIENvQVAgY29tbXVuaWNh dGlvbiBpcyB0eXBpY2FsbHkNCiAgIHVzZWQuDQoNCjIuMS4xLiAgRGlzdHJpYnV0ZWQgRGV2aWNl IERpc2NvdmVyeQ0KDQojIEknZCBkcm9wICJEaXN0cmlidXRlZCIgKGhlcmUgYW5kIHRoZSBvdGhl ciBvY2N1cnJlbmNlcyBiZWxvdykgLSBhcyB3ZQ0KIyBhcmUgdGFsa2luZyBhYm91dCB0aGUgSW50 ZXJuZXQgd2UgY2FuIHNhZmVseSBhc3N1bWUgZXZlcnl0aGluZyBpcyBkb25lDQojIGluIGEgZGlz dHJpYnV0ZWQgZmFzaGlvbj8NCg0KICAgRGV2aWNlIGRpc2NvdmVyeSBpcyB0aGUgZGlzY292ZXJ5 IGFuZCBpZGVudGlmaWNhdGlvbiBvZiBuZXR3b3JrZWQNCiAgIGRldmljZXMgb2YgYSBwYXJ0aWN1 bGFyIGNsYXNzLCB0eXBlLCBtb2RlbCwgb3IgYnJhbmQuICBHcm91cA0KICAgY29tbXVuaWNhdGlv biBpcyB1c2VkIGZvciBkaXN0cmlidXRlZCBkZXZpY2UgZGlzY292ZXJ5LCB3aGVyZSBhDQogICBj ZW50cmFsIGRpcmVjdG9yeSBzZXJ2aWNlIGlzIG5vdCB1c2VkLiAgVHlwaWNhbGx5IGluIGRpc3Ry aWJ1dGVkDQogICBzZXJ2aWNlIGRpc2NvdmVyeSwgYSBtdWx0aWNhc3QgcmVxdWVzdCBpcyBzZW50 IHRvIGEgcGFydGljdWxhcg0KDQojIHMvc2VydmljZSBkaXNjb3ZlcnkvZGV2aWNlIGRpc2NvdmVy eS8gPw0KDQogICBhZGRyZXNzIChvciBhZGRyZXNzIHJhbmdlKSBhbmQgbXVsdGljYXN0IHNjb3Bl IG9mIGludGVyZXN0LCBhbmQgYW55DQogICBkZXZpY2VzIGNvbmZpZ3VyZWQgdG8gYmUgZGlzY292 ZXJhYmxlIHdpbGwgcmVzcG9uZCBiYWNrLiAgRm9yIHRoZQ0KICAgYWx0ZXJuYXRpdmUgc29sdXRp b24gb2YgY2VudHJhbGl6ZWQgZGV2aWNlIGRpc2NvdmVyeSBhIGNlbnRyYWwNCiAgIGRpcmVjdG9y eSBzZXJ2aWNlIGlzIGFjY2Vzc2VkIHRocm91Z2ggdW5pY2FzdCwgaW4gd2hpY2ggY2FzZSBncm91 cA0KICAgY29tbXVuaWNhdGlvbiBpcyBub3QgbmVlZGVkLg0KDQoyLjEuMi4gIERpc3RyaWJ1dGVk IFNlcnZpY2UgRGlzY292ZXJ5DQoNCiAgIFNlcnZpY2UgZGlzY292ZXJ5IGlzIHRoZSBkaXNjb3Zl cnkgYW5kIGlkZW50aWZpY2F0aW9uIG9mIHBhcnRpY3VsYXINCiAgIHNlcnZpY2VzIGhvc3RlZCBv biBuZXR3b3JrIGRldmljZXMuICBTZXJ2aWNlcyBjYW4gYmUgaWRlbnRpZmllZCBieQ0KICAgb25l IG9yIG1vcmUgcGFyYW1ldGVycyBzdWNoIGFzIElELCBuYW1lLCBwcm90b2NvbCwgdmVyc2lvbiBh bmQvb3INCiAgIHR5cGUuICBEaXN0cmlidXRlZCBzZXJ2aWNlIGRpc2NvdmVyeSBpbnZvbHZlcyBn cm91cCBjb21tdW5pY2F0aW9uIHRvDQogICByZWFjaCBpbmRpdmlkdWFsIGRldmljZXMgaG9zdGlu ZyBhIHBhcnRpY3VsYXIgc2VydmljZTsgd2l0aCBhIGNlbnRyYWwNCiAgIGRpcmVjdG9yeSBzZXJ2 aWNlIG5vdCBiZWluZyB1c2VkLiAgVGVjaG5pY2FsbHkgdGhpcyBpcyBzaW1pbGFyIHRvIHRoZQ0K ICAgYWJvdmUgdXNlIGNhc2Ugb2YgZGlzdHJpYnV0ZWQgZGV2aWNlIGRpc2NvdmVyeSAoU2VjdGlv biAyLjEuMSkuICBGb3INCiAgIGV4YW1wbGUsIHdoZW4gdXNpbmcgQ29BUCByZXNvdXJjZSBkaXNj b3ZlcnkgKFNlY3Rpb24gNyBvZiBbUkZDNzI1Ml0pDQogICB0aGVyZSBpcyBubyB0ZWNobmljYWwg ZGlzdGluY3Rpb24gYmV0d2VlbiBkb2luZyBkaXN0cmlidXRlZCBkZXZpY2UNCiAgIGRpc2NvdmVy eSBhbmQgZGlzdHJpYnV0ZWQgc2VydmljZSBkaXNjb3Zlcnk6IGJvdGggdXNlIHRoZSBzYW1lIENv QVANCiAgIHF1ZXJ5IGludGVyZmFjZSBkZWZpbmVkIGluIFNlY3Rpb24gNCBvZiBbUkZDNjY5MF0u DQoNCjIuMS4zLiAgRGlyZWN0b3J5IERpc2NvdmVyeQ0KDQogICBUaGlzIHVzZSBjYXNlIGlzIGEg c3BlY2lmaWMgc3ViLWNhc2Ugb2YgRGlzdHJpYnV0ZWQgU2VydmljZSBEaXNjb3ZlcnkNCiAgIChT ZWN0aW9uIDIuMS4yKSwgaW4gd2hpY2ggYSBkZXZpY2UgbmVlZHMgdG8gaWRlbnRpZnkgdGhlIGxv Y2F0aW9uIG9mDQogICBhIERpcmVjdG9yeSBvbiB0aGUgbmV0d29yayB0byB3aGljaCBpdCBjYW4g ZS5nLiByZWdpc3RlciBpdHMgb3duDQogICBvZmZlcmVkIHNlcnZpY2VzLCBvciB0byB3aGljaCBp dCBjYW4gcGVyZm9ybSBxdWVyaWVzIHRvIGlkZW50aWZ5IGFuZA0KICAgbG9jYXRlIG90aGVyIGRl dmljZXMvc2VydmljZXMgaXQgbmVlZHMgdG8gYWNjZXNzIG9uIHRoZSBuZXR3b3JrLiAgT25lDQog ICBwYXJ0aWN1bGFyIHR5cGUgb2YgZGlyZWN0b3J5IGlzIHRoZSBDb1JFIFJlc291cmNlIERpcmVj dG9yeQ0KICAgW0ktRC5pZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5XTsgYW5kIHRoZXJlIG1h eSBiZSBvdGhlciB0eXBlcyBvZg0KICAgZGlyZWN0b3JpZXMgdGhhdCBjYW4gYmUgZGlzY292ZXJl ZCB1c2luZyBDb0FQLiAgU2VjdGlvbiAzLjMgb2YNCiAgIFtSRkM3MzkwXSBzaG93cyBhbiBleGFt cGxlIG9mIGRpc2NvdmVyaW5nIGEgQ29SRSBSZXNvdXJjZSBEaXJlY3RvcnkNCiAgIHVzaW5nIENv QVAgZ3JvdXAgY29tbXVuaWNhdGlvbi4NCg0KIyBUaGUgcGFyYWdyYXBoIGJlbG93IGlzIGVpdGhl ciByZWR1bmRhbnQgKHRoZSByZWFkZXIgYWxyZWFkeSBrbm93cyB3aGF0DQojIGFuIFJEIGlzKSBv ciBiYWRseSBwbGFjZWQgKHRoZSByZWFkZXIgZG9lc24ndCBrbm93IHdoYXQgYW4gUkQgaXMgYW5k DQojIHdlIHNob3VsZCB0ZWxsIGhlciBhdCB0aGUgdG9wIG9mIHRoZSBzZWN0aW9uLCB0byBzZXQg dGhlIHN0YWdlLikNCg0KICAgQXMgZGVmaW5lZCBpbg0KICAgW0ktRC5pZXRmLWNvcmUtcmVzb3Vy Y2UtZGlyZWN0b3J5XSwgYSByZXNvdXJjZSBkaXJlY3RvcnkgaXMgYSB3ZWINCiAgIGVudGl0eSB0 aGF0IHN0b3JlcyBpbmZvcm1hdGlvbiBhYm91dCB3ZWIgcmVzb3VyY2VzIGFuZCBpbXBsZW1lbnRz DQogICBSRVNUIGludGVyZmFjZXMgZm9yIHJlZ2lzdHJhdGlvbiBhbmQgbG9va3VwIG9mIHRob3Nl IHJlc291cmNlcy4gIEZvcg0KICAgZXhhbXBsZSwgYSBkZXZpY2UgY2FuIHJlZ2lzdGVyIGl0c2Vs ZiB0byBhIHJlc291cmNlIGRpcmVjdG9yeSB0byBiZQ0KICAgbG9va2VkIHVwIGJ5IG90aGVyIGRl dmljZXMgYW5kL29yIGFwcGxpY2F0aW9ucy4NCg0KMi4yLiAgT3BlcmF0aW9uYWwNCg0KIyBzL09w ZXJhdGlvbmFsL05ldHdvcmsgT3BlcmF0aW9ucy8gPw0KDQogICBPcGVyYXRpb25hbCB1c2UgY2Fz ZXMgZGVzY3JpYmUgdGhvc2Ugb3BlcmF0aW9ucyB0aGF0IG9jY3VyIG1vc3QNCiAgIGZyZXF1ZW50 bHkgaW4gYSBuZXR3b3JrZWQgc3lzdGVtLCBkdXJpbmcgaXRzIG9wZXJhdGlvbmFsIGxpZmV0aW1l IGFuZA0KICAgbm9ybWFsIHVzYWdlLg0KDQojIFdoYXQgZG8geW91IG1lYW4gYnkgIm5vcm1hbCI/ DQoNCjIuMi4xLiAgQWN0dWF0b3IgR3JvdXAgQ29udHJvbA0KDQogICBHcm91cCBjb21tdW5pY2F0 aW9uIGNhbiBiZSBiZW5lZmljaWFsIHRvIGNvbnRyb2wgYWN0dWF0b3JzIHRoYXQgbmVlZA0KICAg dG8gYWN0IGluIHN5bmNocm9ueSwgYXMgYSBncm91cCwgd2l0aCBzdHJpY3QgdGltaW5nIChsYXRl bmN5KQ0KICAgcmVxdWlyZW1lbnRzLiAgRXhhbXBsZXMgYXJlIG9mZmljZSBsaWdodGluZywgc3Rh Z2UgbGlnaHRpbmcsIHN0cmVldA0KICAgbGlnaHRpbmcsIG9yIGF1ZGlvIGFsZXJ0L1B1YmxpYyBB ZGRyZXNzIHN5c3RlbXMuICBTZWN0aW9ucyAzLjQgYW5kDQogICAzLjUgb2YgW1JGQzczOTBdIHNo b3cgZXhhbXBsZXMgb2YgbGlnaHRpbmcgY29udHJvbCBvZiBhIGdyb3VwIG9mDQogICA2TG9XUEFO LWNvbm5lY3RlZCBsaWdodHMuDQoNCjIuMi4yLiAgRGV2aWNlIEdyb3VwIFN0YXR1cyBSZXF1ZXN0 DQoNCiAgIFRvIHByb3Blcmx5IG1vbml0b3IgdGhlIHN0YXR1cyBvZiBzeXN0ZW1zLCB0aGVyZSBt YXkgYmUgYSBuZWVkIGZvcg0KICAgYWQtaG9jLCB1bnBsYW5uZWQgc3RhdHVzIHVwZGF0ZXMuICBH cm91cCBjb21tdW5pY2F0aW9uIGNhbiBiZSB1c2VkIHRvDQogICBxdWlja2x5IHNlbmQgb3V0IGEg cmVxdWVzdCB0byBhIChwb3RlbnRpYWxseSBsYXJnZSkgbnVtYmVyIG9mIGRldmljZXMNCiAgIGZv ciBzcGVjaWZpYyBpbmZvcm1hdGlvbi4gIEVhY2ggZGV2aWNlIHRoZW4gcmVzcG9uZHMgYmFjayB3 aXRoIHRoZQ0KICAgcmVxdWVzdGVkIGRhdGEuICBUaG9zZSBkZXZpY2VzIHRoYXQgZGlkIG5vdCBy ZXNwb25kIHRvIHRoZSByZXF1ZXN0DQogICBjYW4gb3B0aW9uYWxseSBiZSBwb2xsZWQgYWdhaW4g dmlhIHJlbGlhYmxlIHVuaWNhc3QgY29tbXVuaWNhdGlvbiB0bw0KICAgY29tcGxldGUgdGhlIGRh dGFzZXQuICBUaGUgZGV2aWNlIGdyb3VwIG1heSBiZSBkZWZpbmVkIGUuZy4gYXMgImFsbA0KICAg dGVtcGVyYXR1cmUgc2Vuc29ycyBvbiBmbG9vciAzIiwgb3IgImFsbCBsaWdodHMgaW4gd2luZyBC Ii4gIEZvcg0KICAgZXhhbXBsZSwgaXQgY291bGQgYmUgYSBzdGF0dXMgcmVxdWVzdCBmb3IgZGV2 aWNlIHRlbXBlcmF0dXJlLCBtb3N0DQogICByZWNlbnQgc2Vuc29yIGV2ZW50IGRldGVjdGVkLCBm aXJtd2FyZSB2ZXJzaW9uLCBuZXR3b3JrIGxvYWQsIGFuZC9vcg0KICAgYmF0dGVyeSBsZXZlbC4N Cg0KMi4yLjMuICBOZXR3b3JrLXdpZGUgUXVlcnkNCg0KICAgSW4gc29tZSBjYXNlcyBhIHdob2xl IG5ldHdvcmsgb3Igc3VibmV0IG9mIG11bHRpcGxlIElQIGRldmljZXMgbmVlZHMNCiAgIHRvIGJl IHF1ZXJpZWQgZm9yIHN0YXR1cyBvciBvdGhlciBpbmZvcm1hdGlvbi4gIFRoaXMgaXMgc2ltaWxh ciB0bw0KICAgdGhlIHByZXZpb3VzIHVzZSBjYXNlIGV4Y2VwdCB0aGF0IHRoZSBkZXZpY2UgZ3Jv dXAgaXMgbm90IGRlZmluZWQgaW4NCiAgIHRlcm1zIG9mIGl0cyBmdW5jdGlvbi90eXBlIGJ1dCBp biB0ZXJtcyBvZiBpdHMgbmV0d29yayBsb2NhdGlvbi4NCiAgIFRlY2huaWNhbGx5IHRoaXMgaXMg YWxzbyBzaW1pbGFyIHRvIGRpc3RyaWJ1dGVkIHNlcnZpY2UgZGlzY292ZXJ5DQogICAoU2VjdGlv biAyLjEuMikgd2hlcmUgYSBxdWVyeSBpcyBwcm9jZXNzZWQgYnkgYWxsIGRldmljZXMgb24gYQ0K ICAgbmV0d29yayAtIGV4Y2VwdCB0aGF0IHRoZSBxdWVyeSBpcyBub3QgYWJvdXQgc2VydmljZXMg b2ZmZXJlZCBieSB0aGUNCiAgIGRldmljZSwgYnV0IHJhdGhlciBzcGVjaWZpYyBvcGVyYXRpb25h bCBkYXRhIGlzIHJlcXVlc3RlZC4NCg0KIyBJJ20gbm90IHN1cmUgYWJvdXQgdGhlIHZhbHVlIG9m IHRoaXMgZGlzdGluY3Rpb246IGluIGEgUkVTVGZ1bA0KIyBlbnZpcm9ubWVudCBldmVyeXRoaW5n IHRoYXQgaXMgZXhwb3NlZCAob3BlcmF0aW9uYWwgZGF0YSBvciBzZXJ2aWNlKQ0KIyBpcyBhY2Nl c3NlZCB1bmlmb3JtbHkuICBXaHkgd2UgbmVlZCBhbGwgdGhpcyB0YXhvbm9teT8NCg0KMi4zLiAg U29mdHdhcmUgVXBkYXRlDQoNCiAgIE11bHRpY2FzdCBjYW4gYmUgdXNlZnVsIHRvIGVmZmljaWVu dGx5IGRpc3RyaWJ1dGUgbmV3IHNvZnR3YXJlDQogICAoZmlybXdhcmUpIHRvIGEgZ3JvdXAgb2Yg bXVsdGlwbGUgZGV2aWNlcy4gIEluIHRoaXMgY2FzZSwgdGhlIGdyb3VwDQogICBpcyBkZWZpbmVk IGluIHRlcm1zIG9mIGRldmljZSB0eXBlOiBhbGwgZGV2aWNlcyBpbiB0aGUgdGFyZ2V0IGdyb3Vw DQogICBhcmUga25vd24gdG8gYmUgY2FwYWJsZSBvZiBpbnN0YWxsaW5nIGFuZCBydW5uaW5nIHRo ZSBuZXcgc29mdHdhcmUuDQogICBUaGUgc29mdHdhcmUgaXMgZGlzdHJpYnV0ZWQgYXMgYSBzZXJp ZXMgb2Ygc21hbGxlciBibG9ja3MgdGhhdCBhcmUNCiAgIGNvbGxlY3RlZCBieSBhbGwgZGV2aWNl cyBhbmQgc3RvcmVkIGluIG1lbW9yeS4gIEFsbCBkZXZpY2VzIGluIHRoZQ0KICAgdGFyZ2V0IGdy b3VwIHVzdWFsbHkgYXJlIHJlc3BvbnNpYmxlIGZvciBpbnRlZ3JpdHkgdmVyaWZpY2F0aW9uIG9m DQogICB0aGUgcmVjZWl2ZWQgc29mdHdhcmU7IHdoaWNoIGNhbiBiZSBkb25lIHBlci1ibG9jayBv ciBmb3IgdGhlIGVudGlyZQ0KICAgc29mdHdhcmUgaW1hZ2Ugb25jZSBhbGwgYmxvY2tzIGhhdmUg YmVlbiByZWNlaXZlZC4gIER1ZSB0byB0aGUNCiAgIGluaGVyZW50IHVucmVsaWFiaWxpdHkgb2Yg Q29BUCBtdWx0aWNhc3QgdGhlcmUgbmVlZHMgdG8gYmUgYSBiYWNrdXANCiAgIG1lY2hhbmlzbSAo ZS5nLiBpbXBsZW1lbnRlZCB1c2luZyBDb0FQIHVuaWNhc3QpIGJ5IHdoaWNoIGEgZGV2aWNlIGNh bg0KICAgaW5kaXZpZHVhbGx5IHJlcXVlc3QgbWlzc2luZyBzb2Z0d2FyZSBibG9ja3MuDQoNCjMu ICBHZW5lcmFsIEdyb3VwIENvbW11bmljYXRpb24gT3BlcmF0aW9uDQoNCiAgIFRoZSBnZW5lcmFs IG9wZXJhdGlvbiBvZiBncm91cCBjb21tdW5pY2F0aW9uLCBhcHBsaWNhYmxlIGZvciBib3RoDQog ICB1bnNlY3VyZWQgYW5kIHNlY3VyZWQgb3BlcmF0aW9uLCBpcyBzcGVjaWZpZWQgaW4gdGhpcyBz ZWN0aW9uIGJ5DQogICBnb2luZyB0aHJvdWdoIHRoZSBzdGFjayBmcm9tIHRvcCB0byBib3R0b20u ICBGaXJzdCwgZ3JvdXANCiAgIGNvbmZpZ3VyYXRpb24gKGUuZy4gZ3JvdXAgY3JlYXRpb24gYW5k IG1haW50ZW5hbmNlIHdoaWNoIGFyZSB1c3VhbGx5DQogICBkb25lIGJ5IGFuIGFwcGxpY2F0aW9u LCB1c2VyIG9yIGNvbW1pc3Npb25pbmcgZW50aXR5KSBpcyBjb25zaWRlcmVkDQogICBpbiBTZWN0 aW9uIDMuMS4gIFRoZW4gdGhlIHVzZSBvZiBDb0FQIGZvciBncm91cCBjb21tdW5pY2F0aW9uDQog ICBpbmNsdWRpbmcgc3VwcG9ydCBmb3IgcHJvdG9jb2wgZXh0ZW5zaW9ucyAoQmxvY2stV2lzZSwg T2JzZXJ2ZSwgUEFUQ0gNCiAgIG1ldGhvZCkgZm9sbG93cyBpbiBTZWN0aW9uIDMuMi4gIEhvdyBD b0FQIGdyb3VwIG1lc3NhZ2VzIGFyZSBjYXJyaWVkDQogICBvdmVyIHZhcmlvdXMgdHJhbnNwb3J0 IGxheWVycyBpcyB0aGUgc3ViamVjdCBvZiBTZWN0aW9uIDMuMy4NCiAgIEZpbmFsbHksIFNlY3Rp b24gMy40IGNvdmVycyB0aGUgaW50ZXJ3b3JraW5nIG9mIENvQVAgd2l0aCBvdGhlcg0KICAgcHJv dG9jb2xzIGF0IHRoZSBsYXllcnMgYmVsb3cgaXQuDQoNCjMuMS4gIEdyb3VwIENvbmZpZ3VyYXRp b24NCg0KMy4xLjEuICBHcm91cCBEZWZpbml0aW9uDQoNCiAgIEZvbGxvd2luZyBbUkZDNzM5MF0s IGEgQ29BUCBncm91cCBpcyBkZWZpbmVkIGhlcmUgYXMgYSBzZXQgb2YgQ29BUA0KICAgZW5kcG9p bnRzLCB3aGVyZSBlYWNoIGVuZHBvaW50IGlzIGNvbmZpZ3VyZWQgdG8gcmVjZWl2ZSBDb0FQDQog ICBtdWx0aWNhc3QgcmVxdWVzdHMgdGhhdCBhcmUgc2VudCB0byB0aGUgZ3JvdXAncyBhc3NvY2lh dGVkIElQDQogICBtdWx0aWNhc3QgYWRkcmVzcy4gIEFuIGVuZHBvaW50IG1heSBiZSBhIG1lbWJl ciBvZiBtdWx0aXBsZSBncm91cHMuDQogICBHcm91cCBtZW1iZXJzaGlwKHMpIG9mIGFuIGVuZHBv aW50IG1heSBkeW5hbWljYWxseSBjaGFuZ2Ugb3ZlciB0aW1lLg0KICAgQSBkZXZpY2Ugc2VuZGlu ZyBhIENvQVAgcmVxdWVzdCB0byBhIGdyb3VwIGlzIG5vdCBuZWNlc3NhcmlseSBpdHNlbGYNCiAg IGEgbWVtYmVyIG9mIHRoaXMgZ3JvdXA6IGl0IGlzIG9ubHkgYSBtZW1iZXIgaWYgaXQgYWxzbyBo YXMgYSBDb0FQDQogICBzZXJ2ZXIgZW5kcG9pbnQgbGlzdGVuaW5nIHRvIHJlcXVlc3RzIGZvciB0 aGlzIGdyb3VwLg0KDQogICBBIENvQVAgR3JvdXAgVVJJIGhhcyB0aGUgc2NoZW1lICdjb2FwJyBh bmQgaW5jbHVkZXMgaW4gdGhlIGF1dGhvcml0eQ0KICAgcGFydCBlaXRoZXIgYW4gSVAgbXVsdGlj YXN0IGFkZHJlc3Mgb3IgYSBncm91cCBob3N0bmFtZSAoZS5nLiwgR3JvdXANCiAgIEZ1bGx5IFF1 YWxpZmllZCBEb21haW4gTmFtZSAoRlFETikpIHRoYXQgY2FuIGJlIHJlc29sdmVkIHRvIGFuIElQ DQoNCiMgVGhlIGFib3ZlIHNlbnRlbmNlIHNlZW1zIHRvIHN1Z2dlc3QgRE5TIGlzIGFzc3VtZWQg Zm9yIGZvciBuYW1lLT5JUA0KIyBtYXBwaW5nLCB3aGljaCwgaW4gQ29SRSwgaXMgbm90Lg0KDQog ICBtdWx0aWNhc3QgYWRkcmVzcy4gIEEgR3JvdXAgVVJJIGFsc28gY29udGFpbnMgYW4gb3B0aW9u YWwgVURQIHBvcnQNCiAgIG51bWJlciBpbiB0aGUgYXV0aG9yaXR5IHBhcnQuICBHcm91cCBVUklz IGZvbGxvdyB0aGUgcmVndWxhciBDb0FQIFVSSQ0KICAgc3ludGF4IChTZWN0aW9uIDYgb2YgW1JG QzcyNTJdKS4NCg0KMy4xLjIuICBHcm91cCBOYW1pbmcgKEROUykNCg0KICAgRm9yIGNsaWVudHMs IGl0IGlzIFJFQ09NTUVOREVEIHRvIHVzZSBieSBkZWZhdWx0IGFuIElQIG11bHRpY2FzdA0KICAg YWRkcmVzcyBsaXRlcmFsIGluIGEgY29uZmlndXJlZCBHcm91cCBVUkksIGluc3RlYWQgb2YgYSBo b3N0bmFtZS4NCiAgIFRoaXMgaXMgYmVjYXVzZSBETlMgaW5mcmFzdHJ1Y3R1cmUgbWF5IG5vdCBi ZSBkZXBsb3llZCBpbiBtYW55DQogICBjb25zdHJhaW5lZCBuZXR3b3Jrcy4gIEluIGNhc2UgYSBn cm91cCBob3N0bmFtZSBpcyB1c2VkIGluIHRoZSBHcm91cA0KICAgVVJJLCBpdCBjYW4gYmUgdW5p cXVlbHkgbWFwcGVkIHRvIGFuIElQIG11bHRpY2FzdCBhZGRyZXNzIHZpYSBETlMNCiAgIHJlc29s dXRpb24gLSBpZiBETlMgY2xpZW50IGZ1bmN0aW9uYWxpdHkgaXMgYXZhaWxhYmxlIGluIHRoZSBj bGllbnRzDQogICBhbmQgdGhlIEROUyBzZXJ2aWNlIGlzIHN1cHBvcnRlZCBpbiB0aGUgbmV0d29y ay4gIFNvbWUgZXhhbXBsZXMgb2YNCiAgIGhpZXJhcmNoaWNhbCBncm91cCBGUUROIG5hbWluZyAo YW5kIHNjb3BpbmcpIGZvciBhIGJ1aWxkaW5nIGNvbnRyb2wNCiAgIGFwcGxpY2F0aW9uIGFyZSBz aG93biBpbiBTZWN0aW9uIDIuMiBvZiBbUkZDNzM5MF0uDQoNCjMuMS4zLiAgR3JvdXAgQ3JlYXRp b24gYW5kIE1lbWJlcnNoaXANCg0KICAgR3JvdXAgbWVtYmVyc2hpcCBtYXkgYmUgKGZhY3Rvcnkt KXByZWNvbmZpZ3VyZWQgaW4gZGV2aWNlcyBvcg0KICAgZHluYW1pY2FsbHkgY29uZmlndXJlZCBp biBhIHN5c3RlbSBvbi1zaXRlLg0KDQojIFRoZSBhYm92ZSBzZW50ZW5jZSBkb2Vzbid0IHJlYWQg dmVyeSB3ZWxsLiAgQWxzbywgaXQgZG9lc24ndCBsb29rIGxpa2UNCiMgaXQncyBzdHJpY3RseSBu ZWVkZWQ6IHlvdSBkZWZpbmUgYW4gYWJzdHJhY3QgImNvbmZpZ3VyaW5nIGVudGl0eSIgYW5kDQoj IGl0cyBkdXRpZXMgYmVsb3c7IGlzIGl0IHJlYWxseSBpbXBvcnRhbnQgdG8gc3RhdGUgd2hlcmUg dGhhdCBlbnRpdHkNCiMgb3BlcmF0ZXM/DQoNCiAgIFRvIGNyZWF0ZSBhIGdyb3VwLCBhIGNvbmZp Z3VyaW5nIGVudGl0eSBkZWZpbmVzIGFuIElQIG11bHRpY2FzdA0KICAgYWRkcmVzcyAob3IgaG9z dG5hbWUpIGFuZCBhIFVEUCBwb3J0IG51bWJlciBmb3IgdGhlIGdyb3VwLiAgVGhlbiBpdA0KDQoj IFNob3VsZG4ndCB0aGUgVURQIHBvcnQgYmUgb3B0aW9uYWwgYW5kIGRlZmF1bHQgdG8gdGhlIENv QVAgcG9ydD8NCiMgKEF0IGxlYXN0IHRoaXMgaXMgd2hhdCBTZWN0aW9uIDMuMi4yIHNheXMuKQ0K DQogICBjb25maWd1cmVzIG9uZSBvciBtb3JlIGRldmljZXMgYXMgbGlzdGVuZXJzIHRvIHRoYXQg SVAgbXVsdGljYXN0DQogICBhZGRyZXNzLCB3aXRoIGEgQ29BUCBzZXJ2ZXIgbGlzdGVuaW5nIG9u IHRoZSBzcGVjaWZpYyBwb3J0LiAgVGhlc2UNCiAgIGRldmljZXMgYXJlIHRoZSBncm91cCBtZW1i ZXJzLiAgVGhlIGNvbmZpZ3VyaW5nIGVudGl0eSBjYW4gYmUgYSBsb2NhbA0KICAgYXBwbGljYXRp b24gd2l0aCBwcmVjb25maWd1cmF0aW9uLCBhIHVzZXIsIGEgY2xvdWQgc2VydmljZSwgb3IgYQ0K ICAgbG9jYWwgY29tbWlzc2lvbmluZyB0b29sIGZvciBleGFtcGxlLiAgQWxzbyB0aGUgZGV2aWNl cyBzZW5kaW5nDQogICByZXF1ZXN0cyB0byB0aGUgZ3JvdXAgaW4gdGhlIHJvbGUgb2YgQ29BUCBj bGllbnRzIG5lZWQgdG8gYmUNCiAgIGNvbmZpZ3VyZWQgd2l0aCB0aGUgc2FtZSBpbmZvcm1hdGlv biwgZXZlbiB0aG91Z2ggdGhleSBhcmUgbm90DQogICBuZWNlc3NhcmlseSBncm91cCBtZW1iZXJz LiAgT25lIHdheSB0byBjb25maWd1cmUgYSBjbGllbnQgaXMgdG8NCiAgIHN1cHBseSBpdCB3aXRo IGEgQ29BUCBHcm91cCBVUkkuDQoNCiAgIFRoZSBJRVRGIGRvZXMgbm90IGRlZmluZSBhIG1hbmRh dG9yeSwgc3RhbmRhcmRpemVkIHByb3RvY29sIHRvDQogICBhY2NvbXBsaXNoIHRoZXNlIHN0ZXBz LiAgRm9yIHNlY3VyZSBncm91cCBjb21tdW5pY2F0aW9uLCB0aGUgcGFydCBvZg0KICAgdGhlIHBy b2Nlc3MgdGhhdCBpbnZvbHZlcyBzZWN1cmUgZGlzdHJpYnV0aW9uIG9mIGdyb3VwIGtleXMgTUFZ IHVzZQ0KICAgc3RhbmRhcmRpemVkIGNvbW11bmljYXRpb24gd2l0aCBhIEdyb3VwIE1hbmFnZXIg YXMgZnVydGhlciBkZWZpbmVkIGluDQogICBTZWN0aW9uIDUuICBbUkZDNzM5MF0gZGVmaW5lcyBh biBleHBlcmltZW50YWwgcHJvdG9jb2wgZm9yDQogICBjb25maWd1cmF0aW9uIG9mIGdyb3VwIG1l bWJlcnNoaXAgZm9yIG5vbi1zZWN1cmVkIGdyb3VwDQogICBjb21tdW5pY2F0aW9uLCBiYXNlZCBv biBKU09OLWZvcm1hdHRlZCBjb25maWd1cmF0aW9uIHJlc291cmNlcy4NCg0KIyBJcyB0aGlzIHN0 aWxsIGV4cGVyaW1lbnRhbD8NCg0KMy4xLjQuICBHcm91cCBNYWludGVuYW5jZQ0KDQogICBNYWlu dGVuYW5jZSBvZiBhIGdyb3VwIGluY2x1ZGVzIG5lY2Vzc2FyeSBvcGVyYXRpb25zIHRvIGNvcGUg d2l0aA0KICAgY2hhbmdlcyBpbiBhIHN5c3RlbSwgc3VjaCBhczogYWRkaW5nIGdyb3VwIG1lbWJl cnMsIHJlbW92aW5nIGdyb3VwDQogICBtZW1iZXJzLCByZWNvbmZpZ3VyYXRpb24gb2YgVURQIHBv cnQgYW5kL29yIElQIG11bHRpY2FzdCBhZGRyZXNzLA0KICAgcmVjb25maWd1cmF0aW9uIG9mIHRo ZSBHcm91cCBVUkksIHNwbGl0dGluZyBvZiBncm91cHMsIG9yIG1lcmdpbmcgb2YNCiAgIGdyb3Vw cy4NCg0KICAgRm9yIHVuc2VjdXJlZCBncm91cCBjb21tdW5pY2F0aW9uLCBhZGRpdGlvbi9yZW1v dmFsIG9mIGdyb3VwIG1lbWJlcnMNCiAgIGlzIHNpbXBseSBkb25lIGJ5IGNvbmZpZ3VyaW5nIHRo ZXNlIGRldmljZXMgdG8gc3RhcnQvc3RvcCBsaXN0ZW5pbmcNCiAgIHRvIHRoZSBncm91cCBJUCBt dWx0aWNhc3QgYWRkcmVzcywgYW5kIHRvIHN0YXJ0L3N0b3AgdGhlIENvQVAgc2VydmVyDQogICBs aXN0ZW5pbmcgdG8gdGhlIGdyb3VwIElQIG11bHRpY2FzdCBhZGRyZXNzIGFuZCBwb3J0Lg0KDQog ICBXaGVuIGdyb3VwIGNvbW11bmljYXRpb24gaXMgc2VjdXJlZCB1c2luZyBHcm91cCBPU0NPUkUN CiAgIFtJLUQuaWV0Zi1jb3JlLW9zY29yZS1ncm91cGNvbW1dIChzZWUgU2VjdGlvbiA1KSwgYWxs IENvQVAgZW5kcG9pbnRzDQogICBwYXJ0aWNpcGF0aW5nIHRvIHNlY3VyZSBncm91cCBjb21tdW5p Y2F0aW9uIE1VU1QgYmUgbWVtYmVycyBvZiBhDQoNCiMgSSdtIHVuYWJsZSB0byBwYXJzZSB0aGUg c2VudGVuY2UgYWJvdmUsIGl0IGxvb2tzIHNsaWdodGx5DQojIHRhdXRvbG9naWNhbCB0byBtZS4g IEFsc28sIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgMjExOSBNVVNULg0KIyBXaGF0IGRvIHdlIHdh bnQgdG8gc2F5IGV4YWN0bHk/ICBUaGF0IGdyb3VwIE9TQ09SRSBpcyB0aGUgTVRJDQojIHByb3Rv Y29sIGZvciBzZWN1cmluZyBDb0FQIGV4Y2hhbmdlcyBvdmVyIG11bHRpY2FzdD8gIElmIHNvLCB3 ZSBzaG91bGQNCiMganVzdCBzYXkgdGhhdC4NCg0KICAgY29ycmVzcG9uZGluZyBPU0NPUkUgZ3Jv dXAsIGFuZCB0aHVzIHNoYXJlIGEgY29tbW9uIHNldCBvZg0KICAgY3J5cHRvZ3JhcGhpYyBtYXRl cmlhbC4gIEFkZGl0aW9uYWwgbWFpbnRlbmFuY2Ugb3BlcmF0aW9ucyBhcmUNCiAgIGRpc2N1c3Nl ZCBpbiBTZWN0aW9uIDUuMS4NCg0KMy4yLiAgQ29BUCBVc2FnZQ0KDQozLjIuMS4gIFJlcXVlc3Qv UmVzcG9uc2UgTW9kZWwNCg0KICAgRWRpdG9yIE5vdGUsIFRCRDogdGhpcyBzZWN0aW9uIGlzIHN0 cm9uZ2x5IGJhc2VkIG9uIFNlY3Rpb24gMi41IGluDQogICBbUkZDNzM5MF0uICBJbiBjYXNlIGEg cmVmZXJlbmNlIHRvIHRoaXMgc2VjdGlvbiBpcyBwcmVmZXJyZWQsIHdlIGNhbg0KICAgcmVwbGFj ZSBtb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGlzIHNlY3Rpb24gYnkgYSByZWZlcmVu Y2UgdG8NCiAgIGl0Lg0KDQogICBBbGwgQ29BUCByZXF1ZXN0cyB0aGF0IGFyZSBzZW50IHZpYSBJ UCBtdWx0aWNhc3QgTVVTVCBiZSBOb24tDQogICBjb25maXJtYWJsZSAoU2VjdGlvbiA4LjEgb2Yg W1JGQzcyNTJdKS4gIFRoZSBNZXNzYWdlIElEIGluIGFuIElQDQogICBtdWx0aWNhc3QgQ29BUCBt ZXNzYWdlIGlzIHVzZWQgZm9yIG9wdGlvbmFsIG1lc3NhZ2UgZGVkdXBsaWNhdGlvbiBhcw0KICAg ZGV0YWlsZWQgaW4gU2VjdGlvbiA0LjUgb2YgW1JGQzcyNTJdLg0KDQogICBBIHNlcnZlciBNQVkg c2VuZCBiYWNrIGEgdW5pY2FzdCByZXNwb25zZSB0byB0aGUgQ29BUCBncm91cA0KICAgY29tbXVu aWNhdGlvbiByZXF1ZXN0IC0gd2hldGhlciBpdCBkb2VzIHRoaXMgb3Igbm90IGlzIHNlbGVjdGVk IGJ5DQogICB0aGUgc2VydmVyIGFwcGxpY2F0aW9uLiAgVGhlIHVuaWNhc3QgcmVzcG9uc2VzIHJl Y2VpdmVkIGJ5IHRoZSBDb0FQDQogICBjbGllbnQgbWF5IGJlIGEgbWl4dHVyZSBvZiBzdWNjZXNz IChlLmcuLCAyLjA1IENvbnRlbnQpIGFuZCBmYWlsdXJlDQogICAoZS5nLiwgNC4wNCBOb3QgRm91 bmQpIGNvZGVzIGRlcGVuZGluZyBvbiB0aGUgaW5kaXZpZHVhbCBzZXJ2ZXINCiAgIHByb2Nlc3Np bmcgcmVzdWx0cy4NCg0KICAgVEJEOiB0aGUgQ29BUCBPcHRpb24gZm9yIE5vIFNlcnZlciBSZXNw b25zZSBbUkZDNzk2N10gY2FuIGJlIHVzZWQgYnkNCiAgIHRoZSBjbGllbnQgdG8gaW5mbHVlbmNl IHJlc3BvbnNlIHN1cHByZXNzaW9uIG9uIHRoZSBzZXJ2ZXIgc2lkZS4NCiAgIFBvc3NpYmx5IHdl IGNhbiBpbmNsdWRlIHRoaXMgaW5mb3JtYXRpb24gaGVyZTsgaXQgc3BlY2lmaWNhbGx5DQogICB0 YXJnZXRzIHVzZSBmb3IgbXVsdGljYXN0IHVzZSBjYXNlcyBhbHNvLg0KDQogICBUaGUgY2xpZW50 IGNhbiBkaXN0aW5ndWlzaCB0aGUgb3JpZ2luIG9mIG11bHRpcGxlIHNlcnZlciByZXNwb25zZXMg YnkNCiAgIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBvZiB0aGUgVURQIG1lc3NhZ2UgY29udGFpbmlu ZyB0aGUgQ29BUCByZXNwb25zZQ0KICAgb3IgYW55IG90aGVyIGF2YWlsYWJsZSB1bmlxdWUgaWRl bnRpZmllciAoZS5nLiwgY29udGFpbmVkIGluIHRoZSBDb0FQDQogICByZXNwb25zZSBwYXlsb2Fk KS4gIEluIGNhc2UgYSBjbGllbnQgaGFzIHNlbnQgbXVsdGlwbGUgZ3JvdXAgcmVxdWVzdHMNCiAg IHdpdGggY29uY3VycmVudCBDb0FQIHRyYW5zYWN0aW9ucyBvbmdvaW5nLCB0aGUgcmVzcG9uc2Vz IGFyZSBhcyB1c3VhbA0KICAgbWF0Y2hlZCB0byBhIHJlcXVlc3QgdXNpbmcgdGhlIFRva2VuLg0K DQogICBGb3IgbXVsdGljYXN0IENvQVAgcmVxdWVzdHMsIHRoZXJlIGFyZSBhZGRpdGlvbmFsIGNv bnN0cmFpbnRzIG9uIHRoZQ0KICAgcmV1c2Ugb2YgVG9rZW4gdmFsdWVzLCBjb21wYXJlZCB0byB0 aGUgdW5pY2FzdCBjYXNlLiAgSW4gdGhlIHVuaWNhc3QNCiAgIGNhc2UsIHJlY2VpdmluZyBhIHJl c3BvbnNlIGVmZmVjdGl2ZWx5IGZyZWVzIHVwIGl0cyBUb2tlbiB2YWx1ZSBmb3INCiAgIHJldXNl IHNpbmNlIG5vIG1vcmUgcmVzcG9uc2VzIHdpbGwgZm9sbG93LiAgSG93ZXZlciwgZm9yIG11bHRp Y2FzdA0KICAgQ29BUCwgdGhlIG51bWJlciBvZiByZXNwb25zZXMgaXMgbm90IGJvdW5kZWQgYSBw cmlvcmkuICBUaGVyZWZvcmUsDQogICB0aGUgcmVjZXB0aW9uIG9mIGEgcmVzcG9uc2UgY2Fubm90 IGJlIHVzZWQgYXMgYSB0cmlnZ2VyIHRvICJmcmVlIHVwIg0KICAgYSBUb2tlbiB2YWx1ZSBmb3Ig cmV1c2UuICBSZXVzaW5nIGEgVG9rZW4gdmFsdWUgdG9vIGVhcmx5IGNvdWxkIGxlYWQNCiAgIHRv IGluY29ycmVjdCByZXNwb25zZS9yZXF1ZXN0IG1hdGNoaW5nIGluIHRoZSBjbGllbnQgYW5kIHdv dWxkIGJlIGENCiAgIHByb3RvY29sIGVycm9yLiAgVGhlcmVmb3JlLCB0aGUgdGltZSBiZXR3ZWVu IHJldXNlIG9mIFRva2VuIHZhbHVlcw0KICAgdXNlZCBpbiBtdWx0aWNhc3QgcmVxdWVzdHMgTVVT VCBiZSBncmVhdGVyIHRoYW46DQoNCiAgIE5PTl9MSUZFVElNRSArIE1BWF9MQVRFTkNZICsgTUFY X1NFUlZFUl9SRVNQT05TRV9ERUxBWQ0KDQogICB3aGVyZSBOT05fTElGRVRJTUUgYW5kIE1BWF9M QVRFTkNZIGFyZSBkZWZpbmVkIGluIFNlY3Rpb24gNC44IG9mDQogICBbUkZDNzI1Ml0uICBUaGlz IHNwZWNpZmljYXRpb24gZGVmaW5lcyBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZIGFzDQogICBp biBbUkZDNzM5MF0sIHRoYXQgaXM6IHRoZSBleHBlY3RlZCBtYXhpbXVtIHJlc3BvbnNlIGRlbGF5 IG92ZXIgYWxsDQogICBzZXJ2ZXJzIHRoYXQgdGhlIGNsaWVudCBjYW4gc2VuZCBhIG11bHRpY2Fz dCByZXF1ZXN0IHRvLiAgVGhpcyBkZWxheQ0KICAgaW5jbHVkZXMgdGhlIG1heGltdW0gTGVpc3Vy ZSB0aW1lIHBlcmlvZCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gOC4yIG9mDQogICBbUkZDNzI1Ml0u ICBIb3dldmVyLCBDb0FQIGRvZXMgbm90IGRlZmluZSBhIHRpbWUgbGltaXQgZm9yIHRoZSBzZXJ2 ZXINCiAgIHJlc3BvbnNlIGRlbGF5LiAgVXNpbmcgdGhlIGRlZmF1bHQgQ29BUCBwYXJhbWV0ZXJz LCB0aGUgVG9rZW4gcmV1c2UNCiAgIHRpbWUgTVVTVCBiZSBncmVhdGVyIHRoYW4gMjUwIHNlY29u ZHMgcGx1cyBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZLg0KICAgQSBwcmVmZXJyZWQgc29sdXRp b24gdG8gbWVldCB0aGlzIHJlcXVpcmVtZW50IGlzIHRvIGdlbmVyYXRlIGEgbmV3DQogICB1bmlx dWUgVG9rZW4gZm9yIGV2ZXJ5IG11bHRpY2FzdCByZXF1ZXN0LCBzdWNoIHRoYXQgYSBUb2tlbiB2 YWx1ZSBpcw0KICAgbmV2ZXIgcmV1c2VkLiAgSWYgYSBjbGllbnQgaGFzIHRvIHJldXNlIFRva2Vu IHZhbHVlcyBmb3Igc29tZSByZWFzb24sDQogICBhbmQgYWxzbyBNQVhfU0VSVkVSX1JFU1BPTlNF X0RFTEFZIGlzIHVua25vd24sIHRoZW4gdXNpbmcNCiAgIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVM QVkgPSAyNTAgc2Vjb25kcyBpcyBhIHJlYXNvbmFibGUgZ3VpZGVsaW5lLg0KICAgVGhlIHRpbWUg YmV0d2VlbiBUb2tlbiByZXVzZXMgaXMgaW4gdGhhdCBjYXNlIHNldCB0byBhIHZhbHVlIGdyZWF0 ZXINCiAgIHRoYW4gNTAwIHNlY29uZHMuDQoNCjMuMi4yLiAgUG9ydCBhbmQgVVJJIFBhdGggU2Vs ZWN0aW9uDQoNCiAgIEEgQ29BUCBzZXJ2ZXIgdGhhdCBpcyBhIG1lbWJlciBvZiBhIGdyb3VwIGxp c3RlbnMgZm9yIENvQVAgbWVzc2FnZXMNCiAgIG9uIHRoZSBncm91cCdzIElQIG11bHRpY2FzdCBh ZGRyZXNzLCB1c3VhbGx5IG9uIHRoZSBDb0FQIGRlZmF1bHQgVURQDQogICBwb3J0LCA1NjgzLCBv ciBhbm90aGVyIG5vbi1kZWZhdWx0IFVEUCBwb3J0IGlmIGNvbmZpZ3VyZWQuDQogICBSZWdhcmRs ZXNzIG9mIHRoZSBtZXRob2Qgb2Ygc2VsZWN0aW5nIHRoZSBwb3J0IG51bWJlciwgdGhlIHNhbWUg cG9ydA0KICAgbnVtYmVyIE1VU1QgYmUgdXNlZCBhY3Jvc3MgYWxsIENvQVAgc2VydmVycyB0aGF0 IGFyZSBtZW1iZXJzIG9mIGENCiAgIGdyb3VwIGFuZCBhY3Jvc3MgYWxsIENvQVAgY2xpZW50cyBw ZXJmb3JtaW5nIHRoZSBncm91cCByZXF1ZXN0cyB0bw0KICAgdGhhdCBncm91cC4gIFRoZSBVUkkg UGF0aCB1c2VkIGluIHRoZSByZXF1ZXN0IGlzIHByZWZlcmFibHkgYSBwYXRoDQogICB0aGF0IGlz IGtub3duIHRvIGJlIHN1cHBvcnRlZCBhY3Jvc3MgYWxsIGdyb3VwIG1lbWJlcnMuICBIb3dldmVy DQogICB0aGVyZSBhcmUgdXNlIGNhc2VzIHdoZXJlIGEgcmVxdWVzdCBvbmx5IGNhbiBiZSBzdWNj ZXNzZnVsIGZvciBhDQogICBzdWJzZXQgb2YgdGhlIGdyb3VwIGFuZCBlcnJvcnMgYXJlIHJldHVy bmVkIGJ5IHRob3NlIGdyb3VwIG1lbWJlcnMNCiAgIGZvciB3aGljaCB0aGUgcmVxdWVzdCB3YXMg dW5zdWNjZXNzZnVsLg0KDQojIE1heWJlLCB0aGUgc2VydmVyIGNhbiBkZWNpZGUgdG8gbm90IHJl cGx5IGlmIGl0J3MgYW4gZXJyb3IgKFNlY3Rpb24NCiMgOC4yIG9mIENvQVApDQoNCiAgIFVzaW5n IGRpZmZlcmVudCBwb3J0cyB3aXRoIHRoZSBzYW1lIElQIG11bHRpY2FzdCBhZGRyZXNzIGlzIGFu DQogICBlZmZpY2llbnQgd2F5IHRvIGNyZWF0ZSBtdWx0aXBsZSBDb0FQIGdyb3VwcyBpbiBjb25z dHJhaW5lZCBkZXZpY2VzLA0KICAgaW4gY2FzZSB0aGUgZGV2aWNlJ3Mgc3RhY2sgb25seSBzdXBw b3J0cyBhIGxpbWl0ZWQgbnVtYmVyIG9mIElQDQogICBtdWx0aWNhc3QgZ3JvdXAgbWVtYmVyc2hp cHMuICBIb3dldmVyLCBpdCBtdXN0IGJlIHRha2VuIGludG8gYWNjb3VudA0KICAgdGhhdCB0aGlz IGluY3VycyBhZGRpdGlvbmFsIHByb2Nlc3Npbmcgb3ZlcmhlYWQgb24gZWFjaCBDb0FQIHNlcnZl cg0KICAgcGFydGljaXBhdGluZyBpbiBhdCBsZWFzdCBvbmUgb2YgdGhlc2UgZ3JvdXBzOiBtZXNz YWdlcyB0byBncm91cHMNCiAgIHRoYXQgYXJlIG5vdCBvZiBpbnRlcmVzdCB0byB0aGUgbm9kZSBh cmUgb25seSBkaXNjYXJkZWQgYXQgdGhlIGhpZ2hlcg0KICAgdHJhbnNwb3J0IChVRFApIGxheWVy IGluc3RlYWQgb2YgZGlyZWN0bHkgYXQgdGhlIG5ldHdvcmsgKElQKSBsYXllci4NCg0KICAgUG9y dCA1Njg0IGlzIHJlc2VydmVkIGZvciBEVExTLXNlY3VyZWQgQ29BUCBhbmQgTVVTVCBOT1QgYmUg dXNlZCBmb3INCiAgIGFueSBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24uDQoNCiAgIEZvciBhIENv QVAgc2VydmVyIG5vZGUgdGhhdCBzdXBwb3J0cyByZXNvdXJjZSBkaXNjb3ZlcnkgYXMgZGVmaW5l ZCBpbg0KICAgU2VjdGlvbiAyLjQgb2YgW1JGQzcyNTJdLCB0aGUgZGVmYXVsdCBwb3J0IDU2ODMg TVVTVCBiZSBzdXBwb3J0ZWQNCiAgIChzZWUgU2VjdGlvbiA3LjEgb2YgW1JGQzcyNTJdKSBmb3Ig dGhlICJBbGwgQ29BUCBOb2RlcyIgbXVsdGljYXN0DQogICBncm91cC4NCg0KICAgKFRCRDogY29u c2lkZXIgaWYgd2Ugc2hvdWxkIHNheSB0aGF0IHJlY2VpdmluZyBub2RlL3NlcnZlciBTSE9VTEQg Tk9UDQogICBzZW5kIGEgIklDTVAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgLSBQb3J0IFVucmVh Y2hhYmxlIiBpbiByZXNwb25zZQ0KICAgdG8gc3VjaCByZXF1ZXN0LikNCg0KIyBJIGRvbid0IHRo aW5rIHlvdSBuZWVkIHRvIHNheSBhbnl0aGluZyBoZXJlLCBvdGhlciB0aGFuIG1heWJlDQojIHJl ZmVyZW5jZSBTZWN0aW9uIDMuMi4yIG9mIFJGQyAxMTIyOg0KIyBBbiBJQ01QIGVycm9yIG1lc3Nh Z2UgTVVTVCBOT1QgYmUgc2VudCBhcyB0aGUgcmVzdWx0IG9mDQojIHJlY2VpdmluZzoNCiMgWy4u Ll0NCiMgKiAgICBhIGRhdGFncmFtIGRlc3RpbmVkIHRvIGFuIElQIGJyb2FkY2FzdCBvciBJUCBt dWx0aWNhc3QNCiMgICAgICBhZGRyZXNzDQoNCjMuMi4zLiAgUHJveHkgT3BlcmF0aW9uDQoNCiAg IFRCRDogY2hlY2sgaWYgZHJhZnQtaWV0Zi1jb3JlLW11bHRpcGFydC1jdC0wMiBjYW4gc29sdmUg dGhlICJtdWx0aXBsZQ0KICAgYW5zd2VycyIgY2FzZSB3aGVuIGEgUHJveHkgc2VuZHMgYmFjayBt dWx0aXBsZSBDb0FQIHJlc3BvbnNlcyB0byBhDQogICBtdWx0aWNhc3QgcmVxdWVzdC4gIFBvc3Np Ymx5IGEgY2xpZW50IG1heSBzdXBwb3J0IHRoaXMuICBJcyB0aGVyZSBhDQogICB3YXkgdG8gc2ln bmFsIG11bHRpcGFydCBzdXBwb3J0IGJ5IHRoZSBjbGllbnQ/ICBDYW4gdGhlIG11bHRpcGFydA0K ICAgcGFydHMgc2lnbmFsIHRoZSBvcmlnaW4vSVAgYWRkcmVzcyBvZiB0aGVpciBvcmlnaW4gc2Vy dmVyPw0KDQojIEkgdGhpbmsgInllcyIgaXMgYSBzZW5zaWJsZSBhbnN3ZXIgdG8gYWxsIHF1ZXN0 aW9ucyBhYm92ZS4gIFlvdSdkIGhhdmUNCiMgdG8gZGVmaW5lIHlvdXIgIm1lc3NhZ2UvY29hcCIg Qy1GIGFuZCBzdGljayB0aGUgcmVzcG9uc2VzIGluIHRoZQ0KIyBtdWx0aXBhcnQgYmFnLiAgT3Ig eW91IGNvdWxkIGRvIHNvbWV0aGluZyBtb3JlIGZpbmUtZ3JhaW5lZCBieQ0KIyBkZWZpbmluZyBh IENvbnRlbnQgVHlwZSBzaW1pbGFyIHRvICJhcHBsaWNhdGlvbi9odHRwIiBieQ0KIyBzcGVjaWFs aXNpbmcgbXVsdGlwYXJ0IChpLmUuLCBvdmVycmlkaW5nIGl0J3MgQy1GKS4NCiMNCiMgT25lIHRo aW5nIHRoYXQgaXMgbWF5YmUgd29ydGggbm90aW5nIGlzIHRoYXQgZ29pbmcgdGhyb3VnaCBhIHBy b3h5IGhhcw0KIyB0aGUgYWR2YW50YWdlIHRoYXQgeW91IGNhbiBsZXQgaXQgZG8gdGhlIGJ1ZmZl cmluZyBhbmQgdXNlIEJsb2NrIHRvDQojIGZyYWdtZW50IHRoZSBtdWx0aXBhcnQgaW4gZGlnZXN0 aWJsZSBiaXRzLg0KIw0KIyBJIHdhcyB3b25kZXJpbmcgd2hldGhlciB0aGVyZSdzIGFueXRoaW5n IHRvIGJlIHNhaWQgaGVyZSBhYm91dCBIQw0KIyBwcm94aWVzPw0KDQoNCjMuMi40LiAgQ29uZ2Vz dGlvbiBDb250cm9sDQoNCiAgIFRoZSBtZWFzdXJlcyB0byByZWR1Y2UgbmV0d29yayBjb25nZXN0 aW9uIHJpc2tzIGFyZSBsaXN0ZWQgaW4NCiAgIFNlY3Rpb24gMi44IG9mIFtSRkM3MzkwXSwgaW5j bHVkaW5nIGJvdGggbWFuZGF0b3J5IHByb3RvY29sIGVsZW1lbnRzDQogICBhcyB3ZWxsIGFzIGd1 aWRlbGluZXMuICBUaGlzIHNwZWNpZmljYXRpb24gUkVDT01NRU5EUyB0byBhcHBseSB0aGUNCg0K IyBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IG5vdCBNVVNUPw0KDQogICBndWlkZWxpbmVzIHNwZWNp ZmllZCBpbiB0aGF0IHNlY3Rpb24uDQoNCjMuMi41LiAgT2JzZXJ2aW5nIFJlc291cmNlcw0KDQog ICBUaGUgQ29BUCBPYnNlcnZlIE9wdGlvbiBbUkZDNzY0MV0gaXMgYSBwcm90b2NvbCBleHRlbnNp b24gb2YgQ29BUCwNCiAgIHRoYXQgYWxsb3dzIGEgQ29BUCBjbGllbnQgdG8gcmV0cmlldmUgYSBy ZXByZXNlbnRhdGlvbiBvZiBhIHJlc291cmNlDQogICBhbmQgYXV0b21hdGljYWxseSBrZWVwIHRo aXMgcmVwcmVzZW50YXRpb24gdXAtdG8tZGF0ZSBvdmVyIGEgbG9uZ2VyDQogICBwZXJpb2Qgb2Yg dGltZS4gIFRoZSBjbGllbnQgZ2V0cyBub3RpZmllZCB3aGVuIHRoZSByZXByZXNlbnRhdGlvbiBo YXMNCiAgIGNoYW5nZWQuICBbUkZDNzY0MV0gZG9lcyBub3QgbWVudGlvbiB3aGV0aGVyIHRoZSBP YnNlcnZlIE9wdGlvbiBjYW4NCiAgIGJlIGNvbWJpbmVkIHdpdGggQ29BUCBtdWx0aWNhc3QuDQoN CiAgIFVzaW5nIHRoZSBPYnNlcnZlIE9wdGlvbiBpbiBhIENvQVAgbXVsdGljYXN0IEdFVCByZXF1 ZXN0IGlzDQogICBleHBsaWNpdGx5IHNwZWNpZmllZCBoZXJlIGFzIGFsbG93ZWQ7IGl0IGlzIHVz ZWZ1bCBhcyBhIG1lYW5zIHRvDQogICBzdGFydCBvYnNlcnZpbmcgYSBwYXJ0aWN1bGFyIHJlc291 cmNlIG9uIGFsbCBtZW1iZXJzIG9mIGEgKG11bHRpY2FzdCkNCiAgIGdyb3VwIGF0IHRoZSBzYW1l IHRpbWUuICBHcm91cCBtZW1iZXJzIHRoYXQgZG8gbm90IGhhdmUgdGhpcyByZXNvdXJjZQ0KICAg b3IgZG8gbm90IGFsbG93IHRoZSBHRVQgbWV0aG9kIG9uIGl0IHdpbGwgcmVzcG9uZCB3aXRoIHRo ZSB1c3VhbCA0LjA0DQogICBOb3QgRm91bmQgb3IgNC4wNSBNZXRob2QgTm90IEFsbG93ZWQsIHJl c3BlY3RpdmVseS4NCg0KIyBEaXR0bywgdGhlIHNlcnZlciBjYW4gZGVjaWRlIHRvIG5vdCByZXBs eSBpZiBpdCdzIGFuIGVycm9yDQoNCiAgIEEgY2xpZW50IHNlbmRpbmcgYSBtdWx0aWNhc3QgR0VU IHdpdGggT2JzZXJ2ZSBNQVkgcmVwZWF0IHRoaXMgcmVxdWVzdA0KICAgdXNpbmcgdGhlIHNhbWUg VG9rZW4gT3B0aW9uIGFuZCBPYnNlcnZlIE9wdGlvbiB2YWx1ZSwgaW4gb3JkZXIgdG8NCiAgIGVu c3VyZSB0aGF0IGVub3VnaCAob3IgYWxsKSBncm91cCBtZW1iZXJzIGhhdmUgYmVlbiByZWFjaGVk IHdpdGggdGhlDQogICByZXF1ZXN0Lg0KDQozLjIuNi4gIEJsb2NrLVdpc2UgVHJhbnNmZXINCg0K ICAgU2VjdGlvbiAyLjggb2YgW1JGQzc5NTldIHNwZWNpZmllcyBob3cgYSBzZXJ2ZXIgKGdyb3Vw IG1lbWJlciksDQogICByZXNwb25kaW5nIHRvIGEgbXVsdGljYXN0IHJlcXVlc3Qgd2l0aCBhIGxh cmdlIHJlc291cmNlLCBjYW4gdXNlDQogICBCbG9jay1XaXNlIHRyYW5zZmVyIHRvIGxpbWl0IHRo ZSBzaXplIG9mIHRoZSBpbml0aWFsIHJlc3BvbnNlLg0KDQogICBUQkQ6IGludmVzdGlnYXRlIHVz ZSBvZiBCbG9jay1XaXNlIGZvciBQVVQvUE9TVC9QQVRDSC9pUEFUQ0gNCiAgIG9wZXJhdGlvbnMg ZS5nLiB0byBiZSB1c2VkIGZvciBkaXN0cmlidXRpbmcgc29mdHdhcmUgYmxvY2tzIG92ZXINCg0K IyBzL3NvZnR3YXJlIGJsb2Nrcy9zb2Z0d2FyZSB1cGRhdGVzLyA/DQoNCiAgIG11bHRpY2FzdC4g IFdlIGNhbiBzcGVjaWZ5IGl0cyB1c2UsIG9yIHJlbWFyayB0aGF0IHRoaXMgaXMgdW5kZWZpbmVk Lg0KDQozLjMuICBUcmFuc3BvcnQNCg0KICAgVEJEOiBNYXJrIFtSRkM4MzIzXSAoVENQLCBUTFMs IFdlYlNvY2tldHMpIGFzIG5vdCBhcHBsaWNhYmxlIGZvciB0aGlzDQogICBmb3JtIG9mIGdyb3Vw Y29tbSwgYXMgd2VsbCBhcyBDb0FQLW92ZXItU01TLg0KDQozLjMuMS4gIFVEUC9JUHY2IE11bHRp Y2FzdCBUcmFuc3BvcnQNCg0KICAgVEJEOiBpbmNsdWRlIHRoZSAiRXhjZXB0aW9ucyIgY2FzZXMg aGVyZSBvZiBSRkMgNzM5MCBTZWN0aW9uIDIuMTAuDQogICBTdGF0ZSB0aGF0IElQdjYgbXVsdGlj YXN0IGlzIHByZXJlcXVpc2l0ZS4gIEFsc28gbWVudGlvbiB0aGUgQWxsLQ0KICAgQ29BUC1ub2Rl cyBJUHY2IGFkZHJlc3Nlcy4NCg0KMy4zLjIuICBVRFAvSVB2NCBNdWx0aWNhc3QgVHJhbnNwb3J0 DQoNCiAgIFRCRDogaW5jbHVkZXMgdGhlICJFeGNlcHRpb25zIiBjYXNlcyBoZXJlIG9mIFJGQyA3 MzkwIDIuMTAuICBTdGF0ZQ0KICAgdGhhdCBJUHY0IG11bHRpY2FzdCBpcyBwcmVyZXF1aXNpdGUu ICBtZW50aW9uIEFsbC1Db0FQLW5vZGVzIElQdjQNCiAgIGFkZHJlc3NlcyBhbmQgdGhlIGxpa2UN Cg0KMy4zLjMuICA2TG9XUEFODQoNCiAgIFRCRDogNmxvd3Bhbi1zcGVjaWZpYyBjb25zaWRlcmF0 aW9ucyB0byBnbyBoZXJlLiAgU3BlY2lmaWNhbGx5LCBhDQogICBtdWx0aWNhc3QgcmVxdWVzdCBz aG91bGQgcHJlZmVyYWJseSBmaXQgaW4gb25lIEwyIGZyYW1lIHRvIGF2b2lkIHRoZQ0KICAgc3Ry b25nIHBlcmZvcm1hbmNlIGRyb3AgdGhhdCBjb21lcyB3aXRoIDZMb1dQQU4tZnJhZ21lbnRhdGlv biBhbmQNCiAgIHJlYXNzZW1ibHkuICBBbHNvIHJlZmVyZW5jZSBbUkZDNzM0Nl0gZm9yIHRoZSBy ZWFsbS1sb2NhbCBzY29wZS4NCg0KMy40LiAgSW50ZXJ3b3JraW5nIHdpdGggT3RoZXIgUHJvdG9j b2xzDQoNCjMuNC4xLiAgTUxEL01MRHYyL0lHTVANCg0KICAgVEJEOiBzZWUgU2VjdGlvbiA0LjIg b2YgW1JGQzczOTBdIGFuZCBpbmNsdWRlIHRoZSBjb250ZW50IGhlcmUgb3INCiAgIHJlZmVyIHRv IGl0Lg0KDQozLjQuMi4gIFJQTA0KDQogICBUQkQ6IHNlZSBTZWN0aW9uIDQuMyBvZiBbUkZDNzM5 MF0gYW5kIGluY2x1ZGUgdGhlIGNvbnRlbnQgaGVyZSBvcg0KICAgcmVmZXIgdG8gaXQuDQoNCjMu NC4zLiAgTVBMDQoNCiAgIFRCRDogc2VlIFNlY3Rpb24gNC40LiAgW1JGQzczOTBdIGFuZCBpbmNs dWRlIHRoZSBjb250ZW50IGhlcmUgb3INCiAgIHJlZmVyIHRvIGl0Lg0KDQo0LiAgVW5zZWN1cmVk IEdyb3VwIENvbW11bmljYXRpb24NCg0KICAgQ29BUCBncm91cCBjb21tdW5pY2F0aW9uIGNhbiBv cGVyYXRlIGluIENvQVAgTm9TZWMgKE5vIFNlY3VyaXR5KQ0KICAgbW9kZSwgd2l0aG91dCB1c2lu ZyBhcHBsaWNhdGlvbi1sYXllciBhbmQgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5DQogICBtZWNo YW5pc21zLiAgVGhlIE5vU2VjIG1vZGUgdXNlcyB0aGUgImNvYXAiIHNjaGVtZSwgYW5kIGlzIGRl ZmluZWQgaW4NCiAgIFNlY3Rpb24gOSBvZiBbUkZDNzI1Ml0uICBCZWZvcmUgdXNpbmcgdGhpcyBt b2RlIG9mIG9wZXJhdGlvbiwgdGhlDQogICBzZWN1cml0eSBpbXBsaWNhdGlvbnMgKFNlY3Rpb24g Ni4xKSBtdXN0IGJlIHdlbGwgdW5kZXJzdG9vZC4NCg0KNS4gIFNlY3VyZWQgR3JvdXAgQ29tbXVu aWNhdGlvbiB1c2luZyBHcm91cCBPU0NPUkUNCg0KICAgVGhlIGFwcGxpY2F0aW9uLWxheWVyIHBy b3RvY29sIE9iamVjdCBTZWN1cml0eSBmb3IgQ29uc3RyYWluZWQNCiAgIFJFU1RmdWwgRW52aXJv bm1lbnRzIChPU0NPUkUpIFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0NCiAgIHByb3Zp ZGVzIGVuZC10by1lbmQgZW5jcnlwdGlvbiwgaW50ZWdyaXR5IGFuZCByZXBsYXkgcHJvdGVjdGlv biBvZg0KICAgQ29BUCBtZXNzYWdlcyBleGNoYW5nZWQgYmV0d2VlbiB0d28gQ29BUCBlbmRwb2lu dHMuICBUaGVzZSBjYW4gYWN0DQogICBib3RoIGFzIENvQVAgQ2xpZW50IGFzIHdlbGwgYXMgQ29B UCBTZXJ2ZXIsIGFuZCBzaGFyZSBhbiBPU0NPUkUNCiAgIFNlY3VyaXR5IENvbnRleHQgdXNlZCB0 byBwcm90ZWN0IGFuZCB2ZXJpZnkgZXhjaGFuZ2VkIG1lc3NhZ2VzLiAgVGhlDQogICB1c2Ugb2Yg T1NDT1JFIGRvZXMgbm90IGFmZmVjdCB0aGUgVVJJIHNjaGVtZSBhbmQgT1NDT1JFIGNhbiB0aGVy ZWZvcmUNCiAgIGJlIHVzZWQgd2l0aCBhbnkgVVJJIHNjaGVtZSBkZWZpbmVkIGZvciBDb0FQLg0K DQogICBPU0NPUkUgdXNlcyBDT1NFIFtSRkM4MTUyXSB0byBwZXJmb3JtIGVuY3J5cHRpb24sIHNp Z25pbmcgYW5kIE1lc3NhZ2UNCiAgIEF1dGhlbnRpY2F0aW9uIENvZGUgb3BlcmF0aW9ucywgYW5k IHRvIGVmZmljaWVudGx5IGVuY29kZSB0aGUgcmVzdWx0DQogICBhcyBhIENPU0Ugb2JqZWN0LiAg SW4gcGFydGljdWxhciwgT1NDT1JFIHRha2VzIGFzIGlucHV0IGFuDQogICB1bnByb3RlY3RlZCBD b0FQIG1lc3NhZ2UgYW5kIHRyYW5zZm9ybXMgaXQgaW50byBhIHByb3RlY3RlZCBDb0FQDQogICBt ZXNzYWdlLCBieSB1c2luZyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gQWxnb3JpdGhtcyB3aXRo IEFkZGl0aW9uYWwNCiAgIERhdGEgKEFFQUQpLg0KDQogICBPU0NPUkUgbWFrZXMgaXQgcG9zc2li bGUgdG8gc2VsZWN0aXZlbHkgcHJvdGVjdCBkaWZmZXJlbnQgcGFydHMgb2YgYQ0KICAgQ29BUCBt ZXNzYWdlIGluIGRpZmZlcmVudCB3YXlzLCBzbyBzdGlsbCBhbGxvd2luZyBpbnRlcm1lZGlhcmll cw0KICAgKGUuZy4sIENvQVAgcHJveGllcykgdG8gcGVyZm9ybSB0aGVpciBpbnRlbmRlZCBmdW50 aW9uYWxpdGllcy4gIFRoYXQNCiAgIGlzLCBzb21lIG1lc3NhZ2UgcGFydHMgYXJlIGVuY3J5cHRl ZCBhbmQgaW50ZWdyaXR5IHByb3RlY3RlZDsgb3RoZXINCiAgIHBhcnRzIG9ubHkgaW50ZWdyaXR5 IHByb3RlY3RlZCB0byBiZSBhY2Nlc3NpYmxlIHRvLCBidXQgbm90DQogICBtb2RpZmlhYmxlIGJ5 LCBwcm94aWVzOyBhbmQgc29tZSBwYXJ0cyBhcmUga2VwdCBhcyBwbGFpbiBjb250ZW50IHRvDQog ICBiZSBib3RoIGFjY2Vzc2libGUgdG8gYW5kIG1vZGlmaWFibGUgYnkgcHJveGllcy4gIFN1Y2gg ZGlmZmVyZW5jZXMNCiAgIGVzcGVjaWFsbHkgY29uY2VybiB0aGUgQ29BUCBvcHRpb25zIGluY2x1 ZGVkIGluIHRoZSB1bnByb3RlY3RlZA0KICAgbWVzc2FnZS4NCg0KICAgR3JvdXAgT1NDT1JFIFtJ LUQuaWV0Zi1jb3JlLW9zY29yZS1ncm91cGNvbW1dIGJ1aWxkcyBvbiBPU0NPUkUsIGFuZA0KICAg cHJvdmlkZXMgZW5kLXRvLWVuZCBzZWN1cml0eSBvZiBDb0FQIG1lc3NhZ2VzIGV4Y2hhbmdlZCBi ZXR3ZWVuDQogICBtZW1iZXJzIG9mIGFuIE9TQ09SRSBncm91cCwgd2hpbGUgZnVsZmlsbGluZyB0 aGUgc2FtZSBzZWN1cml0eQ0KICAgcmVxdWlyZW1lbnRzLg0KDQogICBJbiBwYXJ0aWN1bGFyLCBH cm91cCBPU0NPUkUgcHJvdGVjdHMgQ29BUCByZXF1ZXN0cyBzZW50IG92ZXIgSVANCiAgIG11bHRp Y2FzdCBieSBhIENvQVAgY2xpZW50LCBhcyB3ZWxsIGFzIG11bHRpcGxlIGNvcnJlc3BvbmRpbmcg Q29BUA0KICAgcmVzcG9uc2VzIHNlbnQgb3ZlciBJUCB1bmljYXN0IGJ5IGRpZmZlcmVudCBDb0FQ IHNlcnZlcnMuICBIb3dldmVyLA0KICAgdGhlIHNhbWUga2V5aW5nIG1hdGVyaWFsIGNhbiBhbHNv IGJlIHVzZWQgdG8gcHJvdGVjdCBDb0FQIHJlcXVlc3RzDQogICBzZW50IG92ZXIgSVAgdW5pY2Fz dCB0byBhIHNpbmdsZSBDb0FQIHNlcnZlciBpbiB0aGUgT1NDT1JFIGdyb3VwLCBhcw0KICAgd2Vs bCBhcyB0aGUgY29ycmVzcG9uZGluZyByZXNwb25zZXMuDQoNCiAgIEdyb3VwIE9TQ09SRSB1c2Vz IGRpZ2l0YWwgc2lnbmF0dXJlcyB0byBlbnN1cmUgc291cmNlIGF1dGhlbnRpY2F0aW9uDQogICBv ZiBhbGwgbWVzc2FnZXMgZXhjaGFuZ2VkIHdpdGhpbiB0aGUgT1NDT1JFIGdyb3VwLiAgVGhhdCBp cywgc2VuZGVyDQogICBkZXZpY2VzIHNpZ24gdGhlaXIgb3V0Z29pbmcgbWVzc2FnZXMgYnkgbWVh bnMgb2YgdGhlaXIgb3duIHByaXZhdGUNCiAgIGtleSwgYW5kIGVtYmVkIHRoZSBzaWduYXR1cmUg aW4gdGhlIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2UuDQoNCiAgIEEgR3JvdXAgTWFuYWdlciBpcyBy ZXNwb25zaWJsZSBmb3Igb25lIG9yIG11bHRpcGxlIE9TQ09SRSBncm91cHMuICBJbg0KICAgcGFy dGljdWxhciwgdGhlIEdyb3VwIE1hbmFnZXIgYWN0cyBhcyByZXBvc2l0b3J5IG9mIHB1YmxpYyBr ZXlzIG9mDQogICBncm91cCBtZW1iZXJzOyBtYW5hZ2VzLCByZW5ld3MgYW5kIHByb3ZpZGVzIGtl eWluZyBtYXRlcmlhbCBpbiB0aGUNCiAgIGdyb3VwOyBhbmQgZHJpdmVzIHRoZSBqb2luIHByb2Nl c3MgZm9yIG5ldyBncm91cCBtZW1iZXJzLg0KDQogICBBcyBSRUNPTU1FTkRFRCBpbiBbSS1ELmll dGYtY29yZS1vc2NvcmUtZ3JvdXBjb21tXSwgYSBDb0FQIGVuZHBvaW50DQogICBjYW4gam9pbiBh biBPU0NPUkUgZ3JvdXAgYnkgdXNpbmcgdGhlIG1ldGhvZCBkZXNjcmliZWQgaW4NCiAgIFtJLUQu aWV0Zi1hY2Uta2V5LWdyb3VwY29tbS1vc2NvcmVdIGFuZCBiYXNlZCBvbiB0aGUgQUNFIGZyYW1l d29yaw0KICAgZm9yIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGluIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cw0KICAgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uDQoNCiAgIEEg Q29BUCBlbmRwb2ludCBjYW4gZGlzY292ZXIgT1NDT1JFIGdyb3VwcyBhbmQgcmV0cmlldmUgaW5m b3JtYXRpb24NCiAgIHRvIGpvaW4gdGhlbSB0aHJvdWdoIHRoZWlyIEdyb3VwIE1hbmFnZXJzIGJ5 IHVzaW5nIHRoZSBtZXRob2QNCiAgIGRlc2NyaWJlZCBpbiBbSS1ELnRpbG9jYS1jb3JlLW9zY29y ZS1kaXNjb3ZlcnldIGFuZCBiYXNlZCBvbiB0aGUgQ29SRQ0KICAgUmVzb3VyY2UgRGlyZWN0b3J5 IFtJLUQuaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeV0uDQoNCiAgIElmIHNlY3VyaXR5IGlz IHJlcXVpcmVkLCBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24gYXMgZGVzY3JpYmVkIGluDQogICB0 aGlzIHNwZWNpZmljYXRpb24gTVVTVCB1c2UgR3JvdXAgT1NDT1JFLiAgSW4gcGFydGljdWxhciwg YSBDb0FQDQogICBncm91cCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjEgYW5kIHVzaW5nIHNl Y3VyZSBncm91cA0KICAgY29tbXVuaWNhdGlvbiBpcyBhc3NvY2lhdGVkIHRvIGFuIE9TQ09SRSBn cm91cCwgd2hpY2ggaW5jbHVkZXM6DQoNCiAgIG8gIEFsbCBtZW1iZXJzIG9mIHRoZSBDb0FQIGdy b3VwLCBpLmUuIHRoZSBDb0FQIGVuZHBvaW50cyBjb25maWd1cmVkDQogICAgICAoYWxzbykgYXMg Q29BUCBzZXJ2ZXJzIGFuZCBsaXN0ZW5pbmcgdG8gdGhlIGdyb3VwJ3MgbXVsdGljYXN0IElQDQog ICAgICBhZGRyZXNzLg0KDQogICBvICBBbGwgZnVydGhlciBDb0FQIGVuZHBvaW50cyBjb25maWd1 cmVkIG9ubHkgYXMgQ29BUCBjbGllbnRzLCB0aGF0DQogICAgICBzZW5kIChtdWx0aWNhc3QpIENv QVAgcmVxdWVzdHMgdG8gdGhlIENvQVAgZ3JvdXAuDQoNCjUuMS4gIFNlY3VyZSBHcm91cCBNYWlu dGVuYW5jZQ0KDQogICBBZGRpdGlvbmFsIGtleSBtYW5hZ2VtZW50IG9wZXJhdGlvbnMgb24gdGhl IE9TQ09SRSBncm91cCBhcmUNCiAgIHJlcXVpcmVkLCBkZXBlbmRpbmcgYWxzbyBvbiB0aGUgc2Vj dXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZQ0KICAgYXBwbGljYXRpb24gKHNlZSBTZWN0aW9uIDYu MikuICBUaGF0IGlzOg0KDQogICBvICBBZGRpbmcgbmV3IG1lbWJlcnMgdG8gYSBDb0FQIGdyb3Vw IG9yIGVuYWJsaW5nIG5ldyBjbGllbnQtb25seQ0KICAgICAgZW5kcG9pbnRzIHRvIGludGVyYWN0 IHdpdGggdGhhdCBncm91cCByZXF1aXJlIGFsc28gdGhhdCBlYWNoIG9mDQogICAgICBzdWNoIG1l bWJlcnMvZW5kcG9pbnRzIGpvaW4gdGhlIGNvcnJlc3BvbmRpbmcgT1NDT1JFIGdyb3VwLiAgQnkN CiAgICAgIGRvaW5nIHNvLCB0aGV5IGFyZSBzZWN1cmVseSBwcm92aWRlZCB3aXRoIHRoZSBuZWNl c3NhcnkNCiAgICAgIGNyeXB0b2dyYXBoaWMgbWF0ZXJpYWwuICBJbiBjYXNlIGJhY2t3YXJkIHNl Y3VyaXR5IGlzIG5lZWRlZCwgdGhpcw0KICAgICAgYWxzbyByZXF1aXJlcyB0byBmaXJzdCByZW5l dyBzdWNoIG1hdGVyaWFsIGFuZCBkaXN0cmlidXRlIGl0IHRvDQogICAgICB0aGUgY3VycmVudCBt ZW1iZXJzL2VuZHBvaW50cywgYmVmb3JlIG5ldyBvbmVzIGFyZSBhZGRlZCBhbmQgam9pbg0KICAg ICAgdGhlIE9TQ09SRSBncm91cC4NCg0KICAgbyAgSW4gY2FzZSBmb3J3YXJkIHNlY3VyaXR5IGlz IG5lZWRlZCwgcmVtb3ZpbmcgbWVtYmVycyBmcm9tIGEgQ29BUA0KICAgICAgZ3JvdXAgb3Igc3Rv cHBpbmcgY2xpZW50LW9ubHkgZW5kcG9pbnRzIGZyb20gaW50ZXJhY3Rpbmcgd2l0aCB0aGF0DQog ICAgICBncm91cCByZXF1aXJlcyByZW1vdmluZyBzdWNoIG1lbWJlcnMvZW5kcG9pbnRzIGZyb20g dGhlDQogICAgICBjb3JyZXNwb25kaW5nIE9TQ09SRSBncm91cC4gIFRvIHRoaXMgZW5kLCBuZXcg Y3J5cHRvZ3JhcGhpYw0KICAgICAgbWF0ZXJpYWwgaXMgZ2VuZXJhdGVkIGFuZCBzZWN1cmVseSBk aXN0cmlidXRlZCBvbmx5IHRvIHRoZQ0KICAgICAgcmVtYWluaW5nIG1lbWJlcnMvZW5kcG9pbnRz LiAgVGhpcyBlbnN1cmVzIHRoYXQgb25seSB0aGUgbWVtYmVycy8NCiAgICAgIGVuZHBvaW50cyBp bnRlbmRlZCB0byByZW1haW4gYXJlIGFibGUgdG8gY29udGludWUgcGFydGljaXBhdGluZyB0bw0K ICAgICAgc2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24sIHdoaWxlIHRoZSBldmljdGVkIG9uZXMg YXJlIG5vdCBhYmxlDQogICAgICB0by4NCg0KICAgVGhlIGtleSBtYW5hZ2VtZW50IG9wZXJhdGlv bnMgbWVudGlvbmVkIGFib3ZlIGFyZSBlbnRydXN0ZWQgdG8gdGhlDQogICBHcm91cCBNYW5hZ2Vy IHJlc3BvbnNpYmxlIGZvciB0aGUgT1NDT1JFIGdyb3VwDQogICBbSS1ELmlldGYtY29yZS1vc2Nv cmUtZ3JvdXBjb21tXSwgYW5kIGl0IGlzIFJFQ09NTUVOREVEIHRvIHBlcmZvcm0NCiAgIHRoZW0g YWNjb3JkaW5nIHRvIHRoZSBhcHByb2FjaCBkZXNjcmliZWQgaW4NCiAgIFtJLUQuaWV0Zi1hY2Ut a2V5LWdyb3VwY29tbS1vc2NvcmVdLg0KDQo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0K ICAgVGhpcyBzZWN0aW9uIHByb3ZpZGVzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBDb0FQ IGdyb3VwDQogICBjb21tdW5pY2F0aW9uIHVzaW5nIElQIG11bHRpY2FzdC4NCg0KNi4xLiAgQ29B UCBOb1NlYyBNb2RlDQoNCiAgIENvQVAgZ3JvdXAgY29tbXVuaWNhdGlvbiwgaWYgbm90IHByb3Rl Y3RlZCwgaXMgdnVsbmVyYWJsZSB0byBhbGwgdGhlDQogICBhdHRhY2tzIG1lbnRpb25lZCBpbiBT ZWN0aW9uIDExIG9mIFtSRkM3MjUyXSBmb3IgSVAgbXVsdGljYXN0Lg0KDQogICBUaHVzLCBmb3Ig c2Vuc2l0aXZlIGFuZCBtaXNzaW9uLWNyaXRpY2FsIGFwcGxpY2F0aW9ucyAoZS5nLiwgaGVhbHRo DQogICBtb25pdG9yaW5nIHN5c3RlbXMgYW5kIGFsYXJtIG1vbml0b3Jpbmcgc3lzdGVtcyksIGl0 IGlzIE5PVA0KICAgUkVDT01NRU5ERUQgdG8gZGVwbG95IENvQVAgZ3JvdXAgY29tbXVuaWNhdGlv biBpbiBOb1NlYyBtb2RlLg0KDQogICBXaXRob3V0IGFwcGxpY2F0aW9uLWxheWVyIHNlY3VyaXR5 LCBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24gU0hPVUxEDQogICBvbmx5IGJlIGRlcGxveWVkIGlu IG5vbi1jcml0aWNhbCBhcHBsaWNhdGlvbnMgKGUuZy4sIHJlYWQtb25seQ0KICAgdGVtcGVyYXR1 cmUgc2Vuc29ycyB3aGVyZSB0aGUgY2xpZW50IHJlYWRpbmcgb3V0IHRoZSB2YWx1ZXMgZG9lcyBu b3QNCiAgIHVzZSB0aGUgZGF0YSB0byBjb250cm9sIGFjdHVhdG9ycyBvciB0byBiYXNlIGFuIGlt cG9ydGFudCBkZWNpc2lvbg0KICAgb24pLg0KDQojIE5vdCBzdXJlIHRoaXMgcHJvdmlkZXMgdGhl IHJpZ2h0IGNyaXRlcmlhIC8gbWFrZXMgYSBnb29kIGV4YW1wbGUgZm9yDQojIGRlY2lkaW5nIHdo ZXRoZXIgb3Igbm90IHRoZSB1c2Ugb2YgTm9TZWMgaXMgYXBwcm9wcmlhdGUuICBUaGlzIHNvdW5k cw0KIyBsaWtlIHdlIGFyZSBtaXNzaW5nIGEgUHJpdmFjeSBDb25zaWRlcmF0aW9uIHNlY3Rpb24/ DQoNCiAgIERpc2NvdmVyeSBvZiBkZXZpY2VzIGFuZCByZXNvdXJjZXMgaXMgYSB0eXBpY2FsIHVz ZSBjYXNlIHdoZXJlIE5vU2VjDQogICBtb2RlIGlzIGFwcGxpZWQsIHNpbmNlIHRoZSBkZXZpY2Vz IGludm9sdmVkIGRvIG5vdCBoYXZlIHlldA0KICAgY29uZmlndXJlZCBhbnkgbXV0dWFsIHNlY3Vy aXR5IHJlbGF0aW9ucyBhdCB0aGUgdGltZSB0aGUgZGlzY292ZXJ5DQogICB0YWtlcyBwbGFjZS4N Cg0KNi4yLiAgR3JvdXAgT1NDT1JFDQoNCiAgIEdyb3VwIE9TQ09SRSBwcm92aWRlcyBlbmQtdG8t ZW5kIGFwcGxpY2F0aW9uLWxldmVsIHNlY3VyaXR5LiAgVGhpcw0KICAgaGFzIG1hbnkgZGVzaXJh YmxlIHByb3BlcnRpZXMsIGluY2x1ZGluZyBtYWludGFpbmluZyBzZWN1cml0eQ0KICAgcHJvcGVy dGllcyB3aGlsZSBmb3J3YXJkaW5nIHRyYWZmaWMgdGhyb3VnaCBpbnRlcm1lZGlhcmllcyAocHJv eGllcykuDQogICBBcHBsaWNhdGlvbi1sZXZlbCBzZWN1cml0eSBhbHNvIHRlbmRzIHRvIG1vcmUg Y2xlYW5seSBzZXBhcmF0ZQ0KICAgc2VjdXJpdHkgZnJvbSB0aGUgZHluYW1pY3Mgb2YgZ3JvdXAg bWVtYmVyc2hpcCAoZS5nLiwgdGhlIHByb2JsZW0gb2YNCiAgIGRpc3RyaWJ1dGluZyBzZWN1cml0 eSBrZXlzIGFjcm9zcyBsYXJnZSBncm91cHMgd2l0aCBtYW55IG1lbWJlcnMgdGhhdA0KICAgY29t ZSBhbmQgZ28pLg0KDQogICBGb3Igc2Vuc2l0aXZlIGFuZCBtaXNzaW9uLWNyaXRpY2FsIGFwcGxp Y2F0aW9ucywgQ29BUCBncm91cA0KICAgY29tbXVuaWNhdGlvbiBNVVNUIGJlIHByb3RlY3RlZCBi eSB1c2luZyBHcm91cCBPU0NPUkUgYXMgc3BlY2lmaWVkIGluDQogICBbSS1ELmlldGYtY29yZS1v c2NvcmUtZ3JvdXBjb21tXS4gIFRoZSBzYW1lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQogICBm cm9tIFNlY3Rpb24gOCBvZiBbSS1ELmlldGYtY29yZS1vc2NvcmUtZ3JvdXBjb21tXSBob2xkIGZv ciB0aGlzDQogICBzcGVjaWZpY2F0aW9uLg0KDQogICBBIGtleSBtYW5hZ2VtZW50IHNjaGVtZSBm b3Igc2VjdXJlIHJldm9jYXRpb24gYW5kIHJlbmV3YWwgb2YgZ3JvdXANCiAgIGtleWluZyBtYXRl cmlhbCBzaG91bGQgYmUgYWRvcHRlZCBpbiBPU0NPUkUgZ3JvdXBzLiAgQWxzbywgdGhlIGtleQ0K ICAgbWFuYWdlbWVudCBzY2hlbWUgc2hvdWxkIHByZXNlcnZlIGJhY2t3YXJkIGFuZCBmb3J3YXJk IHNlY3VyaXR5IGluDQogICB0aGUgT1NDT1JFIGdyb3VwLCBpZiB0aGUgYXBwbGljYXRpb24gcmVx dWlyZXMgc28gKHNlZSBTZWN0aW9uIDIuMSBvZg0KICAgW0ktRC5pZXRmLWNvcmUtb3Njb3JlLWdy b3VwY29tbV0pLg0KDQogICBDb0FQIGVuZHBvaW50cyB1c2luZyBHcm91cCBPU0NPUkUgY291bnRl cnNpZ24gdGhlaXIgb3V0Z29pbmcNCiAgIG1lc3NhZ2VzLCBieSBtZWFucyBvZiB0aGUgY291bnRl cnNpZ25hdHVyZSBhbGdvcml0aG0gdXNlZCBpbiB0aGUNCiAgIE9TQ09SRSBncm91cC4gIFRoaXMg ZW5zdXJlcyBzb3VyY2UgYXV0aGVudGljYXRpb24gb2YgbWVzc2FnZXMNCiAgIGV4Y2hhbmdlZCBi eSBDb0FQIGVuZHBvaW50cyB0aHJvdWdoIENvQVAgZ3JvdXAgY29tbXVuaWNhdGlvbi4gIEluDQog ICBmYWN0LCBpdCBhbGxvd3MgdG8gdmVyaWZ5IHRoYXQgYSByZWNlaXZlZCBtZXNzYWdlIGhhcyBh Y3R1YWxseSBiZWVuDQogICBvcmlnaW5hdGVkIGJ5IGEgc3BlY2lmaWMgYW5kIGlkZW50aWZpZWQg bWVtYmVyIG9mIHRoZSBPU0NPUkUgZ3JvdXAuDQoNCiAgIEFwcGVuZGl4IEYgb2YgW0ktRC5pZXRm LWNvcmUtb3Njb3JlLWdyb3VwY29tbV0gZGlzY3Vzc2VzIGEgbnVtYmVyIG9mDQogICBjYXNlcyB3 aGVyZSBhIHJlY2lwaWVudCBDb0FQIGVuZHBvaW50IG1heSBza2lwIHRoZSB2ZXJpZmljYXRpb24g b2YNCiAgIGNvdW50ZXJzaWduYXR1cmVzLCBwb3NzaWJseSBvbiBhIHBlci1tZXNzYWdlIGJhc2lz LiAgSG93ZXZlciwgdGhpcyBpcw0KICAgTk9UIFJFQ09NTUVOREVELiAgVGhhdCBpcywgYSBDb0FQ IGVuZHBvaW50IHJlY2VpdmluZyBhIG1lc3NhZ2UNCiAgIHNlY3VyZWQgd2l0aCBHcm91cCBPU0NP UkUgU0hPVUxEIGFsd2F5cyB2ZXJpZnkgdGhlIGNvdW50ZXJzaWduYXR1cmUuDQoNCiAgIEdyb3Vw IE9TQ09SRSBhZGRyZXNzZXMgc2VjdXJpdHkgYXR0YWNrcyBtZW50aW9uZWQgaW4gU2VjdGlvbnMN CiAgIDExLjItMTEuNiBvZiBbUkZDNzI1Ml0sIHdpdGggcGFydGljdWxhciByZWZlcmVuY2UgdG8g dGhlaXIgZXhlY3V0aW9uDQogICBvdmVyIElQIG11bHRpY2FzdC4gIFRoYXQgaXM6IGl0IHByb3Zp ZGVzIGNvbmZpZGVudGlhbGl0eSBhbmQNCiAgIGludGVncml0eSBvZiByZXF1ZXN0L3Jlc3BvbnNl IGRhdGEgdGhyb3VnaCBwcm94aWVzIGFsc28gaW4gbXVsdGljYXN0DQogICBzZXR0aW5nczsgaXQg cHJldmVudHMgYW1wbGlmaWNhdGlvbiBhdHRhY2tzIGNhcnJpZWQgb3V0IHRocm91Z2gNCiAgIHJl c3BvbnNlcyB0byBpbmplY3RlZCByZXF1ZXN0cyBvdmVyIElQIG11bHRpY2FzdDsgaXQgbGltaXRz IHRoZQ0KICAgaW1wYWN0IG9mIGF0dGFja3MgYmFzZWQgb24gSVAgc3Bvb2Zpbmc7IGl0IHByZXZl bnRzIGNyb3NzLXByb3RvY29sDQogICBhdHRhY2tzOyBpdCBkZXJpdmVzIHRoZSBncm91cCBrZXkg bWF0ZXJpYWwgZnJvbSwgYW1vbmcgb3RoZXIgdGhpbmdzLA0KICAgYSBNYXN0ZXIgU2VjcmV0IHNl Y3VyZWx5IGdlbmVyYXRlZCBieSB0aGUgR3JvdXAgTWFuYWdlciBhbmQgcHJvdmlkZWQNCiAgIHRv IENvQVAgZW5kcG9pbnRzIHVwb24gdGhlaXIgam9pbmluZyBvZiB0aGUgT1NDT1JFIGdyb3VwOw0K ICAgY291bnRlcnNpZ25hdHVyZXMgYXNzdXJlIHNvdXJjZSBhdXRoZW50aWNhdGlvbiBvZiBleGNo YW5nZWQgQ29BUA0KICAgbWVzc2FnZXMsIGFuZCBoZW5jZSBwcmV2ZW50IGEgZ3JvdXAgbWVtYmVy IHRvIGJlIHVzZWQgZm9yIHN1YnZlcnRpbmcNCiAgIHNlY3VyaXR5IGluIHRoZSB3aG9sZSBncm91 cC4NCg0KNi4zLiAgNkxvV1BBTg0KDQogICBFZGl0b3IgTm90ZSwgVEJEOiBpZGVudGlmeSBpZiBt dWx0aS1mcmFnbWVudCBtdWx0aWNhc3QgcmVxdWVzdHMgaGF2ZQ0KICAgYSBuZWdhdGl2ZSBlZmZl Y3Qgb24gc2VjdXJpdHkgYW5kLCBpZiBzbywgYWR2aWNlIGhlcmUgb24gdHJ5aW5nIHRvDQogICBh dm9pZCBzdWNoIHJlcXVlc3RzLiAgQWxzbyBhbiBhdHRhY2tlciBjb3VsZCB1c2UgbXVsdGktZnJh Z21lbnQgdG8NCiAgIG9jY3VweSByZWFzc2VtYmx5IGJ1ZmZlcnMgb2YgbWFueSByb3V0aW5nIDZM b1dQQU4gbm9kZXMuDQoNCjYuNC4gIFdpLUZpDQoNCiAgIFRCRDogV2ktRmkgc3BlY2lmaWMgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnM7IHNlZSBhbHNvIFNlY3Rpb24gNS4zLjENCiAgIG9mIFtSRkM3 MzkwXS4NCg0KNi41LiAgTW9uaXRvcmluZw0KDQogICBUQkQ6IHNlZSBTZWN0aW9uIDUuNCBvZiBb UkZDNzM5MF0uDQoNCjcuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQg aGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuDQoNCjguICBSZWZlcmVuY2VzDQoNCjguMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0NCiAg ICAgICAgICAgICAgU2VsYW5kZXIsIEcuLCBNYXR0c3NvbiwgSi4sIFBhbG9tYmluaSwgRi4sIGFu ZCBMLiBTZWl0eiwNCiAgICAgICAgICAgICAgIk9iamVjdCBTZWN1cml0eSBmb3IgQ29uc3RyYWlu ZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMNCiAgICAgICAgICAgICAgKE9TQ09SRSkiLCBkcmFmdC1p ZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTE2ICh3b3JrIGluDQogICAgICAgICAgICAgIHByb2dy ZXNzKSwgTWFyY2ggMjAxOS4NCg0KICAgW0ktRC5pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbV0N CiAgICAgICAgICAgICAgVGlsb2NhLCBNLiwgU2VsYW5kZXIsIEcuLCBQYWxvbWJpbmksIEYuLCBh bmQgSi4gUGFyaywNCiAgICAgICAgICAgICAgIkdyb3VwIE9TQ09SRSAtIFNlY3VyZSBHcm91cCBD b21tdW5pY2F0aW9uIGZvciBDb0FQIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jb3JlLW9z Y29yZS1ncm91cGNvbW0tMDQgKHdvcmsgaW4gcHJvZ3Jlc3MpLA0KICAgICAgICAgICAgICBNYXJj aCAyMDE5Lg0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBC Q1AgMTQsIFJGQyAyMTE5LA0KICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFy Y2ggMTk5NywNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjMjExOT4uDQoNCiAgIFtSRkM2NjkwXSAgU2hlbGJ5LCBaLiwgIkNvbnN0cmFpbmVkIFJFU1Rm dWwgRW52aXJvbm1lbnRzIChDb1JFKSBMaW5rDQogICAgICAgICAgICAgIEZvcm1hdCIsIFJGQyA2 NjkwLCBET0kgMTAuMTc0ODcvUkZDNjY5MCwgQXVndXN0IDIwMTIsDQogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzY2OTA+Lg0KDQogICBbUkZDNzA0OV0g IEJvcm1hbm4sIEMuIGFuZCBQLiBIb2ZmbWFuLCAiQ29uY2lzZSBCaW5hcnkgT2JqZWN0DQogICAg ICAgICAgICAgIFJlcHJlc2VudGF0aW9uIChDQk9SKSIsIFJGQyA3MDQ5LCBET0kgMTAuMTc0ODcv UkZDNzA0OSwNCiAgICAgICAgICAgICAgT2N0b2JlciAyMDEzLCA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM3MDQ5Pi4NCg0KICAgW1JGQzcyNTJdICBTaGVsYnksIFouLCBIYXJ0 a2UsIEsuLCBhbmQgQy4gQm9ybWFubiwgIlRoZSBDb25zdHJhaW5lZA0KICAgICAgICAgICAgICBB cHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkiLCBSRkMgNzI1MiwNCiAgICAgICAgICAgICAgRE9J IDEwLjE3NDg3L1JGQzcyNTIsIEp1bmUgMjAxNCwNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzI1Mj4uDQoNCiAgIFtSRkM3NjQxXSAgSGFydGtlLCBL LiwgIk9ic2VydmluZyBSZXNvdXJjZXMgaW4gdGhlIENvbnN0cmFpbmVkDQogICAgICAgICAgICAg IEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSIsIFJGQyA3NjQxLA0KICAgICAgICAgICAgICBE T0kgMTAuMTc0ODcvUkZDNzY0MSwgU2VwdGVtYmVyIDIwMTUsDQogICAgICAgICAgICAgIDxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2NDE+Lg0KICAgW1JGQzc5NTldICBCb3Jt YW5uLCBDLiBhbmQgWi4gU2hlbGJ5LCBFZC4sICJCbG9jay1XaXNlIFRyYW5zZmVycyBpbg0KICAg ICAgICAgICAgICB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIiwg UkZDIDc5NTksDQogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3OTU5LCBBdWd1c3QgMjAx NiwNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzk1 OT4uDQoNCiAgIFtSRkM4MTUyXSAgU2NoYWFkLCBKLiwgIkNCT1IgT2JqZWN0IFNpZ25pbmcgYW5k IEVuY3J5cHRpb24gKENPU0UpIiwNCiAgICAgICAgICAgICAgUkZDIDgxNTIsIERPSSAxMC4xNzQ4 Ny9SRkM4MTUyLCBKdWx5IDIwMTcsDQogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRp dG9yLm9yZy9pbmZvL3JmYzgxNTI+Lg0KDQogICBbUkZDODE3NF0gIExlaWJhLCBCLiwgIkFtYmln dWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJGQw0KICAgICAgICAgICAgICAyMTE5 IEtleSBXb3JkcyIsIEJDUCAxNCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0LA0KICAg ICAgICAgICAgICBNYXkgMjAxNywgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj ODE3ND4uDQoNCiAgIFtSRkM4MzIzXSAgQm9ybWFubiwgQy4sIExlbWF5LCBTLiwgVHNjaG9mZW5p ZywgSC4sIEhhcnRrZSwgSy4sDQogICAgICAgICAgICAgIFNpbHZlcmFqYW4sIEIuLCBhbmQgQi4g UmF5bW9yLCBFZC4sICJDb0FQIChDb25zdHJhaW5lZA0KICAgICAgICAgICAgICBBcHBsaWNhdGlv biBQcm90b2NvbCkgb3ZlciBUQ1AsIFRMUywgYW5kIFdlYlNvY2tldHMiLA0KICAgICAgICAgICAg ICBSRkMgODMyMywgRE9JIDEwLjE3NDg3L1JGQzgzMjMsIEZlYnJ1YXJ5IDIwMTgsDQogICAgICAg ICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgzMjM+Lg0KDQo4LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtDYWxpZm9ybml1bV0NCiAgICAgICAgICAg ICAgRWNsaXBzZSBGb3VuZGF0aW9uLCAiRWNsaXBzZSBDYWxpZm9ybml1bSIsIE1hcmNoIDIwMTks DQogICAgICAgICAgICAgIDxodHRwczovL2dpdGh1Yi5jb20vZWNsaXBzZS9jYWxpZm9ybml1bS90 cmVlLzIuMC54Lw0KICAgICAgICAgICAgICBjYWxpZm9ybml1bS1jb3JlL3NyYy9tYWluL2phdmEv b3JnL2VjbGlwc2UvY2FsaWZvcm5pdW0vDQogICAgICAgICAgICAgIGNvcmU+Lg0KDQogICBbR28t T0NGXSAgIE9wZW4gQ29ubmVjdGl2aXR5IEZvdW5kYXRpb24gKE9DRiksICJJbXBsZW1lbnRhdGlv biBvZg0KICAgICAgICAgICAgICBDb0FQIFNlcnZlciAmIENsaWVudCBpbiBHbyIsIE1hcmNoIDIw MTksDQogICAgICAgICAgICAgIDxodHRwczovL2dpdGh1Yi5jb20vZ28tb2NmL2dvLWNvYXA+Lg0K DQogICBbSS1ELmlldGYtYWNlLWtleS1ncm91cGNvbW0tb3Njb3JlXQ0KICAgICAgICAgICAgICBU aWxvY2EsIE0uLCBQYXJrLCBKLiwgYW5kIEYuIFBhbG9tYmluaSwgIktleSBNYW5hZ2VtZW50DQog ICAgICAgICAgICAgIGZvciBPU0NPUkUgR3JvdXBzIGluIEFDRSIsIGRyYWZ0LWlldGYtYWNlLWtl eS1ncm91cGNvbW0tDQogICAgICAgICAgICAgIG9zY29yZS0wMSAod29yayBpbiBwcm9ncmVzcyks IE1hcmNoIDIwMTkuDQoNCiAgIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdDQogICAgICAgICAg ICAgIFNlaXR6LCBMLiwgU2VsYW5kZXIsIEcuLCBXYWhsc3Ryb2VtLCBFLiwgRXJkdG1hbiwgUy4s IGFuZA0KICAgICAgICAgICAgICBILiBUc2Nob2ZlbmlnLCAiQXV0aGVudGljYXRpb24gYW5kIEF1 dGhvcml6YXRpb24gZm9yDQogICAgICAgICAgICAgIENvbnN0cmFpbmVkIEVudmlyb25tZW50cyAo QUNFKSB1c2luZyB0aGUgT0F1dGggMi4wDQogICAgICAgICAgICAgIEZyYW1ld29yayAoQUNFLU9B dXRoKSIsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTIyDQogICAgICAgICAgICAgICh3b3Jr IGluIHByb2dyZXNzKSwgTWFyY2ggMjAxOS4NCg0KICAgW0ktRC5pZXRmLWNvcmUtcmVzb3VyY2Ut ZGlyZWN0b3J5XQ0KICAgICAgICAgICAgICBTaGVsYnksIFouLCBLb3N0ZXIsIE0uLCBCb3JtYW5u LCBDLiwgU3RvaywgUC4sIGFuZCBDLg0KICAgICAgICAgICAgICBBbXN1ZXNzLCAiQ29SRSBSZXNv dXJjZSBEaXJlY3RvcnkiLCBkcmFmdC1pZXRmLWNvcmUtDQogICAgICAgICAgICAgIHJlc291cmNl LWRpcmVjdG9yeS0xOSAod29yayBpbiBwcm9ncmVzcyksIEphbnVhcnkgMjAxOS4NCg0KICAgW0kt RC50aWxvY2EtY29yZS1vc2NvcmUtZGlzY292ZXJ5XQ0KICAgICAgICAgICAgICBUaWxvY2EsIE0u LCBBbXN1ZXNzLCBDLiwgYW5kIFAuIFN0b2ssICJEaXNjb3Zlcnkgb2YgT1NDT1JFDQogICAgICAg ICAgICAgIEdyb3VwcyB3aXRoIHRoZSBDb1JFIFJlc291cmNlIERpcmVjdG9yeSIsIGRyYWZ0LXRp bG9jYS0NCiAgICAgICAgICAgICAgY29yZS1vc2NvcmUtZGlzY292ZXJ5LTAxICh3b3JrIGluIHBy b2dyZXNzKSwgSmFudWFyeSAyMDE5Lg0KDQogICBbUkZDNzM0Nl0gIERyb21zLCBSLiwgIklQdjYg TXVsdGljYXN0IEFkZHJlc3MgU2NvcGVzIiwgUkZDIDczNDYsDQogICAgICAgICAgICAgIERPSSAx MC4xNzQ4Ny9SRkM3MzQ2LCBBdWd1c3QgMjAxNCwNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzM0Nj4uDQoNCiAgIFtSRkM3MzkwXSAgUmFobWFuLCBB LiwgRWQuIGFuZCBFLiBEaWprLCBFZC4sICJHcm91cCBDb21tdW5pY2F0aW9uIGZvcg0KICAgICAg ICAgICAgICB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIiwgUkZD IDczOTAsDQogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3MzkwLCBPY3RvYmVyIDIwMTQs DQogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzczOTA+ Lg0KDQogICBbUkZDNzk2N10gIEJoYXR0YWNoYXJ5eWEsIEEuLCBCYW5keW9wYWRoeWF5LCBTLiwg UGFsLCBBLiwgYW5kIFQuDQogICAgICAgICAgICAgIEJvc2UsICJDb25zdHJhaW5lZCBBcHBsaWNh dGlvbiBQcm90b2NvbCAoQ29BUCkgT3B0aW9uIGZvcg0KICAgICAgICAgICAgICBObyBTZXJ2ZXIg UmVzcG9uc2UiLCBSRkMgNzk2NywgRE9JIDEwLjE3NDg3L1JGQzc5NjcsDQogICAgICAgICAgICAg IEF1Z3VzdCAyMDE2LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3OTY3Pi4N Cg0KQWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQgaGFzIGJl ZW4gcGFydGx5IHN1cHBvcnRlZCBieSBWSU5OT1ZBIGFuZA0KICAgdGhlIENlbHRpYy1OZXh0IHBy b2plY3QgQ1JJVElTRUMuDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBFc2tvIERpamsNCiAg IElvVGNvbnN1bHRhbmN5Lm5sDQogICAtLS0tLS0tDQogICBVdHJlY2h0DQogICBUaGUgTmV0aGVy bGFuZHMNCg0KICAgRW1haWw6IGVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubA0KDQoNCiAgIENo b25nZ2FuZyBXYW5nDQogICBJbnRlckRpZ2l0YWwNCiAgIDEwMDEgRSBIZWN0b3IgU3QsIFN1aXRl IDMwMA0KICAgQ29uc2hvaG9ja2VuICBQQSAxOTQyOA0KICAgVW5pdGVkIFN0YXRlcw0KDQogICBF bWFpbDogQ2hvbmdnYW5nLldhbmdASW50ZXJEaWdpdGFsLmNvbQ0KDQoNCiAgIE1hcmNvIFRpbG9j YQ0KICAgUklTRSBBQg0KICAgSXNhZmpvcmRzZ2F0YW4gMjINCiAgIEtpc3RhICBTRS0xNjQ0MCBT dG9ja2hvbG0NCiAgIFN3ZWRlbg0KDQogICBFbWFpbDogbWFyY28udGlsb2NhQHJpLnNlDQoNCnZp bTogdGV4dHdpZHRoPTcyOg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo= From nobody Fri Jun 21 15:47:17 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577A1201CA; Fri, 21 Jun 2019 15:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 yvIlyHtM1ZWt; Fri, 21 Jun 2019 15:46:51 -0700 (PDT) Received: from smtp.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 E089C120136; Fri, 21 Jun 2019 15:46:50 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45Vv205tNvzyNl; Sat, 22 Jun 2019 00:46:48 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 582850006.279883-1de7b78efff3770d35256eae4114a31e Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 22 Jun 2019 00:46:48 +0200 Message-Id: <82A54967-C272-4037-A933-52718CCB6BC6@tzi.org> To: Ace Wg , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF105: 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, 21 Jun 2019 22:46:54 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF105. Remember that there is still quite some potential for changes. Conflicts that meet the eye: COSE/TEEP again! ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. (The poor TEEP people get to both start and end the week, too.) LAKE and LOOPS -- two BOFs at the same time? All times are EDT (Eastern Daylight Time) =3D=3D UTC -4 hours. (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 22, 2019 -- OMA/T2TRG Work Meeting - @ Ericsson Montreal Office (St-Laurent) SATURDAY/SUNDAY, March 23/24. 2019 -- Hackathon (including various interops) - Centre Ville -- Sun 1700-1900 Welcome Reception - Place du Canada -- Sun 1800-2000 Hot RFC Lightning Talks - Viger MONDAY, July 22, 2019 1000-1200 Morning Session I Laurier ART dispatch Dispatch WG Van Horne SEC *** teep Trusted Execution Environment = Provisioning WG 1330-1530 Afternoon Session I Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Place du Canada SEC secdispatch Security Dispatch WG Duluth TSV taps Transport Services WG 1550-1750 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG St-Catherine OPS v6ops IPv6 Operations WG Van Horne SEC *** lake Lightweight Authenticated Key Exchange = BOF Place du Canada TSV loops Local Optimizations on Path Segments BOF 1810-1910 Afternoon Session III Laurier TSV tsvwg Transport Area Working Group WG TUESDAY, July 23, 2019 1000-1200 Morning Session I St-Catherine ART *** cbor 1000-1130 Concise Binary Object = Representation Maintenance and Extensions WG St-Catherine INT ipwave 1130-1200 IP Wireless Access in = Vehicular Environments WG Notre Dame IRTF icnrg Information-Centric Networking Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG Van Horne SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG 1520-1650 Afternoon Session II Duluth INT intarea Internet Area Working Group WG Place du Canada IRTF irtfopen IRTF Open Meeting Van Horne SEC oauth Web Authorization Protocol WG 1710-1810 Afternoon Session III Duluth ART *** core Constrained RESTful Environments WG Laurier INT 6man IPv6 Maintenance WG Place du Canada SEC tls Transport Layer Security WG WEDNESDAY, July 24, 2019 1000-1200 Morning Session I Van Horne IRTF*** dinrg Decentralized Internet Infrastructure St-Catherine RTG *** roll Routing Over Low power and Lossy = networks WG Viger SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1530 Afternoon Session I Place du Canada GEN netrqmts IETF Meeting Network = Requirements BOF Laurier IRTF pearg Privacy Enhancements and Assessments = Research Group Viger IRTF*** t2trg Thing-to-Thing St-Catherine RTG bier Bit Indexed Explicit Replication WG Centre Ville RTG detnet Deterministic Networking WG 1550-1650 Afternoon Session II St-Catherine RTG babel Babel routing protocol WG Centre Ville RTG detnet Deterministic Networking WG Van Horne SEC *** rats Remote ATtestation ProcedureS WG THURSDAY, July 25, 2019 1000-1200 Morning Session I Centre Ville ART *** core Constrained RESTful Environments WG St-Catherine RTG rift Routing In Fat Trees WG Place du Canada SEC tls Transport Layer Security WG Laurier TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Viger IRTF coinrg Computing in the Network Proposed = Research Group Laurier IRTF panrg Path Aware Networking RG Place du Canada SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT 6man IPv6 Maintenance WG Place du Canada IRTF cfrg Crypto Forum St-Catherine SEC *** rats Remote ATtestation ProcedureS WG Centre Ville TSV tsvarea Transport Area Open Meeting 1740-1910 Afternoon Session III Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** ace Authentication and Authorization for = Constrained Environments WG Place du Canada SEC mls Messaging Layer Security WG Notre Dame TSV rmcat RTP Media Congestion Avoidance = Techniques WG FRIDAY, July 26, 2019 1000-1200 Morning Session I Notre Dame ART ice Interactive Connectivity Establishment = WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Laurier SEC mls Messaging Layer Security WG Duluth SEC oauth Web Authorization Protocol WG 1220-1350 Afternoon Session I Centre Ville SEC acme Automated Certificate Management = Environment WG Van Horne SEC *** cose CBOR Object Signing and Encryption WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG From nobody Mon Jun 24 04:22:16 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC012008B for ; Mon, 24 Jun 2019 04:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Vv_qzE14dlag for ; Mon, 24 Jun 2019 04:22:12 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE87120048 for ; Mon, 24 Jun 2019 04:22:12 -0700 (PDT) Received: from mail-qt1-f171.google.com ([209.85.160.171]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hfN32-0006FG-Rh; Mon, 24 Jun 2019 13:22:08 +0200 Received: by mail-qt1-f171.google.com with SMTP id a15so13997461qtn.7 for ; Mon, 24 Jun 2019 04:22:08 -0700 (PDT) X-Gm-Message-State: APjAAAUTqgPBeQhEHXQL3+bU61RlsHD194kexKwec1PnhRU/yLmR381p NrUVEc6ARUJy8YIhrUd0m6LpVPDGLNb576AR7sI= X-Google-Smtp-Source: APXvYqzgbOBFdAnhvZdn81QIfe/Xg0rJXnw0LjVGgwd6gGI1gorWBweIqqXORyAQjVzujPlQ4NLNKtYtnNAlLmdE/94= X-Received: by 2002:aed:39e7:: with SMTP id m94mr51068537qte.0.1561375327791; Mon, 24 Jun 2019 04:22:07 -0700 (PDT) MIME-Version: 1.0 References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> In-Reply-To: From: Klaus Hartke Date: Mon, 24 Jun 2019 13:21:31 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1561375332; 9ab4c01a; X-HE-SMSGID: 1hfN32-0006FG-Rh Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-se?= =?utf-8?q?nml-etch-03=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 11:22:15 -0000 I have performed a quick review of draft-ietf-core-senml-etch-03: 3.2. "For example, the following document could be given as (i)PATCH payload to change/set values of two SenML Records for the example in Section 1:" -- It would be nice if the example from section 1 was duplicated here and the removal of a record was shown. 5.1 "All IDs are assigned from the "IETF Review or IESG Approval" range." -- Remove this sentence. 5.1 "Table 1: CoAP Content-Format IDs" -- This table is missing the "Content-Coding" (f.k.a. "Encoding") column. General questions: * It seems the new data formats are supersets of the existing data formats. Also, it seems the same data format is used for fetching and patching data. Is this what we, as CoRE WG, recommend (1 media type for data, 1 media type for fetching and patching)? CoRAL is doing it differently at the moment [1]. Klaus [1] https://tools.ietf.org/html/draft-hartke-t2trg-coral-08#section-6.7 On Wed, 12 Jun 2019 at 15:10, Carsten Bormann wrote: > > It seems we have received no (zero, nada) responses to this. > We do need a few voices from people who have read it. > Please speak up if you did! > > It=E2=80=99s a short document, so you can read it right now as well: > https://tools.ietf.org/html/draft-ietf-core-senml-etch-03 > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > On Mar 11, 2019, at 23:40, Carsten Bormann wrote: > > > > On Mar 6, 2019, at 00:40, Ari Ker=C3=A4nen w= rote: > >> > >> If there are no further comments on these, I could merge the PR and > >> submit a new version. > > > > =E2=80=A6 which the authors did (see below). > > > > This starts a working group last call for draft-ietf-core-senml-etch-03= .txt, > > ending on > > > > 24:00 CET on Monday, March 25, 2019. > > > > Please start a new email thread for each major issue that will need > > discussion and make sure the subject line includes the draft name and > > some sort of name for the issue. (Minor issues such as typos can also > > be sent to the authors.) > > > > If you read the draft and think it looks fine, please send a one line > > email to the list or to the chairs letting us know that so we can get > > a feel of how broad the review has been. > > > > (To reviewers and authors:) If you are aware of any patent claims that > > might apply to systems that implement these drafts, please review BCP 7= 8 > > and BCP 79 and make any appropriate IPR declaration before the last-cal= l > > ends. If you are not sure whether you need to make a declaration or not= , > > please talk to the chairs and we will help. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > >> > >> Cheers, > >> Ari > >> > >> On 20/02/2019 17.00, Carsten Bormann wrote: > >>> In preparation for the impending working-group last call, I have > >>> reviewed draft-ietf-core-senml-etch-02.txt. Substantive comments are > >>> below; a set of small editorial comments is going to the authors in > >>> parallel. > >>> > >>> # Minor > >>> > >>> 1. The text of the draft does not contain an argument that the > >>> application of Patch Packs is idempotent. It probably should. > >>> > >>> 2. The text sometimes says "iPATCH" where it probably should be sayin= g > >>> "PATCH and iPATCH". This should be checked throughout. > >>> > >>> 3. The term "resource" is sometimes used in lieu of "subset of SenML > >>> records that, when resolved, match a given name". > >>> > >>> Gr=C3=BC=C3=9Fe, Carsten > >>> > >>> > >>> > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> https://www.ietf.org/mailman/listinfo/core > >>> > >> > >> > >> > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jun 24 06:29:29 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36F120294; Mon, 24 Jun 2019 06:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqZU_On8TLju; Mon, 24 Jun 2019 06:29:24 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50072.outbound.protection.outlook.com [40.107.5.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDF8120289; Mon, 24 Jun 2019 06:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EpqHCCkTQ3s6JfPjec9V557TCjuHCfCaZgOL4pjZGTI=; b=UqGbNR240ArHUER65eIXR4UzCRouuQWk/n4fs++BNCRmtZmYMjZlINXnlknO3WCabG9OmjI+Q9dv9DsJjOgvt42f1V0aTuq2TI97+JyOR31YG7kKAKxz8UYVPR+Je/Lvb8F4ncyVmFfOul7u25j9oBxhq6aveCoCuPCTYl6mWhg= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3356.eurprd07.prod.outlook.com (10.170.247.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.9; Mon, 24 Jun 2019 13:29:21 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d899:9e9d:c986:bf5b]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d899:9e9d:c986:bf5b%7]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 13:29:21 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "ace@ietf.org" , "core@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "lpwan@ietf.org" Thread-Topic: LAKE mailing list and BoF: a handshake protocol for OSCORE Thread-Index: AQHVKpDVTzRlaHKTNE6tB4u99gKRpA== Date: Mon, 24 Jun 2019 13:29:21 +0000 Message-ID: <7356D914-76F4-44B3-978C-AC69D870C29C@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d820f60-ba80-478d-34ad-08d6f8a7f79c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3356; x-ms-traffictypediagnostic: HE1PR07MB3356: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(346002)(376002)(396003)(189003)(199004)(6512007)(7736002)(5660300002)(71190400001)(85182001)(66066001)(66574012)(966005)(86362001)(2201001)(2906002)(71200400001)(85202003)(68736007)(478600001)(316002)(110136005)(33656002)(2501003)(58126008)(81156014)(6486002)(81166006)(186003)(8676002)(6306002)(6506007)(8936002)(53936002)(26005)(305945005)(6436002)(76116006)(66476007)(64756008)(66556008)(66446008)(2616005)(486006)(476003)(73956011)(99286004)(256004)(25786009)(36756003)(14444005)(14454004)(450100002)(6116002)(3846002)(102836004)(66946007)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3356; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K96t7wvomVZOFvk+5r48lWLo64lJxHELaz2zCBUnNloBcS7nocUzDGxM7oQiCEEaujE0NymboJWdCBAuFvgqrhAqT4aw439ip8QYrv0JFgWfmK9kQbGTEw2yrEbF+ZVTOBtEsjz9dLgK9S/XpV/1UVh2oZwbps1FEVxOBee9ZI+udQkY+9QATqBU+AN7ci7zmYLpzArEIwPBxACwSNMA6OECfOLpE0If9j3QupsH6v0KFPlrK0cy913K+2XYY2b9EuD1whHNdlvUdaD/cuu1bxpjDiGJsn2pMTXpKdlgPKMHSx9yZRdW31mKG9uzrOQEXUWB4D65ahhozZ2PYWaQ6h6saUD3utUxD7LxYtfpmkaLm/NPpv0YOQXVTxUJU2zLRd3fJ8DqIL14V/plxxp9DT+hZeCU6lVTfreFYZduzig= Content-Type: text/plain; charset="utf-8" Content-ID: <539EFDC5DBFDB24BA9D8A6674484E207@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d820f60-ba80-478d-34ad-08d6f8a7f79c X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 13:29:21.5441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: goran.selander@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3356 Archived-At: Subject: [core] LAKE mailing list and BoF: a handshake protocol for OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 13:29:27 -0000 DQpBcG9sb2dpZXMgZm9yIGNyb3NzLXBvc3RpbmcsIGJ1dCBpdCBzZWVtcyBzb21lIHBlb3BsZSBu b3QgZm9sbG93aW5nIHRoZSBTZWNkaXNwYXRjaCBsaXN0IGhhdmUgbWlzc2VkIHRoZSBjb25uZWN0 aW9uIGJldHdlZW4gRURIT0MgYW5kIHRoZSBuZXcgTEFLRSBtYWlsaW5nIGxpc3QgYW5kIEJvRi4N Cg0KQUNFLCBDb1JFLCA2VGlTQ0ggYW5kIExQV0FOIGFyZSBpZGVudGlmaWVkIGFzIHN0YWtlaG9s ZGVycyBpbiB0aGUgZHJhZnQgY2hhcnRlciBmb3IgdGhlIExBS0UgV0cgKHNlZSBbMV0gYmVsb3cp Lg0KDQpJZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gYSBoYW5kc2hha2UgcHJvdG9jb2wgZm9yIE9T Q09SRSwgam9pbiB0aGUgTEFLRSBtYWlsaW5nIGxpc3Qgbm93IGFuZCBhdHRlbmQgdGhlIExBS0Ug Qm9GIGF0IElFVEYgMTA1Lg0KDQpHw7ZyYW4NCg0KDQrvu79PbiAyMDE5LTA2LTE0LCAyMTozMiwg IlNlY2Rpc3BhdGNoIG9uIGJlaGFsZiBvZiBTdGVwaGVuIEZhcnJlbGwiIDxzZWNkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3 cm90ZToNCg0KICAgIA0KICAgIEhpeWEsDQogICAgDQogICAgVGhlcmUncyBhIG5ldyBtYWlsaW5n IGxpc3QgZm9yIGRpc2N1c3Npb24gb2YgbGlnaHR3ZWlnaHQNCiAgICBhdXRoZW50aWNhdGVkIGtl eSBleGNoYW5nZSwgd2hpY2ggaGFzIHByZXZpb3VzbHkgYmVlbg0KICAgIGRpc2N1c3NlZCBoZXJl IGluIHZhcmlvdXMgZWRob2MgdGhyZWFkcy4gVGhlcmUncyBhIEJvRg0KICAgIG9uIHRoaXMgdG9w aWMgcGxhbm5lZCBmb3IgSUVURiAxMDUgYXMgd2VsbC4gWzFdIFlvYXYgYW5kDQogICAgSSBhcmUg ZG93biB0byBjaGFpciB0aGF0IGF0IHRoZSBtb21lbnQuDQogICAgDQogICAgU28gaWYgeW91J3Jl IGludGVyZXN0ZWQgaW4gdGhhdCB0b3BpYyBwbGVhc2Ugc2lnbiB1cC4NCiAgICBXZSdsbCB0cnkg a2ljayBvZmYgc29tZSBwcmUtQm9GIGRpc2N1c3Npb24gb25jZSBwZW9wbGUNCiAgICBoYXZlIGhh ZCBhIGNoYW5jZSB0byBnZXQgb250byB0aGUgbmV3IGxpc3QgYW5kIFlvYXYNCiAgICBhbmQgSSBo YXZlIGhhZCBhIGNoYW5jZSB0byBjaGF0IGFib3V0IGl0IGFsbC4NCiAgICANCiAgICBDaGVlcnMs DQogICAgUy4NCiAgICANCiAgICBbMV0gaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3JnL2JvZi90 cmFjL3dpa2kjTEFLRQ0KDQogICAgDQogICAgDQogICAgLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3Nh Z2UgLS0tLS0tLS0NCiAgICBTdWJqZWN0OiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDogbGFrZQ0K ICAgIERhdGU6IEZyaSwgMTQgSnVuIDIwMTkgMTA6MTA6MzQgLTA3MDANCiAgICBGcm9tOiBJRVRG IFNlY3JldGFyaWF0IDxpZXRmLXNlY3JldGFyaWF0QGlldGYub3JnPg0KICAgIFJlcGx5LVRvOiBp ZXRmQGlldGYub3JnDQogICAgVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QgPGlldGYtYW5ub3Vu Y2VAaWV0Zi5vcmc+DQogICAgQ0M6IHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUsIHluaXIuaWV0 ZkBnbWFpbC5jb20NCiAgICANCiAgICBBIG5ldyBJRVRGIG5vbi13b3JraW5nIGdyb3VwIGVtYWls IGxpc3QgaGFzIGJlZW4gY3JlYXRlZC4NCiAgICANCiAgICBMaXN0IGFkZHJlc3M6IGxha2VAaWV0 Zi5vcmcNCiAgICBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv d3NlL2xha2UvDQogICAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xha2UNCg0KICAgIA0KICAgIFB1cnBvc2U6DQogICAgQ29uc3RyYWluZWQgZW52 aXJvbm1lbnRzIHVzaW5nIE9TQ09SRSBpbiBuZXR3b3JrIGVudmlyb25tZW50cyBzdWNoIGFzDQog ICAgTkItSW9ULCA2VGlTQ0gsIGFuZCBMb1JhV0FOIG5lZWQgYSAnbGlnaHR3ZWlnaHQnIGF1dGhl bnRpY2F0ZWQga2V5DQogICAgZXhjaGFuZ2UgKExBS0UpIHRoYXQgZW5hYmxlcyBmb3J3YXJkIHNl Y3VyaXR5LiAnTGlnaHR3ZWlnaHQnIHJlZmVycyB0bw0KICAgIHJlc291cmNlIGNvbnN1bXB0aW9u LCBtZWFzdXJlZCBieSBieXRlcyBvbiB0aGUgd2lyZSwgd2FsbC1jbG9jayB0aW1lIHRvDQogICAg Y29tcGxldGUsIG9yIHBvd2VyIGNvbnN1bXB0aW9uOyBhbmQgdGhlIGFtb3VudCBvZiBuZXcgY29k ZSByZXF1aXJlZCBvbg0KICAgIGVuZCBzeXN0ZW1zIHdoaWNoIGFscmVhZHkgaGF2ZSBhbiBPU0NP UkUgc3RhY2suDQogICAgVGhpcyBsaXN0IGJlbG9uZyBJRVRGIGFyZWE6IFNFQw0KICAgIA0KICAg IEZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCB0aGUgbGlzdCBhZG1p bmlzdHJhdG9ycy4NCiAgICANCiAgICANCg0K From nobody Mon Jun 24 08:35:14 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84C812046C for ; Mon, 24 Jun 2019 08:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh3g6IAmWIaw for ; Mon, 24 Jun 2019 08:35:12 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 AB8FD120468 for ; Mon, 24 Jun 2019 08:35:11 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id w13so22420992eds.4 for ; Mon, 24 Jun 2019 08:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OptSa1ggld7WDr2mZdzcLHhQf79XbqCfQVlH1o/h9hY=; b=dGFNlad/fSWy0sIp2OnnjdL6SXwxJL9sU0mUvshEWUDz9oRlEIj7G2a7EwOmNcDT3o c44hRdhFfHBuuMl2L+jeHWSn0OS1UshHYKDePXTip8NcsheFXAYpU+F1sWfnAzmguJ0B v2cWgA4+uH62Z5Gyg3prODOC1ysz5+wck4Ble9FIIdslnKVShbCVDec8i+zeVGS/nhaZ 4+36yeMIFq/W7b1/evmtrUFoXEWTXCwmmYFooPSzZSrS4Bj6WxGGa0zAaS2dSF/nVU5y BbBBHT+YNcD0sHQ+myVsYPjgucgxpD0bLRefe1sOVST0lImkTECjiUYvaUWJRrjJKPZ3 ym7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OptSa1ggld7WDr2mZdzcLHhQf79XbqCfQVlH1o/h9hY=; b=isGkKpehn9mtQJkbsS43OiEHo1XRllRenS5Tw+mHlGFcML/4RFaHOcZxIGl9VJZFH+ B6q72etK5EVXRbAMUoToQtccNA6JsmZuWYEDfz5PoEeZuBGzCWBPhfN2E4cfxQ8hRJ6b d8omZ+Zr04ghAsEBMjsYtwMqTvq7MPUMLQQ3SlxhGY7aJN0Xd6dt4nKTjqy0w4lo3xVC xCKIn+qW+tHgFFiff6jfUWo6ZKpD5lyGI90sRKL5GyNMBfSQZ3ep4O+9wNDwTWydVAzC XCTLG//LzUVebRXJDay7y9qm+EkuMy7ohwsWvk+rsT+u6jMO6VM2I3ac2DiogyW89+d5 /g+Q== X-Gm-Message-State: APjAAAWS45y2UgJZ/LgoMslRgmTUdnho703LqhtR+jzguPdVw/6MITvy TQ/PaXyLOnam5mpKeBdhVHUmPUVHofsT0CjAuhnV0weTnNE= X-Google-Smtp-Source: APXvYqzT7clNBS4H/0yWk0KFD4+jhgNMgiqV+npE+blLDX5HDd84UOn65qPND7x++gKICkZGii1sHleXYWZQ6prfCfs= X-Received: by 2002:a50:ac4a:: with SMTP id w10mr145101860edc.33.1561390509997; Mon, 24 Jun 2019 08:35:09 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Mon, 24 Jun 2019 17:34:57 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="000000000000b442e3058c138e83" Archived-At: Subject: [core] Announcement: new raza-ace-cbor-certificates version submitted X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 15:35:14 -0000 --000000000000b442e3058c138e83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! We have just submitted a revised version of raza-ace-cbor-certificates. We have clarified why our profiling together with the cbor encoding allows us to reduce certificate sizes more than any general compression mechanism. In addition we have opened up for allowing different public key and signature algorithms, where we propose the use of COSE identifiers for efficient encoding. Finally we propose to register this mechanism as one of the compression algorithms in the registry defined in ietf-tls-certificate-compression. We look forward to further comments, input and discussions! Best Regards Joel H=C3=B6glund, RISE SICS --000000000000b442e3058c138e83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi!


We have just subm= itted a revised version of raza-ace-cbor-certificates. We have clarified wh= y our profiling together with the cbor encoding allows us to reduce certifi= cate sizes more than any general compression mechanism. In addition we have= opened up for allowing different public key and signature algorithms, wher= e we propose the use of COSE identifiers for efficient encoding. Finally we= propose to register this mechanism as one of the compression algorithms in= the registry defined in ietf-tls-certificate-compression.


We look forward to further c= omments, input and discussions!


Best Regards


Joel H=C3=B6glund, RISE SICS


--000000000000b442e3058c138e83-- From nobody Mon Jun 24 08:42:55 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083931201A3 for ; Mon, 24 Jun 2019 08:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 GSqIU0cTuhVs for ; Mon, 24 Jun 2019 08:42:51 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0D9120196 for ; Mon, 24 Jun 2019 08:42:51 -0700 (PDT) Received: from mail-qt1-f177.google.com ([209.85.160.177]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hfR7J-0000l5-EH; Mon, 24 Jun 2019 17:42:49 +0200 Received: by mail-qt1-f177.google.com with SMTP id p15so14965111qtl.3 for ; Mon, 24 Jun 2019 08:42:49 -0700 (PDT) X-Gm-Message-State: APjAAAW+UiL5NSrwRgeBCQ9TUDUGfI8uNbJ218n+stSVbN+pmP8LBndO Cc/qtTSQ8Il/ag0DaxHSsMPh2AhfMd7x/rFhXI8= X-Google-Smtp-Source: APXvYqzyubgLJ6XrPdY12GJsCl+AHnKILAkiD69U6cfq/IvhjxVHZ/nAb5LmTYKS4rCVdosbm+EwycXhKrnFI4P18hg= X-Received: by 2002:aed:39e7:: with SMTP id m94mr52294574qte.0.1561390968366; Mon, 24 Jun 2019 08:42:48 -0700 (PDT) MIME-Version: 1.0 References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> In-Reply-To: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> From: Klaus Hartke Date: Mon, 24 Jun 2019 17:42:12 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1561390971; a5800c04; X-HE-SMSGID: 1hfR7J-0000l5-EH Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 15:42:54 -0000 I've performed a quick review of draft-ietf-core-hop-limit-03: 1. "More and more applications are using Constrained Application Protocol" - ...are using *the* Constrained Application Protocol... 1. "a distributed denial-of-service (DDoS) attack signaling protocol seeking for help" - ...protocol *for* seeking for help...? 1. "When multiple proxies are involved, infinite forwarding loops may be experienced." - It might be useful to spell out why such forwarding loops might exist. 1. "which is inserted in particular by on-path proxies" - This is hard to read. (It took me a few reads to notice that there's no word missing after "in particular"...) 3. "Therefore, any message carrying multiple Hop-Limit options MUST be rejected using 4.00 (Bad Request) error message." - Better to reference RFC 7252, which specifies in detail what to do with an option that doesn't have the right number of occurrences [1]. 3. "The value of the Hop-Limit option is encoded as an 8-bit unsigned integer" - Remove "8-bit". The range of a CoAP uint is not measured in bits. 3. "The initial Hop-Limit value SHOULD be configurable." - Is it really a protocol violation if my implementation does not provide a configuration option for this? 3. "the default initial Hop-Limit value of 16 MUST be used" - Do we have any actual insights to guide the choice for a default of 16 and maximum of 255? 3. "A CoAP proxy which understands the Hop-Limit option MUST NOT use a stored TBA1 (Hop Limit Reached) error response unless..." - Do we need to say something about non-"Hop Limit Reached" responses here? E.g., when there's a cached 2.05 (Content) response and a request with a lower hop limit is received, the last hop might not be reachable anymore. On the other hand, if there's a cached 2.05 (Content) response, then there's clearly no loop, which is what we're trying to detect here. 3. "To ease debugging and troubleshooting, the CoAP proxy which detects a loop SHOULD include its information ... Each intermediate proxy involved in relaying a TBA1 (Hop Limit Reached) error message SHOULD prepend its own information" - Is it really a protocol violation if I want to configure my proxy not to include any information? 3. "That information MUST NOT include any space character." - Since a diagnostic payload is intended for debugging, it seems weird to make any requirements on the formatting. Diagnostic information without any space characters is probably very hard to read. 3. "Each intermediate proxy involved in relaying a TBA1 (Hop Limit Reached) error message SHOULD prepend its own information" - It might be worth pointing out that at some point the diagnostic message might become so large that Blockwise Transfers [2] are needed. Carsten Bormann wrote: > (1) With a way to perform proxy loop mitigation now available, what is ou= r recommendation for usage? Is this something that is (a) specific to DOTS= , something that (b) it would now be reasonable to expect a proxy to add, o= r (c) something that every CoAP implementation should do? (At the interim,= we were leaning towards (b).) I think it would be reasonable to expect every proxy to implement this and have it enabled by default. > (2) The HTTP world has a concurrent document addressing the same issue, > > https://tools.ietf.org/html/rfc8586 > > The technical approach is different here (based on leaving breadcrumbs in= the requests), so it acts as a true loop prevention mechanism, not just mi= tigation. It also is more expensive, adding dozens of bytes to each reques= t passing a proxy. Still, we want to make sure the difference in approache= s is well justified. Maybe if there aren't too many proxies, then adding one or two dozen bytes isn't that expensive? We should check how to do HTTP/CoAP and CoAP/HTTP Mapping when a Hop-Limit option/CDN-Loop header field is present. Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.4.5 [2] https://tools.ietf.org/html/rfc7959 From nobody Mon Jun 24 08:48:01 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E526120150; Mon, 24 Jun 2019 08:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5M2uW6mg1Xpg; Mon, 24 Jun 2019 08:47:58 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8D212008D; Mon, 24 Jun 2019 08:47:57 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45XYbJ0qs9z21gl; Mon, 24 Jun 2019 17:47:56 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 45XYbH6txhzyPk; Mon, 24 Jun 2019 17:47:55 +0200 (CEST) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBMA4.corporate.adroot.infra.ftgroup ([fe80::4538:d7b0:3c64:8ed3%22]) with mapi id 14.03.0439.000; Mon, 24 Jun 2019 17:47:55 +0200 From: To: Thomas Fossati , Laurent Toutain CC: lp-wan , "core@ietf.org WG" Thread-Topic: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.txt Thread-Index: AQHVIGBs9p3Lrr051USWqEm/NEoBQ6aW4xcAgBQkiQA= Date: Mon, 24 Jun 2019 15:47:55 +0000 Message-ID: <22977_1561391276_5D10F0AB_22977_316_1_D936BC6F.62710%dominique.barthel@orange.com> References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 15:48:00 -0000 SGVsbG8gVGhvbWFzLA0KDQpTcGVha2luZyB1bmRlciB0aGUgY29udHJvbCBvZiBMYXVyZW50LCBo ZXJlJ3MgbXkgYW5zd2VyLg0KQnkgZGVmYXVsdCwgU0NIQyB0cmFuc21pdHMgaW4gdW5jb21wcmVz c2VkIGZvcm0gdGhvc2UgbWVzc2FnZXMgaXQgZG9lc24ndA0KZmlsZSBjb21wcmVzc2lvbiBydWxl cyBmb3IuDQpUaGUgc2V0IG9mIGNvbXByZXNzaW9uIHJ1bGVzIHByb3Bvc2VkIGJ5IExhdXJlbnQg bWF0Y2hlcyB0aGUgY3VycmVudA0KdmVyc2lvbiBvZiBDb0FQLg0KVGhlcmVmb3JlLCBhIG1lc3Nh Z2UgYmVhcmluZyBhIGRpZmZlcmVudCAoaS5lLiBmdXR1cmUpIHZlcnNpb24gb2YgQ29BUA0Kd2ls bCBub3QgYmUgbWF0Y2hlZCBieSB0aGUgY3VycmVudCBzZXQgb2YgcnVsZXMsIHRoZXJlZm9yZSBp dCB3aWxsIGJlIHNlbnQNCnVuY29tcHJlc3NlZC4NCkRvZXMgdGhhdCBjbGVhciBvdXQgeW91ciBk b3VidHM/DQpCZXN0IHJlZ2FyZHMNCg0KRG9taW5pcXVlDQoNCkxlIDEyLzA2LzE5IDAwOjExLCDC qyBjb3JlIG9uIGJlaGFsZiBvZiBUaG9tYXMgRm9zc2F0aSDCuw0KPGNvcmUtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgdGhvLmlldGZAZ21haWwuY29tPiBhIMOpY3JpdCA6DQoNCj5IaSBM YXVyZW50LCBBbmEsDQo+DQo+T24gVHVlLCBKdW4gMTEsIDIwMTkgYXQgMzoxNiBQTSBMYXVyZW50 IFRvdXRhaW4NCj48bGF1cmVudC50b3V0YWluQGltdC1hdGxhbnRpcXVlLmZyPiB3cm90ZToNCj4+ IE9uIFRodSwgTWF5IDMwLCAyMDE5IGF0IDE6NTMgUE0gVGhvbWFzIEZvc3NhdGkgPHRoby5pZXRm QGdtYWlsLmNvbT4NCj4+d3JvdGU6DQo+PiA+IC0gU2VjIDQuMTogIlRoaXMgZmllbGQgaXMgYmlk aXJlY3Rpb25hbCBhbmQgTVVTVCBiZSBlbGlkZWQgZHVyaW5nDQo+PiA+IHRoZSBTQ0hDIGNvbXBy ZXNzaW9uIi4gVGhpcyBpcyBhIGRhbmdlcm91cyBzdGF0ZW1lbnQgYXMgaXQgbGVhZHMgdXMNCj4+ ID4gc3RyYWlnaHQgaW50byBDb0FQIG9zc2lmaWNhdGlvbiB0ZXJyaXRvcnkuICBJZiB5b3Ugd2Fu dCBTQ0hDIHRvIHdvcmsNCj4+ID4gd2l0aCBDb0FQIHYxIG9ubHkgd2hhdCB5b3UgcmVhbGx5IHdh bnQgdG8gc2F5IGhlcmUgaXMgIlNIQ0gNCj4+ID4gY29tcHJlc3Npb24gTVVTVCBOT1QgYmUgYXBw bGllZCB0byBDb0FQIHBhY2tldHMgd2l0aCB2ZXJzaW9uDQo+PiA+IGRpZmZlcmVudCBmcm9tIHYx Ii4gIEdyYW50ZWQgdGhhdCwgYSBTQ0hDIGJveCBkZXBsb3llZCB0b2RheSBjb3VsZA0KPj4gPiBz aXQgaW4gdGhlIGZpZWxkIGhhcHBpbHkgZXZlciBhZnRlci4gIElmIG5vdCwgd2hlbiBhIG5ldyBD b0FQDQo+PiA+IHZlcnNpb24gaXMgcm9sbGVkIG91dCwgZW5kcG9pbnRzIHdvdWxkbuKAmXQgYmUg YWJsZSB0byB1c2UgdGhpcyBuZXcNCj4+ID4gdmVyc2lvbiBvbiBhbnkgcGF0aCBjcm9zc2luZyBh biBTQ0hDIGJveC4NCj4+DQo+PiBXZSBkb24ndCB0aGluayB0aGlzIHdpbGwgY3JlYXRlIG9zc2lm aWNhdGlvbi4gVGhlIHJ1bGUgaXMgdmVyeQ0KPj4gZmxleGlibGUgYW5kIGRvIG5vdCBmb3JjZSB0 byBlbGlkZSB0aGlzIGZpZWxkIGF0IGFueSB0aW1lLiBGb3INCj4+IGluc3RhbmNlLCBpZiB5b3Ug aGF2ZSBhIGRldmljZSB0aGF0IGlzIENvQVAgdjEgb25seSwgdGhlbiB5b3UgY2FuDQo+PiBlbGlk ZSB0aGUgZmllbGQuDQo+Pg0KPj4gRHVyaW5nIGEgdHJhbnNpdGlvbiBwZXJpb2QgaWYgdGhlIGRl dmljZSBhY2NlcHRzIENvQVAgdjEgYW5kIHYyLCB0aGVuDQo+PiB0aGUgcnVsZSBjYW4gYmUgc2V0 IHRvIE1PPWlnbm9yZSBhbmQgQ0RBPXZhbHVlLXNlbnQuIE9yIGEgcnVsZSBmb3IgdjENCj4+IGFu ZCBhIHJ1bGUgZm9yIHYyIGNhbiBiZSB1c2VkLiAgSW4gYW55Y2FzZSB0aGUgZGV2aWNlIHdpbGwg cmVjZWl2ZSB0aGUNCj4+IGFwcHJvcHJpYXRlIENvQVAgdmVyc2lvbiBhZnRlciBkZWNvbXByZXNz aW9uLg0KPg0KPlRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGV4cGxhaW4uDQo+DQo+SG93 ZXZlciwgSSdtIHN0aWxsIGEgYml0IHVuc3VyZSBhYm91dCB3aGF0IGlzIHN0b3J5IGZvciBzdXBw b3J0aW5nDQo+cHJvdG9jb2wgdXBncmFkZSAvIGV2b2x1dGlvbiwgc28gcGxlYXNlIGxldCBtZSBy ZXBocmFzZSBteSBjb25jZXJuIGFuZA0KPnlvdSBjYW4gY2xlYXIgYWxsIG15IGRvdWJ0cyA6LSkN Cj4NCj5Eb2VzIHRoZSBzcGVjIGluIGl0cyBjdXJyZW50IGZvcm0gcHJvdmlkZSB0aGUgZ3VhcmFu dGVlIHRoYXQgYSBtaWRkbGVib3gNCj50aGF0IGlzIGRlcGxveWVkIHRvZGF5IGFuZCBuZXZlciB1 cGRhdGVkIChvciB1cGRhdGVkIG9uIGEgZGlmZmVyZW50IHRpbWUNCj5zY2FsZSB3aXRoIHJlc3Bl Y3QgdG8gdGhlIGVuZHBvaW50cykgd2lsbCBub3QgaW50ZXJmZXJlIHdpdGggdmVyc2lvbnMgb2YN Cj50aGUgcHJvdG9jb2wgaXQgZG9lc24ndCB1bmRlcnN0YW5kPyAgT3RoZXJ3aXNlIHNhaWQ6IHdo YXQgaXMgdGhlIGRlZmF1bHQNCj5iZWhhdmlvdXIgb2YgYSBTQ0hDIGVudGl0eSB3aGVuIGhhbmRs aW5nIHVua25vd24gc2VtYW50aWNzPw0KPg0KPmNoZWVycywgdGhhbmtzLCB0DQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5jb3JlIG1haWxpbmcg bGlzdA0KPmNvcmVAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Jun 24 11:15:55 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC11201EA; Mon, 24 Jun 2019 11:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o50KZKpSCIsM; Mon, 24 Jun 2019 11:15:43 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 5A906120119; Mon, 24 Jun 2019 11:15:42 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id j6so3046978ioa.5; Mon, 24 Jun 2019 11:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wwVZvEt3A3NxeeMpCd0VTH5at870efadmnhhs9npHYE=; b=VuwvBD8nr5a2byXgwEvOi4VxWlzSxz7ABQE6UvmPrTUQiJPcIC7BL59SYfmfycP+SK /gAcIYEgtcyR02IAjPsnQJZTj0kzs52fmSgajC9UqDvptiz8FLcaT2tjIFk0TXEfAVb7 /V4VD1nTY0rpWU5ky29f/H9ysngFDXlG9HFaJV4OrKsEkSGHpu3zXuP3DE0Rj3DM5ZOd REXBhFTpFYecwr4/97y1RXJGJCOw5nRLKDcYj+NB0Mdl1+4Fl11AIvxT1+k7tCidy20Y fVOSE9Hx1VnWPOXj+I1chk14PaI+E3azoFhz9lynq83YWKl3J2NKpuozbmjSmxTD4mTT WVIA== 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:content-transfer-encoding; bh=wwVZvEt3A3NxeeMpCd0VTH5at870efadmnhhs9npHYE=; b=O0bLkvvgWUyyrKVfP7OZfRW99Kdm6wnWVUMGnkpOgL1XuRlWYZSKuwXdPc6b8Rsb7a mXTE0gT8I89R6juOdQLjVDEy9vXwACfXR8qQXnMVrqSgU2dQNG2DhD2Zgp1n7H4ybdIi cRFuDG+3G+gxFWGnbyOe/WJSgKcZXFOR5cTvqaj6oFgJ+9ZE9Sb3XgJd07LuqxKoGnV2 9YbqqZoBxYZHSg93pF05D4WFpeUWymUBFromXyTbvWr7mS5Io0Wjsm42wgIk6LCHj5Ef ZAneluy76sn7G3W+XUqAYyCHwMn+Uvq7hKGPt8rpbveKI13eLsj9s7nkqSGdWdgmAXgk l5HQ== X-Gm-Message-State: APjAAAWqjr6AJDfI07i7twfX98t8UqTG6KN/k9khU+wcOPpVcTxEcs/X NsVyeGFuyio3HX82VG+pZwanhLrurbZPM3Q2/4o= X-Google-Smtp-Source: APXvYqywUV/1poxiFrQcu8E1AhMpy6Ggd2z+UKLn10HxKMGyDtGHz62qWj9eE1WxGWtnj8xGafqigDjP0ygQco53rMc= X-Received: by 2002:a6b:6012:: with SMTP id r18mr1203751iog.241.1561400141644; Mon, 24 Jun 2019 11:15:41 -0700 (PDT) MIME-Version: 1.0 References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> <22977_1561391276_5D10F0AB_22977_316_1_D936BC6F.62710%dominique.barthel@orange.com> In-Reply-To: <22977_1561391276_5D10F0AB_22977_316_1_D936BC6F.62710%dominique.barthel@orange.com> From: Thomas Fossati Date: Mon, 24 Jun 2019 19:15:30 +0100 Message-ID: To: dominique.barthel@orange.com Cc: Laurent Toutain , lp-wan , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 18:15:47 -0000 Hey Dominique, On Mon, Jun 24, 2019 at 4:47 PM wrote: > Speaking under the control of Laurent, here's my answer. :-) > By default, SCHC transmits in uncompressed form those messages it doesn't > file compression rules for. > The set of compression rules proposed by Laurent matches the current > version of CoAP. > Therefore, a message bearing a different (i.e. future) version of CoAP > will not be matched by the current set of rules, therefore it will be sen= t > uncompressed. > Does that clear out your doubts? So, IIUC, given the current vocabulary a network operator deploying / configuring the box has absolutely zero chance (even by accident) of becoming an ossifier? If so, excellent, I=E2=80=99m very happy! If instead there is a residual chance of composing a ruleset such that that wouldn't be the case, the document should contain advice on how to avoid the situation to arise. In fact, to avoid all doubts & to ease future stages of review on this point, I'd suggest you add an explicit "ossification / operations considerations" section where you capture this conversation and explain exactly what are SCHC key design features that avoid creating surface for blocking protocol evolution. (Sorry to insist so much on this aspect, but I think making it an explicit discussion point in the document is really important.) From nobody Tue Jun 25 08:13:27 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1DB120385; Tue, 25 Jun 2019 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DrOiVXvBxiSF; Tue, 25 Jun 2019 08:13:23 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C91120145; Tue, 25 Jun 2019 08:13:23 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 45Y8mw5Jqzz229C; Tue, 25 Jun 2019 17:13:20 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 45Y8mw3clqzyQB; Tue, 25 Jun 2019 17:13:20 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0439.000; Tue, 25 Jun 2019 17:13:20 +0200 From: To: Klaus Hartke , Carsten Bormann CC: core , "draft-ietf-core-hop-limit@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1p?= =?utf-8?Q?t-03.txt?= Thread-Index: AQHVKqOBdCBot5+fdkyhjdRBxa3/B6asdnlQ Date: Tue, 25 Jun 2019 15:13:20 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 25 Jun 2019 15:13:26 -0000 SGkgS2xhdXMsIA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4NCg0KUGxlYXNlIHNlZSBp bmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQvVGlydS9Kb24NCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gRGXCoDogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBLbGF1cyBIYXJ0a2UNCj4gRW52b3nDqcKgOiBsdW5kaSAyNCBqdWluIDIwMTkg MTc6NDINCj4gw4DCoDogQ2Fyc3RlbiBCb3JtYW5uDQo+IENjwqA6IGNvcmUNCj4gT2JqZXTCoDog UmU6IFtjb3JlXSDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1pdC0wMy50eHQN Cj4gDQo+IEkndmUgcGVyZm9ybWVkIGEgcXVpY2sgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1o b3AtbGltaXQtMDM6DQo+IA0KPiAxLiAiTW9yZSBhbmQgbW9yZSBhcHBsaWNhdGlvbnMgYXJlIHVz aW5nIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uDQo+IFByb3RvY29sIiAtIC4uLmFyZSB1c2luZyAq dGhlKiBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbC4uLg0KDQpbTWVkXSBPSy4NCg0K PiANCj4gMS4gImEgZGlzdHJpYnV0ZWQgZGVuaWFsLW9mLXNlcnZpY2UgKEREb1MpIGF0dGFjayBz aWduYWxpbmcgcHJvdG9jb2wNCj4gc2Vla2luZyBmb3IgaGVscCIgLSAuLi5wcm90b2NvbCAqZm9y KiBzZWVraW5nIGZvciBoZWxwLi4uPw0KDQpbTWVkXSBPSw0KDQo+IA0KPiAxLiAiV2hlbiBtdWx0 aXBsZSBwcm94aWVzIGFyZSBpbnZvbHZlZCwgaW5maW5pdGUgZm9yd2FyZGluZyBsb29wcyBtYXkN Cj4gYmUgZXhwZXJpZW5jZWQuIiAtIEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBzcGVsbCBvdXQgd2h5 IHN1Y2ggZm9yd2FyZGluZw0KPiBsb29wcyBtaWdodCBleGlzdC4NCg0KW01lZF0gVXBkYXRlZC4g VGhpcyBpcyBiYXNpY2FsbHkgYWJvdXQgbWlzY29uZmlndXJhdGlvbiwgcG9saWN5IGNvbmZsaWN0 cywgZXRjLiANCg0KPiANCj4gMS4gIndoaWNoIGlzIGluc2VydGVkIGluIHBhcnRpY3VsYXIgYnkg b24tcGF0aCBwcm94aWVzIiAtIFRoaXMgaXMgaGFyZA0KPiB0byByZWFkLiAoSXQgdG9vayBtZSBh IGZldyByZWFkcyB0byBub3RpY2UgdGhhdCB0aGVyZSdzIG5vIHdvcmQNCj4gbWlzc2luZyBhZnRl ciAiaW4gcGFydGljdWxhciIuLi4pDQoNCltNZWRdIEZpeGVkLiANCg0KPiANCj4gMy4gIlRoZXJl Zm9yZSwgYW55IG1lc3NhZ2UgY2FycnlpbmcgbXVsdGlwbGUgSG9wLUxpbWl0IG9wdGlvbnMgTVVT VCBiZQ0KPiByZWplY3RlZCB1c2luZyA0LjAwIChCYWQgUmVxdWVzdCkgZXJyb3IgbWVzc2FnZS4i IC0gQmV0dGVyIHRvDQo+IHJlZmVyZW5jZSBSRkMgNzI1Miwgd2hpY2ggc3BlY2lmaWVzIGluIGRl dGFpbCB3aGF0IHRvIGRvIHdpdGggYW4NCj4gb3B0aW9uIHRoYXQgZG9lc24ndCBoYXZlIHRoZSBy aWdodCBudW1iZXIgb2Ygb2NjdXJyZW5jZXMgWzFdLg0KPiANCg0KW01lZF0gTWFrZXMgc2Vuc2Uu IEZpeGVkLiANCg0KPiAzLiAiVGhlIHZhbHVlIG9mIHRoZSBIb3AtTGltaXQgb3B0aW9uIGlzIGVu Y29kZWQgYXMgYW4gOC1iaXQgdW5zaWduZWQNCj4gaW50ZWdlciIgLSBSZW1vdmUgIjgtYml0Ii4g VGhlIHJhbmdlIG9mIGEgQ29BUCB1aW50IGlzIG5vdCBtZWFzdXJlZCBpbg0KPiBiaXRzLg0KPiAN Cg0KW01lZF0gT0sNCg0KPiAzLiAiVGhlIGluaXRpYWwgSG9wLUxpbWl0IHZhbHVlIFNIT1VMRCBi ZSBjb25maWd1cmFibGUuIiAtIElzIGl0DQo+IHJlYWxseSBhIHByb3RvY29sIHZpb2xhdGlvbiBp ZiBteSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBwcm92aWRlIGENCj4gY29uZmlndXJhdGlvbiBv cHRpb24gZm9yIHRoaXM/DQoNCltNZWRdIE5vLCBpdCBpcyBub3QgYSBwcm90b2NvbCB2aW9sYXRp b24gKHRoYXQgaXMgdGhlIHJlYXNvbiBmb3IgdXNpbmcgIlNIT1VMRCIgYW5kIG5vdCAiTVVTVCIp LiANCg0KPiANCj4gMy4gInRoZSBkZWZhdWx0IGluaXRpYWwgSG9wLUxpbWl0IHZhbHVlIG9mIDE2 IE1VU1QgYmUgdXNlZCIgLSBEbyB3ZQ0KPiBoYXZlIGFueSBhY3R1YWwgaW5zaWdodHMgdG8gZ3Vp ZGUgdGhlIGNob2ljZSBmb3IgYSBkZWZhdWx0IG9mIDE2IGFuZA0KPiBtYXhpbXVtIG9mIDI1NT8N Cg0KW01lZF0gV2Ugd2VudCBmb3IgMjU1IGFzIGEgbWF4IHRvIGJlIGFsaWduZWQgd2l0aCBUVEwg KGlwdjQsIG1wbHMpIGFuZCBIb3AgTGltaXQgKGlwdjYpIHdpdGggdGhlIGFzc3VtcHRpb24gdGhh dCBldmVyeSBpbnRlcm1lZGlhdGUgbm9kZSBlbWJlZHMgYSBDb0FQIHByb3h5LiANCg0KVGhlIG1h aW4gcmF0aW9uYWxlIGZvciBwaWNraW5nIDE2IGlzIHdoYXQgaXMgY3VycmVudGx5IGRlcGljdGVk IGluIHRoZSBkcmFmdDogDQoNCiAgICJUaGlzIHZhbHVlIGlzIGNob3NlbiB0byBiZSBzdWZmaWNp ZW50bHkgbGFyZ2UgdG8NCiAgIGd1YXJhbnRlZSB0aGF0IGEgQ29BUCByZXF1ZXN0IHdvdWxkIG5v dCBiZSBkcm9wcGVkIGluIG5ldHdvcmtzIHdoZW4NCiAgIHRoZXJlIHdlcmUgbm8gbG9vcHMsIGJ1 dCBub3Qgc28gbGFyZ2UgYXMgdG8gY29uc3VtZSBDb0FQIHByb3h5DQogICByZXNvdXJjZXMgd2hl biBhIGxvb3AgZG9lcyBvY2N1ci4gIExvd2VyIHZhbHVlcyBzaG91bGQgYmUgdXNlZCB3aXRoDQog ICBjYXV0aW9uIGFuZCBvbmx5IGluIG5ldHdvcmtzIHdoZXJlIHRvcG9sb2dpZXMgYXJlIGtub3du IGJ5IHRoZSBDb0FQDQogICBjbGllbnQgKG9yIHByb3h5KSBpbnNlcnRpbmcgdGhlIEhvcC1MaW1p dCBvcHRpb24uIg0KDQo+IA0KPiAzLiAiQSBDb0FQIHByb3h5IHdoaWNoIHVuZGVyc3RhbmRzIHRo ZSBIb3AtTGltaXQgb3B0aW9uIE1VU1QgTk9UIHVzZSBhDQo+IHN0b3JlZCBUQkExIChIb3AgTGlt aXQgUmVhY2hlZCkgZXJyb3IgcmVzcG9uc2UgdW5sZXNzLi4uIiAtIERvIHdlIG5lZWQNCj4gdG8g c2F5IHNvbWV0aGluZyBhYm91dCBub24tIkhvcCBMaW1pdCBSZWFjaGVkIiByZXNwb25zZXMgaGVy ZT8gRS5nLiwNCj4gd2hlbiB0aGVyZSdzIGEgY2FjaGVkIDIuMDUgKENvbnRlbnQpIHJlc3BvbnNl IGFuZCBhIHJlcXVlc3Qgd2l0aCBhDQo+IGxvd2VyIGhvcCBsaW1pdCBpcyByZWNlaXZlZCwgdGhl IGxhc3QgaG9wIG1pZ2h0IG5vdCBiZSByZWFjaGFibGUNCj4gYW55bW9yZS4gT24gdGhlIG90aGVy IGhhbmQsIGlmIHRoZXJlJ3MgYSBjYWNoZWQgMi4wNSAoQ29udGVudCkNCj4gcmVzcG9uc2UsIHRo ZW4gdGhlcmUncyBjbGVhcmx5IG5vIGxvb3AsIHdoaWNoIGlzIHdoYXQgd2UncmUgdHJ5aW5nIHRv DQo+IGRldGVjdCBoZXJlLg0KDQpbTWVkXSBXZSBkb24ndCBoYXZlIGEgc29saWQgbW90aXZhdGlv biB0byB1c2UgTVVTVCBOT1QgZm9yIHN1Y2ggcG9zaXRpdmUgY2FzZS4gQSBsb3dlciBob3AtbGlt aXQgbWF5IGJlIGFuIGluZGljYXRpb24gdGhhdCBzb21lIGNoYW5nZXMgd2VyZSBtYWRlIHRvIHRo ZSB0b3BvbG9neSAoZS5nLiwgYWRkaW5nIGEgcHJveHkpLCBvbmUgbWF5IGFyZ3VlIHRoYXQgaXQg YmV0dGVyIHRvIGxldCBwYXNzIHRoZSByZXF1ZXN0IHJhdGhlciB0aGFuIHNlcnZpbmcgaXQgZnJv bSB0aGUgY2FjaGUgdG8gZW5zdXJlIHRoYXQgYSBwb3NpdGl2ZSByZXBseSB3aWxsIGJlIHN0aWxs IHJlY2VpdmUuIFJldHJpZXZlZCByZXNwb25zZSB3aWxsIGJlIGNhY2hlZCBhbmQgdGhlbiB1c2Vk IHRvIHNlcnZpY2Ugc3Vic2VxdWVudCByZXF1ZXN0cyAoZXhhY3QgbWF0Y2ggZm9yIHBvc2l0aXZl IGFuc3dlcnMgb3IgbG93ZXIvZXhhY3QgbWF0Y2ggZm9yIGhvcCBsaW1pdCByZWFjaGVkIHJlc3Bv bnNlKS4gDQoNCkJUVywgaWYgdGhlcmUgaXMgZ29pbmcgdG8gYmUgY2FjaGluZywgdGhlbiBldmVy eSBwcm94eSBpbiB0aGUgY2hhaW4gaXMgbGlrZWx5IHRvIGNhY2hlIHRoZSAoZ29vZCkgcmVzcG9u c2UgYW5kIHNvIHRoZSByZXF1ZXN0IHdpbGwgZ2V0IG5vIGZ1cnRoZXIgdGhhbiB0aGUgZmlyc3Qg cHJveHkuICAgIA0KDQo+IA0KPiAzLiAiVG8gZWFzZSBkZWJ1Z2dpbmcgYW5kIHRyb3VibGVzaG9v dGluZywgdGhlIENvQVAgcHJveHkgd2hpY2gNCj4gZGV0ZWN0cyBhIGxvb3AgU0hPVUxEIGluY2x1 ZGUgaXRzIGluZm9ybWF0aW9uIC4uLiBFYWNoIGludGVybWVkaWF0ZQ0KPiBwcm94eSBpbnZvbHZl ZCBpbiByZWxheWluZyBhIFRCQTEgKEhvcCBMaW1pdCBSZWFjaGVkKSBlcnJvciBtZXNzYWdlDQo+ IFNIT1VMRCBwcmVwZW5kIGl0cyBvd24gaW5mb3JtYXRpb24iIC0gSXMgaXQgcmVhbGx5IGEgcHJv dG9jb2wNCj4gdmlvbGF0aW9uIGlmIEkgd2FudCB0byBjb25maWd1cmUgbXkgcHJveHkgbm90IHRv IGluY2x1ZGUgYW55DQo+IGluZm9ybWF0aW9uPw0KPiANCg0KW01lZF0gSXQgaXMgbm90IGEgcHJv dG9jb2wgdmlvbGF0aW9uIGlmIHRoZSBpbmZvcm1hdGlvbiBpcyBub3QgaW5jbHVkZWQgLSBoZW5j ZSB0aGUgU0hPVUxELiBIb3dldmVyIGl0IG1ha2VzIGRpYWdub3NpbmcgdGhlIGlzc3VlIG1vcmUg ZGlmZmljdWx0Lg0KDQo+IDMuICJUaGF0IGluZm9ybWF0aW9uIE1VU1QgTk9UIGluY2x1ZGUgYW55 IHNwYWNlIGNoYXJhY3Rlci4iIC0gU2luY2UgYQ0KPiBkaWFnbm9zdGljIHBheWxvYWQgaXMgaW50 ZW5kZWQgZm9yIGRlYnVnZ2luZywgaXQgc2VlbXMgd2VpcmQgdG8gbWFrZQ0KPiBhbnkgcmVxdWly ZW1lbnRzIG9uIHRoZSBmb3JtYXR0aW5nLg0KDQpbTWVkXSBNYWtpbmcgcmVxdWlyZW1lbnQgb24g dGhlIGRpYWcgaXMgaW1wb3J0YW50IGhlcmUgYmVjYXVzZSB0aGlzIGlzIHVzZWQgdG8gaWRlbnRp ZnkgdGhlIGxvb3AuIE5vdGUgdGhhdCBIVFRQIGFsc28gbWFrZXMgc29tZSByZWNvIGFib3V0IHRo ZSBmb3JtYXQgb2YgZGlhZ25vc3RpYyBpbmZvcm1hdGlvbiwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3MjM5IA0KIA0KDQogRGlhZ25vc3RpYyBpbmZvcm1hdGlvbiB3aXRob3V0 IGFueQ0KPiBzcGFjZSBjaGFyYWN0ZXJzIGlzIHByb2JhYmx5IHZlcnkgaGFyZCB0byByZWFkLg0K DQpbTWVkXSBIbW0uIFRoaXMgaXMgYWJvdXQgYSBuYW1lLCBJUCBhZGRyZXNzZXMuIFRoZXNlIG11 c3Qgbm90IGluY2x1ZGUgc3BhY2UgY2hhcmFjdGVycy4gDQoNCj4gDQo+IDMuICJFYWNoIGludGVy bWVkaWF0ZSBwcm94eSBpbnZvbHZlZCBpbiByZWxheWluZyBhIFRCQTEgKEhvcCBMaW1pdA0KPiBS ZWFjaGVkKSBlcnJvciBtZXNzYWdlIFNIT1VMRCBwcmVwZW5kIGl0cyBvd24gaW5mb3JtYXRpb24i IC0gSXQgbWlnaHQNCj4gYmUgd29ydGggcG9pbnRpbmcgb3V0IHRoYXQgYXQgc29tZSBwb2ludCB0 aGUgZGlhZ25vc3RpYyBtZXNzYWdlIG1pZ2h0DQo+IGJlY29tZSBzbyBsYXJnZSB0aGF0IEJsb2Nr d2lzZSBUcmFuc2ZlcnMgWzJdIGFyZSBuZWVkZWQuDQo+IA0KDQpbTWVkXSBXZSBkbyBoYXZlIGRv dWJ0cyBhYm91dCB0aGUgdXNlIG9mIDc5NTkgaW4gdGhpcyBjb250ZXh0LiBJdCBpcyBub3Qgb2J2 aW91cyBmcm9tIDc5NTkgdG8gc2VlIGhvdyBkaWFnbm9zdGljIG1lc3NhZ2VzIGNhbiBiZSBzcGxp dCBvdmVyIG11bHRpcGxlIG1lc3NhZ2VzIHdpdGhvdXQgZXhwZWN0aW5nIGFueSBhY3Rpb24gZnJv bSB0aGUgY2xpZW50ICsgaG93IHRoZSBpbnRlcm1lZGlhdGUgcHJveHkgd2hpY2ggb2JzZXJ2ZXMg dGhlIHNpemUgaXMgbGFyZ2Ugd2lsbCBoYW5kbGUgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgdmFy aW91cyBmcmFnbWVudHMuDQoNCjQueHggaXMgYSBmYWlsdXJlIGFuZCBzbyB3aGlsZSB0aGlzIGNv dWxkIGJlIHJldHVybmVkIHdpdGggYW4gYWRkaXRpb25hbCBCTE9DSzIgdG8gdGhlIG5leHQgc2Vu ZGVyIGluIHRoZSBjaGFpbiwgd2UgZG9u4oCZdCB0aGluayB0aGlzIHdpbGwgd29yayBhcyB0aGUg b3JpZ2luYWwgY2xpZW50IGlzIGV4cGVjdGluZyBhIDIueHggdG8gaW5zcGVjdCBmb3IgYSBCTE9D SzIgb3B0aW9uIHRvIHNlZSBpZiB0aGUgcmVxdWVzdCBmb3IgdGhlIG5leHQgYmxvY2sgb2YgZGF0 YSBpcyBuZWVkZWQuIFRoZW4sIGhvdyBkb2VzIGFuIGludGVyaW0gcHJveHkga25vdyB0aGF0IGl0 IGlzIHRvIGJlIHNlbmRpbmcgdGhlIGFkZGl0aW9uYWwgZGF0YSByYXRoZXIgdGhhbiBmb3J3YXJk aW5nIHRoZSByZXF1ZXN0IG9uIHRvIHRoZSBuZXh0IHByb3h5Lg0KDQpXZSBzdWdnZXN0IHRoYXQg d2Ugb25seSBwcmVwZW5kIGlmIHRoZXJlIGlzIHN1ZmZpY2llbnQgc3BhY2UuIFdlIGNhbiBhZGQg TkVXIHRleHQgdG8gcmVjb3JkIHRoaXMuIA0KDQo= From nobody Tue Jun 25 23:58:55 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0680B1202EF for ; Tue, 25 Jun 2019 23:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nXTaCaZi1nXl for ; Tue, 25 Jun 2019 23:58:51 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7F8120122 for ; Tue, 25 Jun 2019 23:58:51 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45YYls53ktz21wH; Wed, 26 Jun 2019 08:58:49 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 45YYls4Bfjz8sY7; Wed, 26 Jun 2019 08:58:49 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0439.000; Wed, 26 Jun 2019 08:58:49 +0200 From: To: Klaus Hartke , Carsten Bormann CC: core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1p?= =?utf-8?Q?t-03.txt?= Thread-Index: AQHVKqOBdCBot5+fdkyhjdRBxa3/B6atgSyQ Date: Wed, 26 Jun 2019 06:58:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAD9F9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 26 Jun 2019 06:58:53 -0000 SGkgS2xhdXMsIENhcnN0ZW4sIGFsbCwgDQoNCklzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHRleHQg Y2hhbmdlIHRoYXQgeW91IGxpa2UgdG8gc2VlIGFkZGVkIHRvIHRoZSBkcmFmdCB0byBjYXB0dXJl ICgxKT8NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg S2xhdXMgSGFydGtlDQo+IEVudm95w6nCoDogbHVuZGkgMjQganVpbiAyMDE5IDE3OjQyDQo+IMOA wqA6IENhcnN0ZW4gQm9ybWFubg0KPiBDY8KgOiBjb3JlDQo+IE9iamV0wqA6IFJlOiBbY29yZV0g 8J+UlCBXR0xDIG9mIGRyYWZ0LWlldGYtY29yZS1ob3AtbGltaXQtMDMudHh0DQo+IA0KPiBDYXJz dGVuIEJvcm1hbm4gd3JvdGU6DQo+ID4gKDEpIFdpdGggYSB3YXkgdG8gcGVyZm9ybSBwcm94eSBs b29wIG1pdGlnYXRpb24gbm93IGF2YWlsYWJsZSwgd2hhdCBpcw0KPiBvdXIgcmVjb21tZW5kYXRp b24gZm9yIHVzYWdlPyAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyAoYSkgc3BlY2lmaWMgdG8N Cj4gRE9UUywgc29tZXRoaW5nIHRoYXQgKGIpIGl0IHdvdWxkIG5vdyBiZSByZWFzb25hYmxlIHRv IGV4cGVjdCBhIHByb3h5IHRvDQo+IGFkZCwgb3IgKGMpIHNvbWV0aGluZyB0aGF0IGV2ZXJ5IENv QVAgaW1wbGVtZW50YXRpb24gc2hvdWxkIGRvPyAgKEF0IHRoZQ0KPiBpbnRlcmltLCB3ZSB3ZXJl IGxlYW5pbmcgdG93YXJkcyAoYikuKQ0KPiANCj4gSSB0aGluayBpdCB3b3VsZCBiZSByZWFzb25h YmxlIHRvIGV4cGVjdCBldmVyeSBwcm94eSB0byBpbXBsZW1lbnQgdGhpcw0KPiBhbmQgaGF2ZSBp dCBlbmFibGVkIGJ5IGRlZmF1bHQuDQo+IA0K From nobody Wed Jun 26 03:21:46 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1D4120280; Wed, 26 Jun 2019 03:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 ENHtOxgbPIBX; Wed, 26 Jun 2019 03:21:41 -0700 (PDT) Received: from smtp.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 BE3B9120077; Wed, 26 Jun 2019 03:21:40 -0700 (PDT) Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YfFt6DDPzyPp; Wed, 26 Jun 2019 12:21:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 26 Jun 2019 12:21:38 +0200 Cc: Klaus Hartke , core , "draft-ietf-core-hop-limit@ietf.org" X-Mao-Original-Outgoing-Id: 583237292.625662-b8065f3856b4d0f8e32cffb94c5d825d Content-Transfer-Encoding: quoted-printable Message-Id: <6BB0BDA4-AB44-459A-89FD-7F66D5A3CFD4@tzi.org> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 26 Jun 2019 10:21:44 -0000 On Jun 25, 2019, at 17:13, = wrote: >=20 >> 3. "That information MUST NOT include any space character." - Since a >> diagnostic payload is intended for debugging, it seems weird to make >> any requirements on the formatting. >=20 > [Med] Making requirement on the diag is important here because this is = used to identify the loop. Note that HTTP also makes some reco about the = format of diagnostic information, see = https://tools.ietf.org/html/rfc7239=20 HTTP does not have the concept of diagnostic payload. The RFC is about an HTTP header field, which of course requires specific = syntax; the =E2=80=9CForwarded=E2=80=9D header field is equivalent to a = CoAP repeatable option. But none of that really answers Klaus question, if I understand that = correctly. > Diagnostic information without any >> space characters is probably very hard to read. Maybe we should simply use LF (new line) as the separator, so space = characters can be included in an entry if needed. (There still should = be some encouragement of restraint in formulating these entries.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 26 03:34:32 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0C12042E for ; Wed, 26 Jun 2019 03:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 XkFfHgPy_-tB for ; Wed, 26 Jun 2019 03:34:29 -0700 (PDT) Received: from smtp.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 50CA3120441 for ; Wed, 26 Jun 2019 03:34:29 -0700 (PDT) Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YfXg5PMPzyW7; Wed, 26 Jun 2019 12:34:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAD9F9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 26 Jun 2019 12:34:27 +0200 Cc: Klaus Hartke , core X-Mao-Original-Outgoing-Id: 583238064.758032-f613bd491d756e2d681e3550db5011e0 Content-Transfer-Encoding: quoted-printable Message-Id: <6441966C-0E58-4CB8-B4C2-08E2A1764696@tzi.org> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> <787AE7BB302AE849A7480A190F8B93302EAAD9F9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 26 Jun 2019 10:34:31 -0000 On Jun 26, 2019, at 08:58, = wrote: >=20 > Hi Klaus, Carsten, all,=20 >=20 > Is there any particular text change that you like to see added to the = draft to capture (1)? If we develop WG consensus on the intended usage, there probably should = be something like 1.1 Intended Usage The Hop-Limit option has originally been designed for a specific use = case [I-D.ietf-dots-signal-channel]. However, its intended usage is = general: CoAP proxies that do not have specific knowledge that proxy = forwarding loops are avoided in some other way, are expected to implement this option=20= and have it enabled by default. =20 Note that this means that a server that receives requests both via = proxies and directly from clients may see otherwise identical requests with = and without the Hop-Limit option included; servers with internal caching=20= will therefore also want to implement this option (at least as far as=20= needed for ignoring it). Or so. BTW, the title should say =E2=80=9CHop-Limit Option=E2=80=9D if that is = the name we give it. In the text, =E2=80=9CHop-Limit=E2=80=9D should always be used if the = option is meant, while =E2=80=9Chop limit=E2=80=9D should be used to = discuss the concept of a hop limit (e.g., what happens when that is = reached), and =E2=80=9CHop Limit Reached=E2=80=9D should always be used = in conjunction with TBA1. Gr=C3=BC=C3=9Fe, Carsten >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : core [mailto:core-bounces@ietf.org] De la part de Klaus Hartke >> Envoy=C3=A9 : lundi 24 juin 2019 17:42 >> =C3=80 : Carsten Bormann >> Cc : core >> Objet : Re: [core] =F0=9F=94=94 WGLC of = draft-ietf-core-hop-limit-03.txt >>=20 >> Carsten Bormann wrote: >>> (1) With a way to perform proxy loop mitigation now available, what = is >> our recommendation for usage? Is this something that is (a) specific = to >> DOTS, something that (b) it would now be reasonable to expect a proxy = to >> add, or (c) something that every CoAP implementation should do? (At = the >> interim, we were leaning towards (b).) >>=20 >> I think it would be reasonable to expect every proxy to implement = this >> and have it enabled by default. >>=20 >=20 >=20 From nobody Wed Jun 26 04:17:29 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6971E1200C1; Wed, 26 Jun 2019 04:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pcOQxeLDVJnL; Wed, 26 Jun 2019 04:17:25 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.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 101CB1200EC; Wed, 26 Jun 2019 04:17:25 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 45YgTN531LzBsBR; Wed, 26 Jun 2019 13:16:40 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 45YgTN408tz2xCf; Wed, 26 Jun 2019 13:16:40 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([fe80::d89a:9017:59c2:9724%21]) with mapi id 14.03.0439.000; Wed, 26 Jun 2019 13:16:40 +0200 From: To: Carsten Bormann CC: Klaus Hartke , core , "draft-ietf-core-hop-limit@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1p?= =?utf-8?Q?t-03.txt?= Thread-Index: AQHVKqOBdCBot5+fdkyhjdRBxa3/B6asdnlQgAEkmQCAAC6ZQA== Date: Wed, 26 Jun 2019 11:16:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAADC77@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6BB0BDA4-AB44-459A-89FD-7F66D5A3CFD4@tzi.org> In-Reply-To: <6BB0BDA4-AB44-459A-89FD-7F66D5A3CFD4@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 26 Jun 2019 11:17:28 -0000 SGkgQ2FydHNlbiwgDQoNClRoZXJlIGFyZSB0d28gcGFydHMgaW4gdGhlIGNvbW1lbnQgZnJvbSBL bGF1czogDQooMSkgIml0IHNlZW1zIHdlaXJkIHRvIG1ha2UgYW55IHJlcXVpcmVtZW50cyBvbiB0 aGUgZm9ybWF0dGluZyIgDQooMikgIkRpYWdub3N0aWMgaW5mb3JtYXRpb24gd2l0aG91dCBhbnkg c3BhY2UgY2hhcmFjdGVycyBpcyBwcm9iYWJseSB2ZXJ5IGhhcmQgdG8gcmVhZCINCg0KVXNpbmcg YW5vdGhlciBzZXBhcmF0b3IgaXMgbm90IGFkZXF1YXRlIGdpdmVuIGhpcyAoMSkuIA0KDQpBcyBm b3IgKDIpIGl0IHNlZW1zIHRoYXQgS2xhdXMgaXMgbWl4aW5nIHRoZSBpbmZvcm1hdGlvbiB0aGF0 IGlzIGluamVjdGVkIGJ5IGEgcHJveHkgd2l0aCB0aGUgb3ZlcmFsbCBkaWFnbm9zdGljIGluZm9y bWF0aW9uLiBUaGUgdGV4dCBoZSBxdW90ZWQgaXMgYWJvdXQgYSBuYW1lIG9yIGFuIElQIGFkZHJl c3MuIFN1Y2ggaW5mbyBtdXN0IG5vdCBpbmNsdWRlIGEgc3BhY2UgY2hhcmFjdGVyLiAgDQoNClRo ZSBkaWFnbm9zdGljIGluZm9ybWF0aW9uIHdpbGwgaW5jbHVkZSBzcGFjZSBjaGFyYWN0ZXJzIHdo ZW4gbW9yZSB0aGFuIG9uZSBwcm94eSBpcyBvbiB0aGUgcGF0aC4gU28sICgyKSBpcyBub3QgYWNj dXJhdGUuIA0KDQpNYWtpbmcgZm9ybWF0dGluZyByZXF1aXJlbWVudHMgaXMgaW1wb3J0YW50IGlm IHdlIHdvdWxkIGxpa2UgdG8gZWFzZSBkaWFnIG9wZXJhdGlvbnMuICANCg0KRGlkIEkgbWlzc2Vk IHNvbWV0aGluZz8gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+IEVu dm95w6nCoDogbWVyY3JlZGkgMjYganVpbiAyMDE5IDEyOjIyDQo+IMOAwqA6IEJPVUNBREFJUiBN b2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogS2xhdXMgSGFydGtlOyBjb3JlOyBkcmFmdC1pZXRmLWNv cmUtaG9wLWxpbWl0QGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbY29yZV0g8J+UlCBXR0xDIG9m IGRyYWZ0LWlldGYtY29yZS1ob3AtbGltaXQtMDMudHh0DQo+IA0KPiBPbiBKdW4gMjUsIDIwMTks IGF0IDE3OjEzLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4+IDMuICJUaGF0IGluZm9ybWF0aW9u IE1VU1QgTk9UIGluY2x1ZGUgYW55IHNwYWNlIGNoYXJhY3Rlci4iIC0gU2luY2UgYQ0KPiA+PiBk aWFnbm9zdGljIHBheWxvYWQgaXMgaW50ZW5kZWQgZm9yIGRlYnVnZ2luZywgaXQgc2VlbXMgd2Vp cmQgdG8gbWFrZQ0KPiA+PiBhbnkgcmVxdWlyZW1lbnRzIG9uIHRoZSBmb3JtYXR0aW5nLg0KPiA+ DQo+ID4gW01lZF0gTWFraW5nIHJlcXVpcmVtZW50IG9uIHRoZSBkaWFnIGlzIGltcG9ydGFudCBo ZXJlIGJlY2F1c2UgdGhpcyBpcw0KPiB1c2VkIHRvIGlkZW50aWZ5IHRoZSBsb29wLiBOb3RlIHRo YXQgSFRUUCBhbHNvIG1ha2VzIHNvbWUgcmVjbyBhYm91dCB0aGUNCj4gZm9ybWF0IG9mIGRpYWdu b3N0aWMgaW5mb3JtYXRpb24sIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIz OQ0KPiANCj4gSFRUUCBkb2VzIG5vdCBoYXZlIHRoZSBjb25jZXB0IG9mIGRpYWdub3N0aWMgcGF5 bG9hZC4NCj4gVGhlIFJGQyBpcyBhYm91dCBhbiBIVFRQIGhlYWRlciBmaWVsZCwgd2hpY2ggb2Yg Y291cnNlIHJlcXVpcmVzIHNwZWNpZmljDQo+IHN5bnRheDsgdGhlIOKAnEZvcndhcmRlZOKAnSBo ZWFkZXIgZmllbGQgaXMgZXF1aXZhbGVudCB0byBhIENvQVAgcmVwZWF0YWJsZQ0KPiBvcHRpb24u DQo+IA0KPiBCdXQgbm9uZSBvZiB0aGF0IHJlYWxseSBhbnN3ZXJzIEtsYXVzIHF1ZXN0aW9uLCBp ZiBJIHVuZGVyc3RhbmQgdGhhdA0KPiBjb3JyZWN0bHkuDQo+IA0KPiA+IERpYWdub3N0aWMgaW5m b3JtYXRpb24gd2l0aG91dCBhbnkNCj4gPj4gc3BhY2UgY2hhcmFjdGVycyBpcyBwcm9iYWJseSB2 ZXJ5IGhhcmQgdG8gcmVhZC4NCj4gDQo+IE1heWJlIHdlIHNob3VsZCBzaW1wbHkgdXNlIExGIChu ZXcgbGluZSkgYXMgdGhlIHNlcGFyYXRvciwgc28gc3BhY2UNCj4gY2hhcmFjdGVycyBjYW4gYmUg aW5jbHVkZWQgaW4gYW4gZW50cnkgaWYgbmVlZGVkLiAgKFRoZXJlIHN0aWxsIHNob3VsZCBiZQ0K PiBzb21lIGVuY291cmFnZW1lbnQgb2YgcmVzdHJhaW50IGluIGZvcm11bGF0aW5nIHRoZXNlIGVu dHJpZXMuKQ0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Wed Jun 26 04:23:13 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2407A12010F for ; Wed, 26 Jun 2019 04:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OwcKjMamJb-s for ; Wed, 26 Jun 2019 04:23:09 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2F41200DB for ; Wed, 26 Jun 2019 04:23:09 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45Ygcr09XNz12bD; Wed, 26 Jun 2019 13:23:08 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 45Ygcq1YThzyQB; Wed, 26 Jun 2019 13:23:07 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0439.000; Wed, 26 Jun 2019 13:23:07 +0200 From: To: Klaus Hartke , Carsten Bormann CC: core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1p?= =?utf-8?Q?t-03.txt?= Thread-Index: AQHVKqOBdCBot5+fdkyhjdRBxa3/B6atzHzw Date: Wed, 26 Jun 2019 11:23:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAADCA7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 26 Jun 2019 11:23:12 -0000 UmUtLCANCg0KS2xhdXMgcmFpc2VkIHRoaXMgZ29vZCBwb2ludDogDQoNCj4gV2Ugc2hvdWxkIGNo ZWNrIGhvdyB0byBkbyBIVFRQL0NvQVAgYW5kIENvQVAvSFRUUCBNYXBwaW5nIHdoZW4gYQ0KPiBI b3AtTGltaXQgb3B0aW9uL0NETi1Mb29wIGhlYWRlciBmaWVsZCBpcyBwcmVzZW50Lg0KDQpXZSB3 aWxsIGFkZCB0aGlzIE5FVyB0ZXh0IHRvIGFkZHJlc3MgaXQ6IA0KDQo9PT09PT09DQo0LiAgSFRU UCBNYXBwaW5ncw0KDQogICBUaGlzIHNlY3Rpb24gZm9jdXNlcyBvbiB0aGUgSFRUUCBtYXBwaW5n cyBzcGVjaWZpYyB0byB0aGUgQ29BUA0KICAgZXh0ZW5zaW9uIHNwZWNpZmllZCBpbiB0aGlzIGRv Y3VtZW50LiAgQXMgYSByZW1pbmRlciwgdGhlIGJhc2ljDQogICBub3JtYXRpdmUgcmVxdWlyZW1l bnRzIG9uIEhUVFAtdG8tQ29BUCBtYXBwaW5ncyBhcmUgZGVmaW5lZCBpbg0KICAgU2VjdGlvbiAx MC4yIG9mIFtSRkM3MjUyXS4gIFRoZSBnZW5lcmljIGd1aWRlbGluZXMgZm9yIEhUVFAvQ29BUA0K ICAgbWFwcGluZ3MgYXJlIGVsYWJvcmF0ZWQgaW4gW1JGQzgwNzVdLg0KDQogICBCeSBkZWZhdWx0 LCB0aGUgSFRUUC10by1Db0FQIFByb3h5IGluc2VydHMgYSBIb3AtTGltaXQgb3B0aW9uDQogICBm b2xsb3dpbmcgdGhlIGd1aWRlbGluZXMgaW4gU2VjdGlvbiAzLiAgT3B0aW9uYWxseSwgdGhlIEhU VFAtdG8tQ29BUA0KICAgUHJveHkgbWF5IGJlIGluc3RydWN0ZWQgYnkgcG9saWN5IHRvIGluc2Vy dCBhIEhvcC1MaW1pdCBvcHRpb24gb25seQ0KICAgaWYgYSAnVmlhJyBoZWFkZXIgaXMgcHJlc2Vu dCBpbiB0aGUgSFRUUCByZXF1ZXN0Lg0KDQogICBUaGUgSFRUUC10by1Db0FQIFByb3h5IHVzZXMg NTA4IChMb29wIERldGVjdGVkKSBhcyB0aGUgSFRUUCByZXNwb25zZQ0KICAgc3RhdHVzIGNvZGUg dG8gbWFwIFRCQTEgKEhvcCBMaW1pdCBSZWFjaGVkKS4gIEZ1cnRoZXJtb3JlLCBpdCBtYXBzDQog ICB0aGUgZGlhZ25vc3RpYyBwYXlsb2FkIG9mIFRCQTEgKEhvcCBMaW1pdCBSZWFjaGVkKSBhcyBw ZXIgU2VjdGlvbiA2LjYNCiAgIG9mIFtSRkM4MDc1XS4NCj09PT09PT0NCg0KQ2hlZXJzLA0KTWVk DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGNvcmUgW21haWx0bzpj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgS2xhdXMgSGFydGtlDQo+IEVudm95 w6nCoDogbHVuZGkgMjQganVpbiAyMDE5IDE3OjQyDQo+IMOAwqA6IENhcnN0ZW4gQm9ybWFubg0K PiBDY8KgOiBjb3JlDQo+IE9iamV0wqA6IFJlOiBbY29yZV0g8J+UlCBXR0xDIG9mIGRyYWZ0LWll dGYtY29yZS1ob3AtbGltaXQtMDMudHh0DQo+IA0KPiANCj4gV2Ugc2hvdWxkIGNoZWNrIGhvdyB0 byBkbyBIVFRQL0NvQVAgYW5kIENvQVAvSFRUUCBNYXBwaW5nIHdoZW4gYQ0KPiBIb3AtTGltaXQg b3B0aW9uL0NETi1Mb29wIGhlYWRlciBmaWVsZCBpcyBwcmVzZW50Lg0KPiANCj4gS2xhdXMNCg== From fredrik.wegelid@wittra.se Wed Jun 26 04:30:46 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3764A1200DB for ; Wed, 26 Jun 2019 04:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=wittra.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 UFsTg74bqiRY for ; Wed, 26 Jun 2019 04:30:44 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 18FFD120146 for ; Wed, 26 Jun 2019 04:30:44 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id t28so1793188lje.9 for ; Wed, 26 Jun 2019 04:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wittra.se; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=yx9XHqdHPrB1PNJPkh0J+HMDmqCl3Vr2yWHSjCPNQeQ=; b=gStbWECitsdRANNaJPYp9/429kzwjzbB20eB98kREkqYRLFA4kSZ+T9DM/qAWRQ5yG 8566fppYc4LhuxYJxc56VaFICK4CRDNpFU2kwC1oavbV16zTm4jkXJ0w46hxa4n7HjtM aCS0+vqqou+9sIN3jIcmMdymJtbaRXLnF+RfVIx5AQjXlaKI3EoFxYhHcgFA+CL+hSVf /s+uVEd8RZaoHMhpvePaup43CwvmcYDgIEEqmp4Pb33p+6ag4j6S8ernPfeckBzjaqOv IFK5wbi4dr/RVuvQfcYUr8ZDAPbBP5RXswPFLD8gMAo2jTM/RWBhzbe1q2Wr/SnJ6qT8 HbZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=yx9XHqdHPrB1PNJPkh0J+HMDmqCl3Vr2yWHSjCPNQeQ=; b=gTgY1VRLto+I6/X6jUBRnsu6U1s2ksuStAJ44hdLzQbXNE4q8x4mbtV4hnjvF9HO7B hNSNvY05wsQO7VTsq/6jA8rcQQqwpzoHUKAGBeFp1DAWKyNHeKPCPQnjfEjfyR5AY1cH TIDdfcGm8pN+p8T+Y3Pax4cLlnkFxQh2zHsyyKLt8BQ6tzmB93jtEpeq7quUyrDf2AB0 UuthBA/MOUN/UNVoAaGiWTW2ynb4I/ABWAI9r4j3XE4mbE1i7hfPUPa1UM8zTJbOv57H fDMf50kAuAmyQ8N4FXARY9f5AB/gEOxJE6CO7NM6FZ8+QeGm1SffwR/31Y/5B3naUT84 V5RA== X-Gm-Message-State: APjAAAVJPHGMWBeaEpgKf0UCJhbytcc+s3vxGCoowDIHapDRWSOfc6sQ lgTjEksivKt+tvuktgidFJFahwvhMvg= X-Google-Smtp-Source: APXvYqyevyIKkvGtdurL99vWlrOZ8bq1zPA1wGS2suhIQzBK+MVPXruxsYLJS7XUZgT/47iwYC++KA== X-Received: by 2002:a2e:9ec9:: with SMTP id h9mr2490538ljk.90.1561548641860; Wed, 26 Jun 2019 04:30:41 -0700 (PDT) Received: from sannas-ipad.localdomain (h-206-4.A137.corp.bahnhof.se. [176.10.206.4]) by smtp.gmail.com with ESMTPSA id x194sm2371723lfa.64.2019.06.26.04.30.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 04:30:41 -0700 (PDT) From: Fredrik Wegelid Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> Date: Wed, 26 Jun 2019 13:30:40 +0200 To: core@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 11:31:37 -0000 Hi, I hope that I am using this email list in the correct way. I apologise = if that is not the case. I have some questions/thoughts about using the No-Response option (RFC = 7967) together with block-wise transfers in COAP. In my team we are using CoAP to send messages from devices to a server. = The messages are of such a size that we need to make block-wise = transfers. In an attempt to reduce the amount of traffic in the network = we have looked at using the No-Response option. We are however not clear = on how this would work if used together with block-wise transfers. We = would like to use the No-Response option to make the server omit the = 2.31 Continue responses from the server on each block. We would however = still like to be able to get a response on the last block to indicate = the status of the entire block sequence.=20 Does this make sense? In RFC 7967 block-wise transfers are not = mentioned. Are they meant to be used together? Best regards, Fredrik Wegelid= From nobody Wed Jun 26 04:43:55 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54C01200DB for ; Wed, 26 Jun 2019 04:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 5Id-gconJSnx for ; Wed, 26 Jun 2019 04:43:51 -0700 (PDT) Received: from smtp.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 95826120121 for ; Wed, 26 Jun 2019 04:43:51 -0700 (PDT) Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45Yh4j3WQCzybF; Wed, 26 Jun 2019 13:43:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> Date: Wed, 26 Jun 2019 13:43:48 +0200 Cc: core X-Mao-Original-Outgoing-Id: 583242206.6311359-f1db63e45bb7266562de534b1f11a3a7 Content-Transfer-Encoding: quoted-printable Message-Id: <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> References: <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> To: Fredrik Wegelid , Abhijan Bhattacharyya X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 11:43:54 -0000 Hi Fredrik, I=E2=80=99m not sure I entirely understand the message exchanges you = envision; maybe you can provide an example. RFC 7967 has a way to suppress responses based on the response code. Unfortunately, the granularity is on the class only at the moment. The option that carries this information isn=E2=80=99t explicitly = defined as an extension point. Still, someone (the original author? = The WG?) might want to go ahead, e.g., by defining a bit in the option = value that says =E2=80=9CNot interested in 2.31 responses=E2=80=9D. = (Maybe we want to understand what exactly a client would not be = interested in a bit more before we go ahead allocating bits like this.) Abhijan, what do you think? Gr=C3=BC=C3=9Fe, Carsten > On Jun 26, 2019, at 13:30, Fredrik Wegelid = wrote: >=20 > Hi, >=20 > I hope that I am using this email list in the correct way. I apologise = if that is not the case. > I have some questions/thoughts about using the No-Response option (RFC = 7967) together with block-wise transfers in COAP. >=20 > In my team we are using CoAP to send messages from devices to a = server. The messages are of such a size that we need to make block-wise = transfers. In an attempt to reduce the amount of traffic in the network = we have looked at using the No-Response option. We are however not clear = on how this would work if used together with block-wise transfers. We = would like to use the No-Response option to make the server omit the = 2.31 Continue responses from the server on each block. We would however = still like to be able to get a response on the last block to indicate = the status of the entire block sequence.=20 >=20 > Does this make sense? In RFC 7967 block-wise transfers are not = mentioned. Are they meant to be used together? >=20 > Best regards, > Fredrik Wegelid > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Wed Jun 26 04:53:43 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F27C12069B for ; Wed, 26 Jun 2019 04:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NJWbOjTkkdMX for ; Wed, 26 Jun 2019 04:53:28 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.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 EC801120689 for ; Wed, 26 Jun 2019 04:53:27 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 45YhHp1zNXzFsyt; Wed, 26 Jun 2019 13:53:26 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 45YhHp12Zvz2xCD; Wed, 26 Jun 2019 13:53:26 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d%21]) with mapi id 14.03.0439.000; Wed, 26 Jun 2019 13:53:26 +0200 From: To: Carsten Bormann CC: Klaus Hartke , core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1p?= =?utf-8?Q?t-03.txt?= Thread-Index: AQHVKqOBdCBot5+fdkyhjdRBxa3/B6atgSyQgAAde4CAADaGUA== Date: Wed, 26 Jun 2019 11:53:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAADCFF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> <787AE7BB302AE849A7480A190F8B93302EAAD9F9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6441966C-0E58-4CB8-B4C2-08E2A1764696@tzi.org> In-Reply-To: <6441966C-0E58-4CB8-B4C2-08E2A1764696@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= 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, 26 Jun 2019 11:53:34 -0000 UmUtLA0KDQpUaGFua3MuIA0KDQpGV0lXLCB0aGlzIHRleHQgYW5kIG90aGVyIGNoYW5nZXMgdG8g YWRkcmVzcyB0aGUgV0dMQ3Mgd2VyZSBpbmNsdWRlZCBpbiBvdXIgd29ya2luZyBjb3B5Og0KDQoq IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvZHJhZnQtaG9wLWxpbWl0L2Jsb2IvbWFzdGVy L2RyYWZ0LWlldGYtY29yZS1ob3AtbGltaXQtMDQudHh0IA0KKiBkaWZmOiBodHRwczovL2dpdGh1 Yi5jb20vYm91Y2FkYWlyL2RyYWZ0LWhvcC1saW1pdC9ibG9iL21hc3Rlci93ZGlmZiUyMGRyYWZ0 LWlldGYtY29yZS1ob3AtbGltaXQtMDMudHh0JTIwZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1pdC0w NC5wZGYgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+IEVudm95w6nC oDogbWVyY3JlZGkgMjYganVpbiAyMDE5IDEyOjM0DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVk IFRHSS9PTE4NCj4gQ2PCoDogS2xhdXMgSGFydGtlOyBjb3JlDQo+IE9iamV0wqA6IFJlOiBbY29y ZV0g8J+UlCBXR0xDIG9mIGRyYWZ0LWlldGYtY29yZS1ob3AtbGltaXQtMDMudHh0DQo+IA0KPiBP biBKdW4gMjYsIDIwMTksIGF0IDA4OjU4LCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4N Cj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgS2xh dXMsIENhcnN0ZW4sIGFsbCwNCj4gPg0KPiA+IElzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHRleHQg Y2hhbmdlIHRoYXQgeW91IGxpa2UgdG8gc2VlIGFkZGVkIHRvIHRoZQ0KPiBkcmFmdCB0byBjYXB0 dXJlICgxKT8NCj4gDQo+IElmIHdlIGRldmVsb3AgV0cgY29uc2Vuc3VzIG9uIHRoZSBpbnRlbmRl ZCB1c2FnZSwgdGhlcmUgcHJvYmFibHkgc2hvdWxkIGJlDQo+IHNvbWV0aGluZyBsaWtlDQo+IA0K PiAxLjEgIEludGVuZGVkIFVzYWdlDQo+IA0KPiAgICBUaGUgSG9wLUxpbWl0IG9wdGlvbiBoYXMg b3JpZ2luYWxseSBiZWVuIGRlc2lnbmVkIGZvciBhIHNwZWNpZmljIHVzZQ0KPiBjYXNlDQo+ICAg IFtJLUQuaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsXS4gIEhvd2V2ZXIsIGl0cyBpbnRlbmRlZCB1 c2FnZSBpcw0KPiBnZW5lcmFsOg0KPiAgICBDb0FQIHByb3hpZXMgdGhhdCBkbyBub3QgaGF2ZSBz cGVjaWZpYyBrbm93bGVkZ2UgdGhhdCBwcm94eSBmb3J3YXJkaW5nDQo+IGxvb3BzDQo+ICAgIGFy ZSBhdm9pZGVkIGluIHNvbWUgb3RoZXIgd2F5LCBhcmUgZXhwZWN0ZWQgdG8gaW1wbGVtZW50IHRo aXMgb3B0aW9uDQo+ICAgIGFuZCBoYXZlIGl0IGVuYWJsZWQgYnkgZGVmYXVsdC4NCj4gICAgTm90 ZSB0aGF0IHRoaXMgbWVhbnMgdGhhdCBhIHNlcnZlciB0aGF0IHJlY2VpdmVzIHJlcXVlc3RzIGJv dGggdmlhDQo+IHByb3hpZXMNCj4gICAgYW5kIGRpcmVjdGx5IGZyb20gY2xpZW50cyBtYXkgc2Vl IG90aGVyd2lzZSBpZGVudGljYWwgcmVxdWVzdHMgd2l0aCBhbmQNCj4gICAgd2l0aG91dCB0aGUg SG9wLUxpbWl0IG9wdGlvbiBpbmNsdWRlZDsgc2VydmVycyB3aXRoIGludGVybmFsIGNhY2hpbmcN Cj4gICAgd2lsbCB0aGVyZWZvcmUgYWxzbyB3YW50IHRvIGltcGxlbWVudCB0aGlzIG9wdGlvbiAo YXQgbGVhc3QgYXMgZmFyIGFzDQo+ICAgIG5lZWRlZCBmb3IgaWdub3JpbmcgaXQpLg0KPiANCj4g T3Igc28uDQo+IA0KPiBCVFcsIHRoZSB0aXRsZSBzaG91bGQgc2F5IOKAnEhvcC1MaW1pdCBPcHRp b27igJ0gaWYgdGhhdCBpcyB0aGUgbmFtZSB3ZSBnaXZlDQo+IGl0Lg0KPiBJbiB0aGUgdGV4dCwg 4oCcSG9wLUxpbWl04oCdIHNob3VsZCBhbHdheXMgYmUgdXNlZCBpZiB0aGUgb3B0aW9uIGlzIG1l YW50LA0KPiB3aGlsZSDigJxob3AgbGltaXTigJ0gc2hvdWxkIGJlIHVzZWQgdG8gZGlzY3VzcyB0 aGUgY29uY2VwdCBvZiBhIGhvcCBsaW1pdA0KPiAoZS5nLiwgd2hhdCBoYXBwZW5zIHdoZW4gdGhh dCBpcyByZWFjaGVkKSwgYW5kIOKAnEhvcCBMaW1pdCBSZWFjaGVk4oCdIHNob3VsZA0KPiBhbHdh eXMgYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIFRCQTEuDQo+IA0KPiBHcsO8w59lLCBDYXJz dGVuDQo+IA0KPiANCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGUgOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEtsYXVzIEhhcnRrZQ0KPiA+PiBFbnZvecOpIDogbHVu ZGkgMjQganVpbiAyMDE5IDE3OjQyDQo+ID4+IMOAIDogQ2Fyc3RlbiBCb3JtYW5uDQo+ID4+IENj IDogY29yZQ0KPiA+PiBPYmpldCA6IFJlOiBbY29yZV0g8J+UlCBXR0xDIG9mIGRyYWZ0LWlldGYt Y29yZS1ob3AtbGltaXQtMDMudHh0DQo+ID4+DQo+ID4+IENhcnN0ZW4gQm9ybWFubiB3cm90ZToN Cj4gPj4+ICgxKSBXaXRoIGEgd2F5IHRvIHBlcmZvcm0gcHJveHkgbG9vcCBtaXRpZ2F0aW9uIG5v dyBhdmFpbGFibGUsIHdoYXQgaXMNCj4gPj4gb3VyIHJlY29tbWVuZGF0aW9uIGZvciB1c2FnZT8g IElzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgKGEpIHNwZWNpZmljDQo+IHRvDQo+ID4+IERPVFMs IHNvbWV0aGluZyB0aGF0IChiKSBpdCB3b3VsZCBub3cgYmUgcmVhc29uYWJsZSB0byBleHBlY3Qg YSBwcm94eQ0KPiB0bw0KPiA+PiBhZGQsIG9yIChjKSBzb21ldGhpbmcgdGhhdCBldmVyeSBDb0FQ IGltcGxlbWVudGF0aW9uIHNob3VsZCBkbz8gIChBdA0KPiB0aGUNCj4gPj4gaW50ZXJpbSwgd2Ug d2VyZSBsZWFuaW5nIHRvd2FyZHMgKGIpLikNCj4gPj4NCj4gPj4gSSB0aGluayBpdCB3b3VsZCBi ZSByZWFzb25hYmxlIHRvIGV4cGVjdCBldmVyeSBwcm94eSB0byBpbXBsZW1lbnQgdGhpcw0KPiA+ PiBhbmQgaGF2ZSBpdCBlbmFibGVkIGJ5IGRlZmF1bHQuDQo+ID4+DQo+ID4NCj4gPg0KDQo= From nobody Wed Jun 26 04:54:42 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC0120283 for ; Wed, 26 Jun 2019 04:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANOO1immOKlq for ; Wed, 26 Jun 2019 04:54:38 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::625]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639F4120033 for ; Wed, 26 Jun 2019 04:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EzSAr1m54q+XrKUrJ4SBM3moPhm24VUU+A3geHVruEQ=; b=iVvkoLo92q6vB6wE1m/26fZj5ffWHdGf42TSKdr1X4HxGocBEl5d430Q+S4IOuvtbMb5QngfYNBhqTV4WNp1YItj03KxGxXy34muMZ08rQiBDBVbaqPB/cht355JK0eXM2S/B8/JYsOTL51Kz24hDQ0B/JZHYILRrFSd82ZiTRA= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2217.eurprd07.prod.outlook.com (10.168.35.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.9; Wed, 26 Jun 2019 11:54:35 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::182d:7233:e234:8564]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::182d:7233:e234:8564%6]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 11:54:35 +0000 From: Francesca Palombini To: "core@ietf.org" Thread-Topic: Update on OSCORE Thread-Index: AQHVLBXsq1nQfjnbmEap+iXaMamSrg== Date: Wed, 26 Jun 2019 11:54:35 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8bc928f3-32d1-4403-120b-08d6fa2d0f75 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2217; x-ms-traffictypediagnostic: HE1PR0701MB2217: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(396003)(39860400002)(189003)(199004)(33656002)(476003)(486006)(2906002)(5660300002)(2501003)(3846002)(2616005)(66946007)(6486002)(64756008)(15650500001)(6436002)(6116002)(66556008)(1730700003)(66446008)(606006)(81156014)(66476007)(44832011)(53936002)(86362001)(236005)(186003)(5640700003)(8936002)(36756003)(54896002)(6512007)(6306002)(7736002)(68736007)(478600001)(2351001)(26005)(966005)(99286004)(73956011)(8676002)(256004)(7110500001)(102836004)(76116006)(2420400007)(66066001)(4744005)(316002)(14454004)(71200400001)(3480700005)(6916009)(71190400001)(6506007)(25786009)(7116003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2217; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lIeg+g+tL4PJUEeSXGHSD5kcDn3+4jKJ7pk5Pw79+nByIlISzxK5hBnWLY9hxPknBg1eYC+OrzHx9Itlvwoue3cfxNl2YjvlPA9rMURKAXIcauT0CpOQeVAbD+dlICWYP8duf68BsWLe0FL9kY4T07NDqyo5sVHi3GHZ7CDC5O7CsJidc1ASzZURjzbQ0lAdtEpk/ph/4Bvpj1q7FFd6kd9l/LZRlxPEQNBTFCXasz73GOp+WLs1yYk1eOh8aG1h6eQAfgNZJYwVJNkQfALNFdTF2qukJcL1QyP548wov33fW/h4WV6OYRd4S8lIGYFV8z1NtDi6paayf5zNCn+kv6IUoOEMFcqv5YshQ+T8q2lMnF+n6NXIRqkU/2HGKURV4F9GlVEGwLvyuJO55/O6+IWaiLIr5uv7keBa/xkKFBM= Content-Type: multipart/alternative; boundary="_000_B6DF006C40CA4814B9A904F9B1481132ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bc928f3-32d1-4403-120b-08d6fa2d0f75 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 11:54:35.8466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2217 Archived-At: Subject: [core] Update on OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 11:54:41 -0000 --_000_B6DF006C40CA4814B9A904F9B1481132ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ29SRSB3ZywNCg0KT1NDT1JFIGlzIG5vdyBiZWVuIHByb2Nlc3NlZCBieSB0aGUgUkZDIEVk aXRvciwgYW5kIGR1cmluZyB0aGUgbGF0ZXN0IHRvcCB0byBib3R0b20gcmV2aWV3IHdlIGhhdmUg Zm91bmQgYSBudW1iZXIgb2YgbWlub3IgaW5jb25zaXN0ZW5jaWVzIGFuZCBlZGl0b3JpYWxzIChm cm9tIGNhcGl0YWxpemF0aW9uIHRvIHVzZSBvZiBxdW90ZXMpLCBidXQgYWxzbyBhIGNvdXBsZSBv ZiBlcnJvcnMsIHRoYXQgd2UgaGF2ZSBmaXhlZCAoZm9yIGV4YW1wbGUgYXBwZW5kaXggQS4yLCB3 aGljaCB3YXMgb3V0ZGF0ZWQpLCBhbmQgc29tZSBnZW5lcmFsIGNsYXJpZmljYXRpb25zIGZvciBw b2ludHMgdGhhdCB0aGUgRWRpdG9yIGJyb3VnaHQgdXAuDQoNCklmIHlvdSB3YW50IHRvIGZvbGxv dyBvdXIgdXBkYXRlcywgeW91IGNhbiBzZWUgdGhlbSBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20v Y29yZS13Zy9vc2NvYXANCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQo= --_000_B6DF006C40CA4814B9A904F9B1481132ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIENvUkUgd2csPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T1NDT1JFIGlzIG5vdyBiZWVuIHBy b2Nlc3NlZCBieSB0aGUgUkZDIEVkaXRvciwgYW5kIGR1cmluZyB0aGUgbGF0ZXN0IHRvcCB0byBi b3R0b20gcmV2aWV3IHdlIGhhdmUgZm91bmQgYSBudW1iZXIgb2YgbWlub3IgaW5jb25zaXN0ZW5j aWVzIGFuZCBlZGl0b3JpYWxzIChmcm9tIGNhcGl0YWxpemF0aW9uIHRvIHVzZSBvZiBxdW90ZXMp LCBidXQgYWxzbyBhDQogY291cGxlIG9mIGVycm9ycywgdGhhdCB3ZSBoYXZlIGZpeGVkIChmb3Ig ZXhhbXBsZSBhcHBlbmRpeCBBLjIsIHdoaWNoIHdhcyBvdXRkYXRlZCksIGFuZCBzb21lIGdlbmVy YWwgY2xhcmlmaWNhdGlvbnMgZm9yIHBvaW50cyB0aGF0IHRoZSBFZGl0b3IgYnJvdWdodCB1cC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHlvdSB3YW50IHRv IGZvbGxvdyBvdXIgdXBkYXRlcywgeW91IGNhbiBzZWUgdGhlbSBoZXJlOg0KPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29zY29hcCI+aHR0cHM6Ly9naXRodWIuY29t L2NvcmUtd2cvb3Njb2FwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B6DF006C40CA4814B9A904F9B1481132ericssoncom_-- From nobody Wed Jun 26 04:57:49 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482C4120283 for ; Wed, 26 Jun 2019 04:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wittra.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 fvH9hhHN3wqg for ; Wed, 26 Jun 2019 04:57:44 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 7FB20120033 for ; Wed, 26 Jun 2019 04:57:44 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id h10so1916283ljg.0 for ; Wed, 26 Jun 2019 04:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wittra.se; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yfS0wgTUCmMesD8vi8BLpPfl1zWLn64nK0tC/lJVM28=; b=ir+58Mvl8YbWJGRBgQ3jT67l3GT4oXOpcK3Tx5l0epZi0Dshcb+Svv1Cgz+z00L0PT tiYoU2sGB4t3Xpx3ugZAYjnnxA1rWy//ILWI8lJfrL5qLJUd1f5HRePDXG0ZkW0mLrxV jn+tl4UhV0JnaNPGzkyDRFEBZ5l6hUFAagSEM3Kr/DK2wPr0GW/BAndWHY42TvK2cgUN 5PAWvM53aaIai56Of13XinbFcEm8ZZzzWVG18FjmUERBzdA+aTIsYB+chcT9WUhgtyv0 hvnGvW90TWQjAwC1phTA9JmT7/td37eIFc7A2BYuQh8fSjhLQQ1zBO2D4pnn/HUDtH5v l6Gg== 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=yfS0wgTUCmMesD8vi8BLpPfl1zWLn64nK0tC/lJVM28=; b=XFU8TtU8+/YoLKFwv12IcAVx7oid0rITTJ00/NTCSkVpVZY3NcX+L8SCNg+8r5M0EN LwsVwM3vPUkfgh4PAdJgfGMrqP4sQSFfvccc1eHpWbE9xtvMi7mgvs1qhGQdB+dSeyuD XypQUWDG0ZS43SAfJLI4X/mvW6cAUyz8xYASkD1/sJ80vMUGhIW0mKvmytZJ5LrqaKhP 10LwK/Uye0EqbcR8x3HiIYy4LRFrzX3S0Ijg+EoPASuEhhlyaaQQtayNnXTn8baIRGm3 p3nZnmrY99K1vDaLYailNXuiGxlO7WfNI0ZnTOTZxrEISTsPYd7tJp+VnHCb0RIh1lIu IUKA== X-Gm-Message-State: APjAAAXYeqgfNnc0M/dHN9QcyUjpVYlXocVxj8OGqToR5NFtllW+RuSP HV92ld7fbusRTbRnNxqnMFo/Qw== X-Google-Smtp-Source: APXvYqzGj9eB1BYs8S2zArmJntm5Y7G3unCVRV4dg6JDJZi57e1m4u22jjlBWaXIL2boYsvl+F4rJg== X-Received: by 2002:a2e:3a05:: with SMTP id h5mr2731087lja.114.1561550262431; Wed, 26 Jun 2019 04:57:42 -0700 (PDT) Received: from sannas-ipad.localdomain (h-206-4.A137.corp.bahnhof.se. [176.10.206.4]) by smtp.gmail.com with ESMTPSA id h78sm998414ljf.88.2019.06.26.04.57.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 04:57:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Fredrik Wegelid In-Reply-To: <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> Date: Wed, 26 Jun 2019 13:57:40 +0200 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se> References: <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 11:57:47 -0000 Hi Carsten, This is how an example looks like without the No-Response option. Client -> Server: NON POST Payload: =E2=80=9CBlock 1...=E2=80=9D Server -> Client: NON 2.31 Continue Client -> Server: NON POST Payload: =E2=80=9CBlock 2...=E2=80=9D Server -> Client: NON 2.31 Continue More blocks=E2=80=A6 Client -> Server: NON POST Payload: =E2=80=9CFinal block...=E2=80=9D= Server -> Client: NON 2.01 Created (As an example) With the No-Response option I wish the exchange to look something like = this: Client -> Server: NON POST (No-Response:26) Payload: =E2=80=9CBlock = 1...=E2=80=9D Client -> Server: NON POST (No-Response:26) Payload: =E2=80=9CBlock = 2...=E2=80=9D More blocks=E2=80=A6 Client -> Server: NON POST Payload: =E2=80=9CFinal block...=E2=80=9D= Server -> Client: NON 2.01 Created (As an example) This would mean that the server would not send the 2.31 responses for = each block (as the No-Response option is set to 26) while it still would = send the final response (since the final block does not have the = No-Response option set). This allows the client to ensure that all blocks were sent successfully. = If they are not, the server would respond with another code. It would = also mean that the amount of traffic on the network is reduced. Best regards, Fredrik > On 26 Jun 2019, at 13:43, Carsten Bormann wrote: >=20 > Hi Fredrik, >=20 > I=E2=80=99m not sure I entirely understand the message exchanges you = envision; maybe you can provide an example. >=20 > RFC 7967 has a way to suppress responses based on the response code. > Unfortunately, the granularity is on the class only at the moment. > The option that carries this information isn=E2=80=99t explicitly = defined as an extension point. Still, someone (the original author? = The WG?) might want to go ahead, e.g., by defining a bit in the option = value that says =E2=80=9CNot interested in 2.31 responses=E2=80=9D. = (Maybe we want to understand what exactly a client would not be = interested in a bit more before we go ahead allocating bits like this.) >=20 > Abhijan, what do you think? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Jun 26, 2019, at 13:30, Fredrik Wegelid = wrote: >>=20 >> Hi, >>=20 >> I hope that I am using this email list in the correct way. I = apologise if that is not the case. >> I have some questions/thoughts about using the No-Response option = (RFC 7967) together with block-wise transfers in COAP. >>=20 >> In my team we are using CoAP to send messages from devices to a = server. The messages are of such a size that we need to make block-wise = transfers. In an attempt to reduce the amount of traffic in the network = we have looked at using the No-Response option. We are however not clear = on how this would work if used together with block-wise transfers. We = would like to use the No-Response option to make the server omit the = 2.31 Continue responses from the server on each block. We would however = still like to be able to get a response on the last block to indicate = the status of the entire block sequence.=20 >>=20 >> Does this make sense? In RFC 7967 block-wise transfers are not = mentioned. Are they meant to be used together? >>=20 >> Best regards, >> Fredrik Wegelid >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 From nobody Wed Jun 26 06:30:46 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3486812003E for ; Wed, 26 Jun 2019 06:30:43 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 fGW2O3hp6trP for ; Wed, 26 Jun 2019 06:30:40 -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 AF9241200D6 for ; Wed, 26 Jun 2019 06:30:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1FBB4460B9; Wed, 26 Jun 2019 15:30:37 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B801636; Wed, 26 Jun 2019 15:30:35 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:b187:7d3a:a59c:185]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7B35F2A; Wed, 26 Jun 2019 15:30:35 +0200 (CEST) Received: (nullmailer pid 10211 invoked by uid 1000); Wed, 26 Jun 2019 13:29:59 -0000 Date: Wed, 26 Jun 2019 15:29:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Klaus Hartke Cc: core Message-ID: <20190626132951.GA3528@hephaistos.amsuess.com> References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Separate formats for fetch and patch (was: WG Last Call of draft-ietf-core-senml-etch-03.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 13:30:43 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 24, 2019 at 01:21:31PM +0200, Klaus Hartke wrote: > General questions: >=20 > * It seems the new data formats are supersets of the existing data > formats. Also, it seems the same data format is used for fetching and > patching data. Is this what we, as CoRE WG, recommend (1 media type > for data, 1 media type for fetching and patching)? CoRAL is doing it > differently at the moment. I'd view this not as a general recommendation but as a way to go if for some reason the "descriptive" format can not be extended within its own constraints. In CoRAL, I don't see a need for separate media types. Applications mint their own dictionaries anyway. An application can make restrictions like in [1] for some operations (eg. "an Information Provider must only use dictionary I on resource representations returned from GET, and may accept dictionary F for FETCH-like operations if supported"). Best regards Christian [1]: https://tools.ietf.org/html/draft-hartke-t2trg-coral-08#section-6.1.3 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl0Tc0sACgkQOY0REtOk veE+rRAAn/axHkBysGwZMwdkaURiiQZmdQIWHTHMb6YgieZLMx0nOEtdXzcPvH7F JWQNcSXMa3AZwwUm8RkPXSOWlXVT5NHQ9NLBJJFmjYwtGbGsZzm0ch838YYDhrlL XN0IFe2lFeUtwqXqNmMQve+/MW96ERWKRGBrK0QIW6JYgMEOU547yWPQkkKlIvIZ NkZWSVA5PP6eEejmtn/ZX8rPEFZH0KRPLP1z0OKu549t3TZfu+LzpPdS+wUQzjq8 7J+lXkZUmoVs8Mtk82W8DqiY5zkIxmxsAoJ1g2tTTh3A3WAcE1PFaDU5NlUkBemp 232e0bykIAlb/tj4kVt5IrLRsj64+Uzqf9d70pKFQG000O/PmUme1lvlV/4t/WoP qlh11IQWmSNbNW6joUCktSE2c8ntLRbk8gVWDVAGdXANeJHMWUj3X+RhQiXtKQdE 7a+4Qqv/SEcBeT1He15KM86WrDYjWB0GWeSNb251OYzT0LbnqRiTw+rT4yL9EFd/ uyv9YT+qnVZ+UYOcmMzpdWY3nk35yjw2eVpLVIjPvyICP+ypS5DoTkWsqZAmB6uJ CkaFkQivAPX9Y19UNM2x7jVmTOCvqKiNsv2AwlIkunhL4mvpWY0ge48Z9j2oJiXG Y/Z9SP90vLJaRaDW9pmj9iIfBnXbXVM8yfjozoEb+qZKMPwLojk= =7UAO -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From nobody Wed Jun 26 06:34:51 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D31200E3 for ; Wed, 26 Jun 2019 06:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 pYtQPYTjhjSp for ; Wed, 26 Jun 2019 06:34:47 -0700 (PDT) Received: from smtp.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 56B4712003E for ; Wed, 26 Jun 2019 06:34:47 -0700 (PDT) Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YkXj5WpGzyv9; Wed, 26 Jun 2019 15:34:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <880105127.785171559138207866.JavaMail.nobody@rva2rmd101.webex.com> Date: Wed, 26 Jun 2019 15:34:44 +0200 X-Mao-Original-Outgoing-Id: 583248882.1259561-a51cbcbd875f0df20bd59017766f5aed Content-Transfer-Encoding: quoted-printable Message-Id: References: <880105127.785171559138207866.JavaMail.nobody@rva2rmd101.webex.com> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Webex meeting info: CoRE Virtual Interim 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, 26 Jun 2019 13:34:50 -0000 Hi, The meeting details for the CoRE Virtual Interim that starts in 1.5 = hours at 1500Z haven=E2=80=99t changed from last time; see below for = reference. The provisional agenda we are proposing is: =E2=80=94 (30) completing hop-limit Issue: Proxy paths with both HTTP and CoAP =E2=80=94 (10) completing senml-etch =E2=80=94 (30) status of the registries (Slides and proposals by Klaus) If you have other items that should be discussed today, please send a = message to core-chairs@ietf.org so we can update the agenda. Gr=C3=BC=C3=9Fe, Carsten Virtual Interim Hosted by CORE Working Group Wednesday, 26 Jun, 2019 15:00 | 1 hour 30 minutes | (UTC+00:00) = Monrovia, Reykjavik Occurs every 2 week(s) on Wednesday effective 5/29/2019 until 11/13/2019 = from 3:00 PM to 4:30 PM, (UTC+00:00) Monrovia, Reykjavik Meeting number: 648 636 609 Password: constrained https://ietf.webex.com/ietf/j.php?MTID=3Dm4f01e31ccd50d241bcf796aed4bf46d4= Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 636 609 From nobody Wed Jun 26 07:15:02 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8FD12015B for ; Wed, 26 Jun 2019 07:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 zrp7O1gjHZ8z for ; Wed, 26 Jun 2019 07:14:58 -0700 (PDT) Received: from smtp.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 BDC18120156 for ; Wed, 26 Jun 2019 07:14:58 -0700 (PDT) Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YlR50TR8zyj4; Wed, 26 Jun 2019 16:14:57 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 583251294.768078-8be920730a59de2b8d543ab8e1344c08 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 26 Jun 2019 16:14:56 +0200 Message-Id: To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-stateless-?= =?utf-8?q?01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 14:15:01 -0000 This is a Working Group last call on https://tools.ietf.org/html/draft-ietf-core-stateless-01 The WGLC will end in exactly 336 hours so we can discuss the outcome at = the CoRE WG Interim meeting on 2019-07=E2=80=9310. Please indicate your = position in a message to the CoRE mailing list (core@ietf.org) or, = exceptionally, to the chairs (core-chairs@ietf.org). Please find my chair=E2=80=99s review below; I believe the items raised = there can be discussed during the WGLC alongside the concerns of other = WG members. Gr=C3=BC=C3=9Fe, Carsten Chair=E2=80=99s review of draft-ietf-core-stateless-01 # Major Discovery is currently focused on whether the server supports extended = token lengths at all. Given that the maximum extended token is rather = large for a constrained environment, the client may be interested to = find out how large tokens can be for this server. With CSM, this would = be trivial (change empty option value to an uint value). With = trial-and-error, this leaves the client with binary search (probably = along the lines of the token sizes it actually can make use of). # Minor Section 3.3 suddenly starts to talk about authentication tags and = freshness indicators; this might require additional explanation (in = particular since there are BCP 14 keywords in these paragraphs). = Section 4.2.1 has some implementation guidelines that could possibly be = expanded to cover this. From nobody Wed Jun 26 07:43:37 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1191201AA for ; Wed, 26 Jun 2019 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw_BsJHB-uDV for ; Wed, 26 Jun 2019 07:43:30 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCBE12021B for ; Wed, 26 Jun 2019 07:43:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=TCK8Zwu2BBKXj+yUbKXVmYiSeTAeppyhZjwu7/rpYsOeA5Gm3OaQclbmm5nsYR7vuej6jnyUM/ZPmGDszoVSRg/aJmDOnjVV2K03S/qHqaE0U8OCT5IWdOnMol3btJPzQMawbwdDQNhTnm7Phczt3Fzup7ouf1KtNLNGsZVUalo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mKarOQ1e9VrPFOHQrU0ZUEkCNyGwrCMgvDpXBvvwo2E=; b=p/AHAKyEAUVbEZdjNE3jnNW0LuwvtWVlLeUCf0Whit5aik1BMG/HwZRDtP43UGwuR5oG/0KW5f+74Rcgssp6UivaLb8zNynGgz5QHs0dIQXo6K041u+FWSVNo9HvQSqS+HPmz+PYWN9k/LxnDGgDLhx4YYD3WTCSTv+WQNnW1RQ= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mKarOQ1e9VrPFOHQrU0ZUEkCNyGwrCMgvDpXBvvwo2E=; b=TJ+RjrV8zdCQFhuyiAFIpy1dyb+tryZ82OenIPazSHgTjEoC2wjdDbQz0xUcCXaUMPcyr24dS7C/ApyCpSCg+21/PG9HwpvXWFDIcYfrnruvdrNnadkDBsHjQDs0m869q8PWW1fVP3iDdjCfJxYIo8IMjCVavC7eTpBB5x8KqUk= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB4316.eurprd07.prod.outlook.com (20.176.167.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.11; Wed, 26 Jun 2019 14:43:27 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b5b8:de53:7372:dd2a]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b5b8:de53:7372:dd2a%7]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 14:43:27 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Klaus Hartke CC: Carsten Bormann , core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUt?= =?utf-8?Q?senml-etch-03.txt?= Thread-Index: AQHVISBQHJvty1Er7US6KumrZJ3bDKaqu7GAgANdFAA= Date: Wed, 26 Jun 2019 14:43:27 +0000 Message-ID: References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [2001:14bb:150:480b:8074:a92a:790c:2490] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 985634e3-00d1-4565-b2c4-08d6fa44a66b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4316; x-ms-traffictypediagnostic: HE1PR07MB4316: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(396003)(366004)(346002)(189003)(199004)(102836004)(25786009)(76116006)(5660300002)(86362001)(99936001)(6116002)(6486002)(478600001)(966005)(14454004)(2906002)(6246003)(186003)(6506007)(85202003)(36756003)(6916009)(73956011)(66446008)(64756008)(66556008)(66476007)(66616009)(66946007)(54906003)(2616005)(486006)(476003)(8936002)(305945005)(85182001)(11346002)(446003)(68736007)(316002)(71200400001)(71190400001)(46003)(99286004)(6436002)(6512007)(6306002)(33656002)(76176011)(4326008)(229853002)(7736002)(256004)(53936002)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4316; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CR5FZkWbUwgYHpyKo0/cG5r1FLQBzYt/4LE/eZh11FLR+tizF83uP+6gq72zu1zhpRahbNsQn7iaU2/07brn/IFvm6OGU133P1QgHmd4KLKWdbSU2/5kFzQyZiPX9dmQXVkPaGvpMAlBfw3zls+ys+LJnFWm6xNyWdAYThuar97xFG9y+IYwOp/xtxoSqcnCD2hXYkc3JOBXS+J/MqRKZsaIV5bG+d/WQANZf8cTmZqCY6Gjxd+H0aZnoZvKtSzGLUCcOt2aX0KgfKlfdhR9Pzre0Th14ecq5XoeSGwUaSfQQ7cOS/7h7AtkbnIVZXvNdC/8+Ocg8HLRgctdh1Uxt2hhN2ju+DtJZpQ6rrUkqOHZM12zXMeqGUr97F4q6Tm+TxLtMwJURgg4HjGmToLeY9YmBlMfhhd/oPSRZinQGp0= Content-Type: multipart/signed; boundary=Apple-Mail-A431C75C-20A6-4876-9277-5F0DA5FFB029; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 985634e3-00d1-4565-b2c4-08d6fa44a66b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 14:43:27.4720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ari.keranen@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4316 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-se?= =?utf-8?q?nml-etch-03=2Etxt?= 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, 26 Jun 2019 14:43:34 -0000 --Apple-Mail-A431C75C-20A6-4876-9277-5F0DA5FFB029 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhbmtzIEtsYXVzISBTZWUgaW5saW5lLg0KDQo+IE9uIDI0IEp1biAyMDE5LCBhdCAxNC4yMiwg S2xhdXMgSGFydGtlIDxoYXJ0a2VAcHJvamVjdGNvb2wuZGU+IHdyb3RlOg0KPiANCj4gSSBoYXZl IHBlcmZvcm1lZCBhIHF1aWNrIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtc2VubWwtZXRjaC0w MzoNCj4gDQo+IDMuMi4gIkZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIGRvY3VtZW50IGNvdWxk IGJlIGdpdmVuIGFzIChpKVBBVENIDQo+IHBheWxvYWQgdG8gY2hhbmdlL3NldCB2YWx1ZXMgb2Yg dHdvIFNlbk1MIFJlY29yZHMgZm9yIHRoZSBleGFtcGxlIGluDQo+IFNlY3Rpb24gMToiIC0tIEl0 IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGV4YW1wbGUgZnJvbSBzZWN0aW9uIDEgd2FzDQo+IGR1cGxp Y2F0ZWQgaGVyZSBhbmQgdGhlIHJlbW92YWwgb2YgYSByZWNvcmQgd2FzIHNob3duLg0KDQpNYWtl cyBzZW5zZSwgd2lsbCBhZGQgZXhhbXBsZSB0byB0aGUgbmV4dCByZXZpc2lvbi4NCg0KPiA1LjEg IkFsbCBJRHMgYXJlIGFzc2lnbmVkIGZyb20gdGhlICJJRVRGIFJldmlldyBvciBJRVNHIEFwcHJv dmFsIg0KPiByYW5nZS4iIC0tIFJlbW92ZSB0aGlzIHNlbnRlbmNlLg0KDQpTZW5NTCBSRkMgKGFu ZCBvdGhlcnMpIGhhdmUgdXNlZCBzdWNoIHNlbnRlbmNlIHRvIGluZGljYXRlIHRoZSBkZXNpcmVk IHJhbmdlLCBidXQgSeKAmW0gZmluZSBsZWF2aW5nIGl0IG91dCB0b28uDQoNCj4gNS4xICJUYWJs ZSAxOiBDb0FQIENvbnRlbnQtRm9ybWF0IElEcyIgLS0gVGhpcyB0YWJsZSBpcyBtaXNzaW5nIHRo ZQ0KPiAiQ29udGVudC1Db2RpbmciIChmLmsuYS4gIkVuY29kaW5nIikgY29sdW1uLg0KDQpHb29k IGNhdGNoOyB3aWxsIGFkZC4gSSBzdXBwb3NlIGl0IHdpbGwgYmUgc2ltcGx5IOKAnS3igJ0gZm9y IGJvdGguDQoNCj4gR2VuZXJhbCBxdWVzdGlvbnM6DQo+IA0KPiAqIEl0IHNlZW1zIHRoZSBuZXcg ZGF0YSBmb3JtYXRzIGFyZSBzdXBlcnNldHMgb2YgdGhlIGV4aXN0aW5nIGRhdGENCj4gZm9ybWF0 cy4gQWxzbywgaXQgc2VlbXMgdGhlIHNhbWUgZGF0YSBmb3JtYXQgaXMgdXNlZCBmb3IgZmV0Y2hp bmcgYW5kDQo+IHBhdGNoaW5nIGRhdGEuIElzIHRoaXMgd2hhdCB3ZSwgYXMgQ29SRSBXRywgcmVj b21tZW5kICgxIG1lZGlhIHR5cGUNCj4gZm9yIGRhdGEsIDEgbWVkaWEgdHlwZSBmb3IgZmV0Y2hp bmcgYW5kIHBhdGNoaW5nKT8gQ29SQUwgaXMgZG9pbmcgaXQNCj4gZGlmZmVyZW50bHkgYXQgdGhl IG1vbWVudCBbMV0uDQo+IA0KPiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWhhcnRrZS10MnRyZy1jb3JhbC0wOCNzZWN0aW9uLTYuNw0KDQpDaHJpc3RpYW4gbWFkZSBzb21l IGdvb2Qgb2JzZXJ2YXRpb25zIG9uIHRoaXMgYWxyZWFkeS4gSSB3b3VsZCBub3QgdmlldyB0aGlz IGFzIGEgZ2VuZXJhbCBndWlkZWxpbmUgZWl0aGVyLiBCdXQgbGV04oCZcyBjb250aW51ZSBvbiB0 aGF0IHRocmVhZCAoYW5kIGluIHRoZSBjYWxsIHRvZGF5KS4NCg0KDQpDaGVlcnMsDQpBcmk= --Apple-Mail-A431C75C-20A6-4876-9277-5F0DA5FFB029 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDMAw ggX2MIID3qADAgECAhA3E3FzLlznzicd63Rv9v4YMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMDQxNDEzNDRaFw0yMDEyMDQxNDEzNDNaMGUxETAPBgNVBAoMCEVyaWNzc29u MRUwEwYDVQQDDAxBcmkgS2Vyw6RuZW4xJzAlBgkqhkiG9w0BCQEWGGFyaS5rZXJhbmVuQGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWFyaWtlcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AIUlV66I5z1/qGYdhiIGfyvv8aaZexDetFCPlauUh5ugtp7Pf7ynpPRIK1FeWaoKs+IJ3E9R/9wT APFzjzjXpjyHHoBUdp8ZBuL/kt60cUTHTD4AScJGUHEgy70/Uf2YEj3JJjrTBbFnqDcXWTFF1n2Y edmhZDBdzZQJ18tlIjJmxgAJB1clI0nEg1gBnhl8mVdQp+ar6GjvxXfRuA1+uOpxa3y4zUpzF+ha LmaC4a5AbOsROtr7Uad8/pCzulAvAmPXvEJ/3JusafQfiqxNv1J/fT6W7sS8dBjF6vv3LgeAnYj5 /imtl9BOurFol0aIic+AjptfNoVf2pDhgYxn808CAwEAAaOCAb4wggG6MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCMGA1UdEQQcMBqBGGFyaS5rZXJhbmVuQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB BQUHAwIwHQYDVR0OBBYEFNHQXDyNP/SSyF6+EMLvo07phb3FMB8GA1UdIwQYMBaAFBx7GZ6XnHas ID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAVVggYWTwdz5B iMeBRYLop6Jo3Ji9YmfonCRFiyfw8he+efYc59IwzU9eIBRFSiWf87eqcZZJjcwWjHuju3MvzWsp 1qHnirszOtcNrUflFBoY7N3r19tG+z2bE/bjjZPituSIgCoX28IgLZLpIcnYg7niWXnwR3xGiphs EPO3mR3p7f+XLtdy+1qU/rAjZoW36mZuYk1lV6nIt9GfhuH1/yIQd5pxTDj54j3TOLv/KrEKwCFQ YLkho6zrOicpJk7DkjYGNLwmaDTRxuehMQHKDW+fXi1xi7/eScV0YnELjxXGuE3HojEkLB8Offfa /5TICfBN2HTASXJ0YsbpnAxPTyjExmKzl3mudQz6x5wP6THhM0sltX8wHVQEhU5w0uyLfT9yqWVY KTq+9GI02S9kzD+u1AWtftbWK2CQIGUAE43faZGrCchkT+fnYz5b1Ppyf5H45r/psmsA9J63iFCz nilKlo9M47fQPEsqpFWvDfE4jdobqSmQXp/aK7cvYoAEhcj5vOqR/bPNum7wWegQZdDsfy35vZl8 +vtRrKAk/6bmUfaiazqQoGq+DF1OL7sQlb1HbMmkJblrrBf8Csh6wdEVFey6vegBSIwtOnmcAFN9 2NlKp24f8rJxM17M9pWNG6OsmCGhxyo4k1BHn69nXXQfSN7QdqLpGfhQfpJL3LgwggbCMIIEqqAD AgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29u ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1 MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cY VVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUg MKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwN v/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZq QvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/ KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpX bxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6O Moc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOq QFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3Nw LnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYB Af8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9y ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0 cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQc exmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkq hkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bO ULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQk MrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiR sehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSr Z4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZ oviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4 gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCF z/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb 8ToH7WLoOzmPRCmPlpAxggLNMIICyQIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBglghkgBZQMEAgEFAKCCAUMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTkwNjI2MTQ0MzI2WjAvBgkqhkiG9w0BCQQxIgQgI/7pHd05HE9J56zgRs10tmo4 iIlcXXfiYvATBJHcfYswagYJKwYBBAGCNxAEMV0wWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfO Jx3rdG/2/hgwbAYLKoZIhvcNAQkQAgsxXaBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBgkqhkiG9w0BAQEFAASCAQBGQ6Vji6G65V0J4yM4iCk/34scxUDkmclOJlDgvJ4YDnvy jGGdwBYGPZP0mvQkV38RFuUu25L4nyBkU5Du4w1cqpBRw6W2L4ASDvgTuIgSJhWE4GrIapAWS1YH JOntsgIcOCvNU71I9KA1GwEkzyiRZPuLx0dsjXPZqiAN/xVcIPg0t6QpBNj+9YGCbOb+WAQw3jam b9n5X6EZWZWy1+nBBr7BLBpYUXXamSKwDwb7NlJdNEoKd32bnXoOHPZc3HypsVHwvCe4JMkQqbmK rg/OoCm3eVMGUfJfCMztUga8UQ8CEW1qLDF9l+m4VpX6ue45AdB1JQbetpM48TagR76fAAAAAAAA --Apple-Mail-A431C75C-20A6-4876-9277-5F0DA5FFB029-- From nobody Wed Jun 26 07:54:12 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A946212012B for ; Wed, 26 Jun 2019 07:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 BUCwnvJxidD7 for ; Wed, 26 Jun 2019 07:54:08 -0700 (PDT) Received: from smtp.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 79ECF120136 for ; Wed, 26 Jun 2019 07:54:08 -0700 (PDT) Received: from client-0057.vpn.uni-bremen.de (client-0057.vpn.uni-bremen.de [134.102.107.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YmJG4YYkzyT1; Wed, 26 Jun 2019 16:54:06 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 583253644.643083-bedb4afd47d69718c071e47ce44ebe3d Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 26 Jun 2019 16:54:06 +0200 Message-Id: To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-echo-reque?= =?utf-8?q?st-tag-05?= 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, 26 Jun 2019 14:54:11 -0000 This is a Working Group last call on https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-05 The WGLC will end in exactly 336 hours so we can discuss the outcome at = the CoRE WG Interim meeting on 2019-07=E2=80=9310. Please indicate your = position in a message to the CoRE mailing list (core@ietf.org) or, = exceptionally, to the chairs (core-chairs@ietf.org). Please find a couple of chair=E2=80=99s comments below (further to my = chair=E2=80=99s review of -03 on 2019-02-06) so that not everyone has to = make the same comments. I believe the items raised here can be = discussed during the WGLC alongside the concerns of other WG members. Gr=C3=BC=C3=9Fe, Carsten Chair=E2=80=99s comments on draft-ietf-core-echo-request-tag-05 # Minor The use of the term =E2=80=9Cfragments=E2=80=9D and =E2=80=9Cfragmented=E2= =80=9D does not quite describe RFC 7959. Empty CoAP messages (code=3D0.00) are not requests. So there is no need = for the text at the end of the first sentence of 2.2 # Nits -- The draft header indicates that this document updates RFC7252, but = the abstract doesn=E2=80=99t seem to mention this, which it should. RFC 7959 uses the spelling =E2=80=9Cblock-wise=E2=80=9D; this = specification could align to that. Section 2: =E2=80=9Ccoap=E2=80=9D The RFC editor notes about RFC 8613-to-be can be removed, I hope=E2=80=A6 From nobody Wed Jun 26 11:47:11 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE35120619 for ; Wed, 26 Jun 2019 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY1yQRPJN0SB for ; Wed, 26 Jun 2019 11:47:05 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70047.outbound.protection.outlook.com [40.107.7.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9E812008B for ; Wed, 26 Jun 2019 11:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QZLmpfxsGdJl225Ps6kHX4rJ4oxw0YElgWcDDxCdcug=; b=kbHJZaVEUUrfYwUtFUU/BOb8R20x2H5uBccNld8PfvSqV9Blkfw186m0MonYMQTJyZHsUhvP5f550DvCWd3/Z54Aas+aFIgjyJ+RsdHYTNbnKRSNkMTUDNlERUEJjZ+Rx3NXaD0vOgzK4onMMXAU5RlYsEl0mcKoyCtvB+NGpbw= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB4249.eurprd07.prod.outlook.com (20.176.166.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.13; Wed, 26 Jun 2019 18:47:00 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b5b8:de53:7372:dd2a]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b5b8:de53:7372:dd2a%7]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 18:47:00 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Klaus Hartke , core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUt?= =?utf-8?Q?senml-etch-03.txt?= Thread-Index: AQHVISBQHJvty1Er7US6KumrZJ3bDKaqu7GAgANdFACAAEQIAA== Date: Wed, 26 Jun 2019 18:47:00 +0000 Message-ID: <8112FF8E-1081-4766-9CD9-FDC38D55FB6B@ericsson.com> References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [2001:14bb:150:480b:8074:a92a:790c:2490] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0ca617e-b92c-4e69-a990-08d6fa66ac7b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4249; x-ms-traffictypediagnostic: HE1PR07MB4249: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(366004)(346002)(396003)(199004)(189003)(256004)(7736002)(6436002)(68736007)(81166006)(486006)(66476007)(73956011)(46003)(6246003)(66946007)(66616009)(66556008)(76116006)(64756008)(66446008)(102836004)(186003)(76176011)(81156014)(25786009)(85182001)(86362001)(6506007)(478600001)(6512007)(6306002)(99286004)(54896002)(99936001)(316002)(229853002)(71200400001)(110136005)(36756003)(5660300002)(8936002)(2616005)(11346002)(476003)(6116002)(446003)(6486002)(966005)(606006)(53936002)(2906002)(33656002)(14454004)(236005)(85202003)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4249; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kLxUSdlNTfprke1ZpTOZvp0ksfSrTGGv+plhJxe97+69jMR35IOw0X4r/0CeG3wiYj3S/7broNGwBI8CwZlytCMJvGyZ3PlS75szUBbNNmy7jOoUi2JbJIdJStWAuJS6jW4Pn+SH435rXAmt3ITIu0V2JcqME8N10ux1hgcCG6sVGz6/DzWnuZA0U7srZzcmBeaMhOgYw/AE4slAEaeIZ6T/wGm/FuooiFfes9P39b9uVxHezmNp/FpMyhHvX2AwVHBHJATvEJg3qI0SdcTNBpHR9AcgObBED1SvlkQPCpxD4W+9kdpyAc4s0aAWnXusuyPbu4jivvl30+fCnT1itnYFRM+XXlKseC6AftDOn7XZoNWEzXuP63fZ1Zm3harooD9ulnhx5wmPCYD9bolCXG9USn8hhkNMonlnkvI/y60= Content-Type: multipart/signed; boundary=Apple-Mail-4D8D0D5B-1C3F-42BE-8C5C-1C42168C7903; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0ca617e-b92c-4e69-a990-08d6fa66ac7b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 18:47:00.5588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ari.keranen@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4249 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-se?= =?utf-8?q?nml-etch-03=2Etxt?= 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, 26 Jun 2019 18:47:08 -0000 --Apple-Mail-4D8D0D5B-1C3F-42BE-8C5C-1C42168C7903 Content-Type: multipart/alternative; boundary=Apple-Mail-EB289882-063D-40F9-8568-16DCD374A3F9 Content-Transfer-Encoding: 7bit --Apple-Mail-EB289882-063D-40F9-8568-16DCD374A3F9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksDQoNCkhlcmXigJlzIG5vdyBhIFBSIHRoYXQgYWRkcmVzc2VzIGFsbCB0aGVzZSBjb21tZW50 czoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Nlbm1sLWV0Y2gvcHVsbC81L2ZpbGVzDQoN Ck1pY2hhZWwgUiBhbHNvIHBvaW50ZWQgb3V0IGEgYnVnIGluIHRoZSByZWZlcmVuY2VzLCB0aGF0 IHJldmVhbGVkIGFsc28gYSBidWcgaW4gdGhlIGV4YW1wbGVzLiBUaGlzIFBSIGZpeGVzIGJvdGgg aXNzdWVzOiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9zZW5tbC1ldGNoL3B1bGwvNi9maWxl cw0KDQoNCkNoZWVycywNCkFyaQ0KDQo+IE9uIDI2IEp1biAyMDE5LCBhdCAxNy40NCwgQXJpIEtl csOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gVGhhbmtzIEts YXVzISBTZWUgaW5saW5lLg0KPiANCj4+IE9uIDI0IEp1biAyMDE5LCBhdCAxNC4yMiwgS2xhdXMg SGFydGtlIDxoYXJ0a2VAcHJvamVjdGNvb2wuZGU+IHdyb3RlOg0KPj4gDQo+PiBJIGhhdmUgcGVy Zm9ybWVkIGEgcXVpY2sgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1zZW5tbC1ldGNoLTAzOg0K Pj4gDQo+PiAzLjIuICJGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBkb2N1bWVudCBjb3VsZCBi ZSBnaXZlbiBhcyAoaSlQQVRDSA0KPj4gcGF5bG9hZCB0byBjaGFuZ2Uvc2V0IHZhbHVlcyBvZiB0 d28gU2VuTUwgUmVjb3JkcyBmb3IgdGhlIGV4YW1wbGUgaW4NCj4+IFNlY3Rpb24gMToiIC0tIEl0 IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGV4YW1wbGUgZnJvbSBzZWN0aW9uIDEgd2FzDQo+PiBkdXBs aWNhdGVkIGhlcmUgYW5kIHRoZSByZW1vdmFsIG9mIGEgcmVjb3JkIHdhcyBzaG93bi4NCj4gDQo+ IE1ha2VzIHNlbnNlLCB3aWxsIGFkZCBleGFtcGxlIHRvIHRoZSBuZXh0IHJldmlzaW9uLg0KPiAN Cj4+IDUuMSAiQWxsIElEcyBhcmUgYXNzaWduZWQgZnJvbSB0aGUgIklFVEYgUmV2aWV3IG9yIElF U0cgQXBwcm92YWwiDQo+PiByYW5nZS4iIC0tIFJlbW92ZSB0aGlzIHNlbnRlbmNlLg0KPiANCj4g U2VuTUwgUkZDIChhbmQgb3RoZXJzKSBoYXZlIHVzZWQgc3VjaCBzZW50ZW5jZSB0byBpbmRpY2F0 ZSB0aGUgZGVzaXJlZCByYW5nZSwgYnV0IEnigJltIGZpbmUgbGVhdmluZyBpdCBvdXQgdG9vLg0K PiANCj4+IDUuMSAiVGFibGUgMTogQ29BUCBDb250ZW50LUZvcm1hdCBJRHMiIC0tIFRoaXMgdGFi bGUgaXMgbWlzc2luZyB0aGUNCj4+ICJDb250ZW50LUNvZGluZyIgKGYuay5hLiAiRW5jb2Rpbmci KSBjb2x1bW4uDQo+IA0KPiBHb29kIGNhdGNoOyB3aWxsIGFkZC4gSSBzdXBwb3NlIGl0IHdpbGwg YmUgc2ltcGx5IOKAnS3igJ0gZm9yIGJvdGguDQo+IA0KPj4gR2VuZXJhbCBxdWVzdGlvbnM6DQo+ PiANCj4+ICogSXQgc2VlbXMgdGhlIG5ldyBkYXRhIGZvcm1hdHMgYXJlIHN1cGVyc2V0cyBvZiB0 aGUgZXhpc3RpbmcgZGF0YQ0KPj4gZm9ybWF0cy4gQWxzbywgaXQgc2VlbXMgdGhlIHNhbWUgZGF0 YSBmb3JtYXQgaXMgdXNlZCBmb3IgZmV0Y2hpbmcgYW5kDQo+PiBwYXRjaGluZyBkYXRhLiBJcyB0 aGlzIHdoYXQgd2UsIGFzIENvUkUgV0csIHJlY29tbWVuZCAoMSBtZWRpYSB0eXBlDQo+PiBmb3Ig ZGF0YSwgMSBtZWRpYSB0eXBlIGZvciBmZXRjaGluZyBhbmQgcGF0Y2hpbmcpPyBDb1JBTCBpcyBk b2luZyBpdA0KPj4gZGlmZmVyZW50bHkgYXQgdGhlIG1vbWVudCBbMV0uDQo+PiANCj4+IFsxXSBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtlLXQydHJnLWNvcmFsLTA4I3Nl Y3Rpb24tNi43DQo+IA0KPiBDaHJpc3RpYW4gbWFkZSBzb21lIGdvb2Qgb2JzZXJ2YXRpb25zIG9u IHRoaXMgYWxyZWFkeS4gSSB3b3VsZCBub3QgdmlldyB0aGlzIGFzIGEgZ2VuZXJhbCBndWlkZWxp bmUgZWl0aGVyLiBCdXQgbGV04oCZcyBjb250aW51ZSBvbiB0aGF0IHRocmVhZCAoYW5kIGluIHRo ZSBjYWxsIHRvZGF5KS4NCj4gDQo+IA0KPiBDaGVlcnMsDQo+IEFyaQ0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0K PiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZQ0K --Apple-Mail-EB289882-063D-40F9-8568-16DCD374A3F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpLDxkaXY+PGJy PjwvZGl2PjxkaXY+SGVyZeKAmXMgbm93IGEgUFIgdGhhdCBhZGRyZXNzZXMgYWxsIHRoZXNlIGNv bW1lbnRzOjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2Vu bWwtZXRjaC9wdWxsLzUvZmlsZXMiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Nlbm1sLWV0 Y2gvcHVsbC81L2ZpbGVzPC9hPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TWljaGFlbCBSIGFs c28gcG9pbnRlZCBvdXQgYSBidWcgaW4gdGhlIHJlZmVyZW5jZXMsIHRoYXQgcmV2ZWFsZWQgYWxz byBhIGJ1ZyBpbiB0aGUgZXhhbXBsZXMuIFRoaXMgUFIgZml4ZXMgYm90aCBpc3N1ZXM6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2VubWwtZXRjaC9wdWxsLzYvZmls ZXMiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Nlbm1sLWV0Y2gvcHVsbC82L2ZpbGVzPC9h Pjxicj48YnI+PGJyPjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSIgZGlyPSJsdHIiPkNoZWVy cyw8ZGl2PkFyaTwvZGl2PjwvZGl2PjxkaXYgZGlyPSJsdHIiPjxicj5PbiAyNiBKdW4gMjAxOSwg YXQgMTcuNDQsIEFyaSBLZXLDpG5lbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyaS5rZXJhbmVuQGVy aWNzc29uLmNvbSI+YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPjxi cj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2IGRpcj0ibHRyIj48c3Bhbj5UaGFu a3MgS2xhdXMhIFNlZSBpbmxpbmUuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9uIDI0IEp1biAyMDE5LCBhdCAxNC4yMiwgS2xhdXMgSGFy dGtlICZsdDs8YSBocmVmPSJtYWlsdG86aGFydGtlQHByb2plY3Rjb29sLmRlIj5oYXJ0a2VAcHJv amVjdGNvb2wuZGU8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5JIGhhdmUgcGVyZm9ybWVkIGEgcXVpY2sgcmV2aWV3IG9mIGRy YWZ0LWlldGYtY29yZS1zZW5tbC1ldGNoLTAzOjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjMuMi4gIkZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIGRv Y3VtZW50IGNvdWxkIGJlIGdpdmVuIGFzIChpKVBBVENIPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+cGF5bG9hZCB0byBjaGFuZ2Uvc2V0IHZhbHVl cyBvZiB0d28gU2VuTUwgUmVjb3JkcyBmb3IgdGhlIGV4YW1wbGUgaW48L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5TZWN0aW9uIDE6IiAtLSBJdCB3 b3VsZCBiZSBuaWNlIGlmIHRoZSBleGFtcGxlIGZyb20gc2VjdGlvbiAxIHdhczwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmR1cGxpY2F0ZWQgaGVy ZSBhbmQgdGhlIHJlbW92YWwgb2YgYSByZWNvcmQgd2FzIHNob3duLjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TWFrZXMgc2Vuc2UsIHdpbGwgYWRkIGV4YW1w bGUgdG8gdGhlIG5leHQgcmV2aXNpb24uPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjUuMSAiQWxsIElEcyBhcmUgYXNzaWduZWQgZnJvbSB0 aGUgIklFVEYgUmV2aWV3IG9yIElFU0cgQXBwcm92YWwiPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+cmFuZ2UuIiAtLSBSZW1vdmUgdGhpcyBzZW50 ZW5jZS48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlNlbk1M IFJGQyAoYW5kIG90aGVycykgaGF2ZSB1c2VkIHN1Y2ggc2VudGVuY2UgdG8gaW5kaWNhdGUgdGhl IGRlc2lyZWQgcmFuZ2UsIGJ1dCBJ4oCZbSBmaW5lIGxlYXZpbmcgaXQgb3V0IHRvby48L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+NS4xICJU YWJsZSAxOiBDb0FQIENvbnRlbnQtRm9ybWF0IElEcyIgLS0gVGhpcyB0YWJsZSBpcyBtaXNzaW5n IHRoZTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu PiJDb250ZW50LUNvZGluZyIgKGYuay5hLiAiRW5jb2RpbmciKSBjb2x1bW4uPC9zcGFuPjxicj48 L2Jsb2NrcXVvdGU+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5Hb29kIGNhdGNoOyB3aWxsIGFkZC4g SSBzdXBwb3NlIGl0IHdpbGwgYmUgc2ltcGx5IOKAnS3igJ0gZm9yIGJvdGguPC9zcGFuPjxicj48 c3Bhbj48L3NwYW4+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkdlbmVyYWwgcXVl c3Rpb25zOjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu PiogSXQgc2VlbXMgdGhlIG5ldyBkYXRhIGZvcm1hdHMgYXJlIHN1cGVyc2V0cyBvZiB0aGUgZXhp c3RpbmcgZGF0YTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPmZvcm1hdHMuIEFsc28sIGl0IHNlZW1zIHRoZSBzYW1lIGRhdGEgZm9ybWF0IGlzIHVz ZWQgZm9yIGZldGNoaW5nIGFuZDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPnBhdGNoaW5nIGRhdGEuIElzIHRoaXMgd2hhdCB3ZSwgYXMgQ29SRSBX RywgcmVjb21tZW5kICgxIG1lZGlhIHR5cGU8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5mb3IgZGF0YSwgMSBtZWRpYSB0eXBlIGZvciBmZXRjaGlu ZyBhbmQgcGF0Y2hpbmcpPyBDb1JBTCBpcyBkb2luZyBpdDwvc3Bhbj48YnI+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmRpZmZlcmVudGx5IGF0IHRoZSBtb21lbnQg WzFdLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu Pjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlsx XSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtlLXQydHJn LWNvcmFsLTA4I3NlY3Rpb24tNi43Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGFydGtlLXQydHJnLWNvcmFsLTA4I3NlY3Rpb24tNi43PC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+Q2hyaXN0aWFuIG1hZGUgc29tZSBnb29kIG9ic2Vy dmF0aW9ucyBvbiB0aGlzIGFscmVhZHkuIEkgd291bGQgbm90IHZpZXcgdGhpcyBhcyBhIGdlbmVy YWwgZ3VpZGVsaW5lIGVpdGhlci4gQnV0IGxldOKAmXMgY29udGludWUgb24gdGhhdCB0aHJlYWQg KGFuZCBpbiB0aGUgY2FsbCB0b2RheSkuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFu Pjwvc3Bhbj48YnI+PHNwYW4+Q2hlZXJzLDwvc3Bhbj48YnI+PHNwYW4+QXJpPC9zcGFuPjwvZGl2 PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2IGRpcj0ibHRyIj48c3Bh bj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 YnI+PHNwYW4+Y29yZSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0 bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Js b2NrcXVvdGU+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-EB289882-063D-40F9-8568-16DCD374A3F9-- --Apple-Mail-4D8D0D5B-1C3F-42BE-8C5C-1C42168C7903 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDMAw ggX2MIID3qADAgECAhA3E3FzLlznzicd63Rv9v4YMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMDQxNDEzNDRaFw0yMDEyMDQxNDEzNDNaMGUxETAPBgNVBAoMCEVyaWNzc29u MRUwEwYDVQQDDAxBcmkgS2Vyw6RuZW4xJzAlBgkqhkiG9w0BCQEWGGFyaS5rZXJhbmVuQGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWFyaWtlcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AIUlV66I5z1/qGYdhiIGfyvv8aaZexDetFCPlauUh5ugtp7Pf7ynpPRIK1FeWaoKs+IJ3E9R/9wT APFzjzjXpjyHHoBUdp8ZBuL/kt60cUTHTD4AScJGUHEgy70/Uf2YEj3JJjrTBbFnqDcXWTFF1n2Y edmhZDBdzZQJ18tlIjJmxgAJB1clI0nEg1gBnhl8mVdQp+ar6GjvxXfRuA1+uOpxa3y4zUpzF+ha LmaC4a5AbOsROtr7Uad8/pCzulAvAmPXvEJ/3JusafQfiqxNv1J/fT6W7sS8dBjF6vv3LgeAnYj5 /imtl9BOurFol0aIic+AjptfNoVf2pDhgYxn808CAwEAAaOCAb4wggG6MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCMGA1UdEQQcMBqBGGFyaS5rZXJhbmVuQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB BQUHAwIwHQYDVR0OBBYEFNHQXDyNP/SSyF6+EMLvo07phb3FMB8GA1UdIwQYMBaAFBx7GZ6XnHas ID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAVVggYWTwdz5B iMeBRYLop6Jo3Ji9YmfonCRFiyfw8he+efYc59IwzU9eIBRFSiWf87eqcZZJjcwWjHuju3MvzWsp 1qHnirszOtcNrUflFBoY7N3r19tG+z2bE/bjjZPituSIgCoX28IgLZLpIcnYg7niWXnwR3xGiphs EPO3mR3p7f+XLtdy+1qU/rAjZoW36mZuYk1lV6nIt9GfhuH1/yIQd5pxTDj54j3TOLv/KrEKwCFQ YLkho6zrOicpJk7DkjYGNLwmaDTRxuehMQHKDW+fXi1xi7/eScV0YnELjxXGuE3HojEkLB8Offfa /5TICfBN2HTASXJ0YsbpnAxPTyjExmKzl3mudQz6x5wP6THhM0sltX8wHVQEhU5w0uyLfT9yqWVY KTq+9GI02S9kzD+u1AWtftbWK2CQIGUAE43faZGrCchkT+fnYz5b1Ppyf5H45r/psmsA9J63iFCz nilKlo9M47fQPEsqpFWvDfE4jdobqSmQXp/aK7cvYoAEhcj5vOqR/bPNum7wWegQZdDsfy35vZl8 +vtRrKAk/6bmUfaiazqQoGq+DF1OL7sQlb1HbMmkJblrrBf8Csh6wdEVFey6vegBSIwtOnmcAFN9 2NlKp24f8rJxM17M9pWNG6OsmCGhxyo4k1BHn69nXXQfSN7QdqLpGfhQfpJL3LgwggbCMIIEqqAD AgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29u ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1 MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cY VVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUg MKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwN v/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZq QvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/ KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpX bxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6O Moc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOq QFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3Nw LnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYB Af8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9y ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0 cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQc exmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkq hkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bO ULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQk MrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiR sehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSr Z4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZ oviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4 gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCF z/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb 8ToH7WLoOzmPRCmPlpAxggLNMIICyQIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBglghkgBZQMEAgEFAKCCAUMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTkwNjI2MTg0NjU2WjAvBgkqhkiG9w0BCQQxIgQgYh/p2zpIhOpid0Z61Im0xxEP o8G9IJaeBGbPgKvrd7swagYJKwYBBAGCNxAEMV0wWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfO Jx3rdG/2/hgwbAYLKoZIhvcNAQkQAgsxXaBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBgkqhkiG9w0BAQEFAASCAQBztPIF/HO5XjOsxXgu4Zvc/72ZkF1saGRAK6kzp8yf9X5U pn7NNOIvYrMh5eek6LWYL4qrAfcQE8Nu3Q7zrnNM//4t1SecIvmBJyH298C+ecqZgrNllKB5pxWT c6zMlGewU0E7Y4uWYOxfG50WAQyGFdg0St4ex9fgwBJ4nb/h9DFA5UrR+U6gN+7ZVC09jKwCW+P1 xMVR4/x7tNJoeAtx/PtPYNW8OlSnj1JumhRn2Xq1AfoeFVoi69jjklK0Li/Ey5HZt/XtU/pjSY2a qz+SCkjVPDuSMc/fn16CNZDm5Zp+lBvyuffpnC+iiIDVu++32ZQwCq2BsW1ot79g3a/nAAAAAAAA --Apple-Mail-4D8D0D5B-1C3F-42BE-8C5C-1C42168C7903-- From nobody Wed Jun 26 22:19:51 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4812006D for ; Wed, 26 Jun 2019 22:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 QW7-HdkTQva5 for ; Wed, 26 Jun 2019 22:19:45 -0700 (PDT) Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E2C12012E for ; Wed, 26 Jun 2019 22:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1561614996; x=1593150996; h=mime-version:in-reply-to:references:subject:from:to: message-id:date; bh=6+/zK5kk0Y5A0f2XoYR8S5u6MifNLKo1y0YdAnI5jXA=; b=SkQosXw0WI7AmtqwDLSCXUdq3FHs8tCwf+uwkOvlhEKpGwAc63R8jdhO MU8XZioxeAf8vPMTQudH1umbQmKtvBHdAYZ6WxHWwYlJ+44MbNH42pN1/ V6rRZEQ/hPz+0DX8aSJuhLVWyTPOI+HLyfnNT42TJTZq1xE5dHuR38dv/ LL/bsXO4GfwMe+6+SrzCi+fMyrqGhT885e67BpPhlNbb8IeTfBTkaO2Xc 8dxIujte9A2na3f2o/Sq7Q6h/33/1cVpXD5Y+REKXUiFjKD3GLOV6b2bF Nvjqerfq9yDiDMHeuj/abOowp6JUkIBrk9adCbrnafk6GWtqBEut2wf+c w==; IronPort-PHdr: =?us-ascii?q?9a23=3A8hQOMxLDwvauzC5nrtmcpTZWNBhigK39O0sv0r?= =?us-ascii?q?FitYgXKvT6rarrMEGX3/hxlliBBdydt6sezbOJ+PG6ESxYuNDd6SlEKMQNHz?= =?us-ascii?q?Y+yuwu1zQ6B8CEDUCpZNXLVAcdWPp4aVl+4nugOlJUEsutL3fbo3m18CJAUk?= =?us-ascii?q?6nbVk9Kev6AJPdgNqq3O6u5ZLTfx9IhD2gar9uMRm6twrcutQIjYd4N6o8yB?= =?us-ascii?q?TFr39Wd+9LwW9kOU+fkwzz68ut4ZJv6Thct+4k+8VdTaj0YqM0QKBCAj87KW?= =?us-ascii?q?41/srrtRfCTQuL+HQRV3gdnwRLDQbY8hz0R4/9vSTmuOVz3imaJtD2QqsvWT?= =?us-ascii?q?u+9adrSQTnhzkBOjUk7WzYkM1wjKZcoBK8uxxyxpPfbY+JOPZieK7WYMgXTn?= =?us-ascii?q?RdUMlPSyNBA5u8b4oRAOoHIeZYtJT2q18XoRejGQWgGObjxzlVjXH0wKI6yf?= =?us-ascii?q?wsHg7F0wI6Hd0OvmnaotXrOqkRX+67y7XHwC7ZYP9Kwzrw8ozIfgw8rfyKQL?= =?us-ascii?q?l+cdDRyU4qFw7dklifsozlPzKX1usXtWiQ8vdtVeK1hG47twF+uCSgxsc2hY?= =?us-ascii?q?nThoMUykrL/jh+zYkvPtK4SE97Ydy+H5tWrS2VLIt2Tdk+Q2F0oik11r0Gto?= =?us-ascii?q?ShfCkKyJUo3QXSa+CbfIiT+B7sSOGRITJhiX9jZbmxiRGy8U26xe39UMm5yF?= =?us-ascii?q?dKoTRZktnCrHwN0AbT6sefRvth4kihwiyD2BzU6uFBJ00/iKnVK4Y5z7ItlJ?= =?us-ascii?q?cfr17PEjHrlEnsgqKaaF8o9+ms5unhf77ovIWTN5VuhQH7Kqkun8u/DvkmPQ?= =?us-ascii?q?UWRGib/Pi81KXk/U3kXLVGlv02nbfdsJDdPckVpba3DQFa3Igl8xixATSo3t?= =?us-ascii?q?cWk3cBNlxLfwyJgpT0N13WIfD4C+mwg0i0nTt2xf3KIKftDovQInTZnrrtY6?= =?us-ascii?q?xx5k9YxQYryNBQ/ZNUCrUPIPLpXU/xscTVAQUiPAy0wubnCs9y1oUEVW2UAq?= =?us-ascii?q?+WKr/SsUOS6e0zI+mDfpUVuTb9Kvc//PPukWM2mUQHcaa12psXbWi0Hu56LE?= =?us-ascii?q?WBfXrsntABHH8WsQo5VuzllkaPUT9NaHauUaIw/DY7CJipDY3bXICinKSB3D?= =?us-ascii?q?unHp1Rfm1JFkqDHmzvd4ifR/cNaSOSLtVmkjweWrirU5Uh2g22tA/m17pnKf?= =?us-ascii?q?LZ+iMCtZ39ydd1/ezTlRIo+T16Ecud3H+CT2V1nmwVXDI30qF/oVBhyleZy6?= =?us-ascii?q?d0medYGsIAr89OBykgOJLGzu8yNN39VwbAcp/dRkyrTs+nAncuQ908x94CS1?= =?us-ascii?q?l8B8m4h1bY0nzuS5QcjaeXCZp82KXG2nH3IY4pwH/M04E9nVhgRdFAYynuja?= =?us-ascii?q?ll+kCHDInTnm2YmrqkM6MG03ie2n2EyD+ntkFZUgd2GY/FVGwDb0DWpM7o90?= =?us-ascii?q?qKG7akCbUlOw0Hw86LNrdDYd3gl0RXTd//M8+YaGW0zTTjTS2Uz6+BOdK5M1?= =?us-ascii?q?4W2z/QXQ1dy1ge?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AFAACWThRd/0UgFaxlGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBZ4EZgSyEe5QdmGwUgWcJAQEBAQEBAQEBIAE?= =?us-ascii?q?KDAEBhEACgyA1CA4BAwEBBQEBAQEFAYsjDII6KQGCZgEBAQMBAQElQAcQCwU?= =?us-ascii?q?GDQQDAQIBJwcnHwkIBgEJAQgRCoMHAYF7HqQsAQEBgW4zhDYChD6BRoE0AYt?= =?us-ascii?q?/aA9+gRGDEj6BBIFdAQEDgSsBEgEJNoMYBIImBIwNJwOIV4cbjXcHAoIZXYV?= =?us-ascii?q?1hGSDeQWEWYIqhxKOGo0phzeRXgKBG3FwUIJsCYJEDAuDTYUUhUdqjGyCQwE?= =?us-ascii?q?B?= X-IPAS-Result: =?us-ascii?q?A2AFAACWThRd/0UgFaxlGgEBAQEBAgEBAQEHAgEBAQGBV?= =?us-ascii?q?AQBAQEBCwGBZ4EZgSyEe5QdmGwUgWcJAQEBAQEBAQEBIAEKDAEBhEACgyA1C?= =?us-ascii?q?A4BAwEBBQEBAQEFAYsjDII6KQGCZgEBAQMBAQElQAcQCwUGDQQDAQIBJwcnH?= =?us-ascii?q?wkIBgEJAQgRCoMHAYF7HqQsAQEBgW4zhDYChD6BRoE0AYt/aA9+gRGDEj6BB?= =?us-ascii?q?IFdAQEDgSsBEgEJNoMYBIImBIwNJwOIV4cbjXcHAoIZXYV1hGSDeQWEWYIqh?= =?us-ascii?q?xKOGo0phzeRXgKBG3FwUIJsCYJEDAuDTYUUhUdqjGyCQwEB?= X-IronPort-AV: E=Sophos; i="5.63,422,1557167400"; d="scan'208,217"; a="52150961" MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se> References: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se>, <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> From: Abhijan Bhattacharyya To: Fredrik Wegelid , Carsten Bormann , core Message-ID: Date: Thu, 27 Jun 2019 10:48:26 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP10HF213 April 26, 2018 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 06/27/2019 10:48:26, Serialize complete at 06/27/2019 10:48:27, Itemize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 06/27/2019 10:48:27, Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 06/27/2019 10:48:30, Serialize complete at 06/27/2019 10:48:30 Content-Type: multipart/alternative; boundary="=_alternative 001D277165258426_=" Archived-At: Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 05:19:49 -0000 --=_alternative 001D277165258426_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fredrick and Carsten, Thanks for the discussion so far. Let me put my thoughts. The proposal to reduce the traffic in case of block-wise transfer using no-= response is obvious. However, there is a catch. As per my understanding, th= e use case considered for block-wise transfer relates to transfers demandin= g high integrity of the received data and very low complexity at the receiv= ing end in re-assembling the segments. One example is firmware upgrade of r= emote sensors: you cannot miss a single bit. Also, the message reception is= tightly sequential in order. In case you miss one segment or receive in ou= t-of-order, the transfers seizes in between. Now, Fredrick, coming to your solution: I do not know the QoS requirements = in your perceived use case. You do not care about responses of intermediate= blocks (essentially this means RESTfully fire-and-forget!) and you take th= e response of the last block to ensure the end of transfer. Now the questio= n is, if you care for all the blocks at the receiving end (for which you di= d not care for a response) how do you ensure reception of all the blocks? C= onsidering the resource constrains in IoT use cases it will be a wastage of= bandwidth if you have sent all the segments from the transmit end and the = receiver, after receiving the end block, realizes that one intermediate seg= ment got missing. The whole transfer, and the resource consumption related = to that, becomes useless. You might have rather stopped at the loss instanc= e and take corrective measures to resume. That would save your resources. S= o, there something more to think and design carefully according to the exac= t QoS requirements of the perceived class of use-cases. However, in case you are looking for real-time + low-latency + low-resource= consuming transfer, you may please have a look at this proposal that we al= ready submitted few months back: https://tools.ietf.org/html/draft-bhattach= aryya-core-a-realist-02 . To relate this draft to your problem you may simp= ly consider to model your block-wise traffic as a time-series traffic. Having said that, I did once nurture some ideas to make block-wise transfer= "statistically" more resource-efficient, yet reliable . But, must I be con= firmed about the efficacy of my idea, both theoretically and experimentally= , before I speak about that. I have kept that in back burner. In case there= is enough interest I can renew the interest and discuss. Thank you. = With Best Regards Abhijan Bhattacharyya Consultant / Scientist, {Internet Protocols | 5G | Standardization}, = TCS Research, Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33 66884691 Cell:- +919830468972 | +918583875003 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"core" wrote: ----- To: Carsten Bormann From: Fredrik Wegelid = Sent by: "core" = Date: 06/26/2019 05:28PM Cc: core Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfe= rs in CoAP "External email. Open with Caution" Hi Carsten, This is how an example looks like without the No-Response option. Client -> Server: NON POST Payload: “Block 1...” Server -> Client: NON 2.31 Continue Client -> Server: NON POST Payload: “Block 2...” Server -> Client: NON 2.31 Continue More blocks… Client -> Server: NON POST Payload: “Final block...” Server -> Client: NON 2.01 Created (As an example) With the No-Response option I wish the exchange to look something like this: Client -> Server: NON POST (No-Response:26) Payload: “Block 1...̶= 1; Client -> Server: NON POST (No-Response:26) Payload: “Block 2...̶= 1; More blocks… Client -> Server: NON POST Payload: “Final block...” Server -> Client: NON 2.01 Created (As an example) This would mean that the server would not send the 2.31 responses for each = block (as the No-Response option is set to 26) while it still would send th= e final response (since the final block does not have the No-Response optio= n set). This allows the client to ensure that all blocks were sent successfully. If= they are not, the server would respond with another code. It would also me= an that the amount of traffic on the network is reduced. Best regards, Fredrik > On 26 Jun 2019, at 13:43, Carsten Bormann wrote: > = > Hi Fredrik, > = > I’m not sure I entirely understand the message exchanges you envisi= on; maybe you can provide an example. > = > RFC 7967 has a way to suppress responses based on the response code. > Unfortunately, the granularity is on the class only at the moment. > The option that carries this information isn’t explicitly defined a= s an extension point. Still, someone (the original author? The WG?) might= want to go ahead, e.g., by defining a bit in the option value that says &#= 8220;Not interested in 2.31 responses”. (Maybe we want to understand= what exactly a client would not be interested in a bit more before we go a= head allocating bits like this.) > = > Abhijan, what do you think? > = > Gr=FC=DFe, Carsten > = > = >> On Jun 26, 2019, at 13:30, Fredrik Wegelid w= rote: >> = >> Hi, >> = >> I hope that I am using this email list in the correct way. I apologise i= f that is not the case. >> I have some questions/thoughts about using the No-Response option (RFC 7= 967) together with block-wise transfers in COAP. >> = >> In my team we are using CoAP to send messages from devices to a server. = The messages are of such a size that we need to make block-wise transfers. = In an attempt to reduce the amount of traffic in the network we have looked= at using the No-Response option. We are however not clear on how this woul= d work if used together with block-wise transfers. We would like to use the= No-Response option to make the server omit the 2.31 Continue responses fro= m the server on each block. We would however still like to be able to get a= response on the last block to indicate the status of the entire block sequ= ence. = >> = >> Does this make sense? In RFC 7967 block-wise transfers are not mentioned= . Are they meant to be used together? >> = >> Best regards, >> Fredrik Wegelid >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> = > = _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 001D277165258426_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Fredrick and Carsten,
Thanks for the discussion so= far. Let me put my thoughts.

The proposal to redu= ce the traffic in case of block-wise transfer using no-response is obvious.= However, there is a catch. As per my understanding, the use case considere= d for block-wise transfer relates to transfers demanding high integrity of = the received data and very low complexity at the receiving end in re-assemb= ling the segments. One example is firmware upgrade of remote sensors: you c= annot miss a single bit. Also, the message reception is tightly sequential = in order. In case you miss one segment or receive in out-of-order, the tran= sfers seizes in between.

Now, Fredrick, coming to = your solution: I do not know the QoS requirements in your perceived use cas= e. You do not care about responses of intermediate blocks (essentially this= means RESTfully fire-and-forget!) and you take the response of the last bl= ock to ensure the end of transfer. Now the question is, if you care for all= the blocks at the receiving end (for which you did not care for a response= ) how do you ensure reception of all the blocks? Considering the resource c= onstrains in IoT use cases it will be a wastage of bandwidth if you have se= nt all the segments from the transmit end and the receiver, after receiving= the end block, realizes that one intermediate segment got missing. The who= le transfer, and the resource consumption related to that, becomes useless.= You might have rather stopped at the loss instance and take corrective mea= sures to resume. That would save your resources. So, there something more t= o think and design carefully according to the exact QoS requirements of the= perceived class of use-cases.

However, in case yo= u are looking for real-time + low-latency + low-resource consuming transfer= , you may please have a look at this proposal that we already submitted few= months back: https://tools.ietf.org/html/draft-bhatta= charyya-core-a-realist-02 . To relate this draft to your problem you ma= y simply consider to model your block-wise traffic as a time-series traffic= .

Having said that, I did once nurture some ideas = to make block-wise transfer "statistically" more resource-efficient, yet re= liable . But, must I be confirmed about the efficacy of my idea, both theor= etically and experimentally, before I speak about that. I have kept that in= back burner. In case there is enough interest I can renew the interest and= discuss.

Thank you.     

With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization},
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: = abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________


-----"core" <core-bounces@ietf.org> = wrote: -----
To: Carsten Bormann <cabo@tzi.org>
From: Fredrik Wegelid
Sent by: "core"
Date: 06/26/2019 05:28PMCc: core <core@ietf= .org>
Subject: Re: [core] RFC 7967 (No-Response) together with bl= ock-wise transfers in CoAP

"External email. Open with Caution"

Hi Carsten,<= br>
This is how an example looks like without the No-Response option.
Client -> Server: NON POST Payload: “Block 1...”
Se= rver -> Client: NON 2.31 Continue
Client -> Server: NON POST Payl= oad: “Block 2...”
Server -> Client: NON 2.31 Continue
=
More blocks…

Client -> Server: NON POST Payload: ̶= 0;Final block...”
Server -> Client: NON 2.01 Created (As an exa= mple)

With the No-Response option I wish the exchange to look someth= ing like this:

Client -> Server: NON POST (No-Response:26) Paylo= ad: “Block 1...”
Client -> Server: NON POST (No-Response= :26) Payload: “Block 2...”

More blocks…

Cli= ent -> Server: NON POST Payload: “Final block...”
Server= -> Client: NON 2.01 Created (As an example)

This would mean that= the server would not send the 2.31 responses for each block (as the No-Res= ponse option is set to 26) while it still would send the final response (si= nce the final block does not have the No-Response option set).
This allo= ws the client to ensure that all blocks were sent successfully. If they are= not, the server would respond with another code. It would also mean that t= he amount of traffic on the network is reduced.

Best regards,
Fre= drik

> On 26 Jun 2019, at 13:43, Carsten Bormann <cabo@tzi.org> wrote:
> <= br>> Hi Fredrik,
>
> I’m not sure I entirely understa= nd the message exchanges you envision; maybe you can provide an example.>
> RFC 7967 has a way to suppress responses based on the respon= se code.
> Unfortunately, the granularity is on the class only at the= moment.
> The option that carries this information isn’t expli= citly defined as an extension point.  Still, someone (the original aut= hor?  The WG?) might want to go ahead, e.g., by defining a bit in the = option value that says “Not interested in 2.31 responses”. &nbs= p;(Maybe we want to understand what exactly a client would not be intereste= d in a bit more before we go ahead allocating bits like this.)
>
= > Abhijan, what do you think?
>
> Gr=FC=DFe, Carsten
>= ;
>
>> On Jun 26, 2019, at 13:30, Fredrik Wegelid <fredrik.wegelid@= wittra.se> wrote:
>>
>> Hi,
>>
>&= gt; I hope that I am using this email list in the correct way. I apologise = if that is not the case.
>> I have some questions/thoughts about u= sing the No-Response option (RFC 7967) together with block-wise transfers i= n COAP.
>>
>> In my team we are using CoAP to send messa= ges from devices to a server. The messages are of such a size that we need = to make block-wise transfers. In an attempt to reduce the amount of traffic= in the network we have looked at using the No-Response option. We are howe= ver not clear on how this would work if used together with block-wise trans= fers. We would like to use the No-Response option to make the server omit t= he 2.31 Continue responses from the server on each block. We would however = still like to be able to get a response on the last block to indicate the s= tatus of the entire block sequence.
>>
>> Does this mak= e sense? In RFC 7967 block-wise transfers are not mentioned. Are they meant= to be used together?
>>
>> Best regards,
>> Fr= edrik Wegelid
>> _______________________________________________>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core>>
>

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

=3D=3D=3D= =3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 001D277165258426_=-- From nobody Wed Jun 26 23:40:31 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36921120163 for ; Wed, 26 Jun 2019 23:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90cV--xeKhze for ; Wed, 26 Jun 2019 23:40:25 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65434120139 for ; Wed, 26 Jun 2019 23:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=63CZrSANInCgFeFB2e5Nq01sbZT+pCv6XfMViyYauhY=; b=HGZZJXDHrKvKVl9lYo99FFVOost/24jEjsiSDoqQ19htPeWNdyPAmrC0ev1RCd3NUFnacCtyHm8gyw2DJEamFhjF/zQ3jWNNXSv1Cj02TKG2Yk1jPQ5UrzSqSB4k+yUE8/I0zj/INANn0AZoeURndg2/DowEOaikz1kHaghVS6c= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.4.202) by AM6PR08MB4438.eurprd08.prod.outlook.com (20.179.7.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.17; Thu, 27 Jun 2019 06:40:22 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::6897:93dc:1fd:e091]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::6897:93dc:1fd:e091%4]) with mapi id 15.20.2008.017; Thu, 27 Jun 2019 06:40:22 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: Review of draft-ietf-core-stateless-01 Thread-Index: AQHVLLMxToMq11Zc9kiaekqUOr8c3A== Date: Thu, 27 Jun 2019 06:40:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [62.254.132.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 351a5227-bd4f-4bbf-5ec0-08d6faca5449 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4438; x-ms-traffictypediagnostic: AM6PR08MB4438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39860400002)(136003)(346002)(396003)(189003)(199004)(40434004)(25786009)(486006)(86362001)(476003)(2906002)(4326008)(2616005)(6916009)(1730700003)(71200400001)(71190400001)(6116002)(3846002)(81166006)(81156014)(8936002)(91956017)(53936002)(478600001)(36756003)(6486002)(6436002)(68736007)(6512007)(5640700003)(8676002)(76116006)(102836004)(14444005)(256004)(316002)(5024004)(73956011)(186003)(99286004)(66066001)(66946007)(33656002)(66446008)(305945005)(64756008)(66476007)(66556008)(7736002)(14454004)(2501003)(2351001)(5660300002)(72206003)(6506007)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4438; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: d4eBvmP/3lWZXJ8cg2tmfDKGg4XUK3YazqJqCIw5HQMTnSqK5QqJRFVBs6vM9+aTJU4xBzh7/ISx+d/ZXxBLmxYZYEnB0X11LGmSDhvcRlpZPGzT+MuoB7NjEN9Qhi+n1L1eAGIahmpa/JKV7F0JTaUbLGb6kqU9ddLF5t2ySiy3ov7tf/Ae6ANWzbi4ew9LdIdxFFKxraFYEo5Y6qfRFGYJsoYOlRcLAoAPrPPP76IJi81roWPtqsce6CIoW9kYQUiJsKwL/U7KIfDG1SWwHmusEJgu3j9oqktyNEtBAJfASM87Dauk1YZgCUPX85uVvOZX/nez7jt1uTMd+1QH8VZ9Lnq/nrRZlKbAtsHfi8LrQ0jfx9Wj8g2kX5S8CbxFRBrtAhsLzV2DJGSkGhU6Z5y8Fls31jJs7rPlLMCzFl8= Content-Type: text/plain; charset="utf-8" Content-ID: <567E6C64B33EF44EB77327EE2292689D@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 351a5227-bd4f-4bbf-5ec0-08d6faca5449 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 06:40:22.3276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Thomas.Fossati@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4438 Archived-At: Subject: [core] Review of draft-ietf-core-stateless-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 06:40:29 -0000 SGkgS2xhdXMsDQoNCihGb2N1c2luZyBzb2xlbHkgb24gdGhlIHNlY3VyaXR5IGFzcGVjdHMgb2Yg dGhlIHByb3RvY29sLikNCg0KU2VjdGlvbiA0LjE6DQoNCiAgIEEgbm9kZSBpbiB0aGUgc2VydmVy IHJvbGUgc3VwcG9ydGluZyBleHRlbmRlZCB0b2tlbiBsZW5ndGhzIG1heSBiZQ0KICAgdnVsbmVy YWJsZSB0byBhIGRlbmlhbC1vZi1zZXJ2aWNlIHdoZW4gYW4gYXR0YWNrZXIgKGVpdGhlciBvbi1w YXRoIG9yDQogICBhIG1hbGljaW91cyBjbGllbnQpIHNlbmRzIGxhcmdlIHRva2VucyB0byBmaWxs IHVwIHRoZSBtZW1vcnkgb2YgdGhlDQogICBub2RlLiAgSW1wbGVtZW50YXRpb25zIE1VU1QgYmUg cHJlcGFyZWQgZm9yIHRoaXMgYW5kIG1pdGlnYXRlIGl0Lg0KDQpJJ20gaGF2aW5nIGEgYml0IG9m IHRyb3VibGUgbWFraW5nIHNlbnNlIG9mIHRoaXMgbGFzdCBzZW50ZW5jZToNCg0KMS4gSXQgZG9l c24ndCBwcm92aWRlIGhlbHBmdWwgYWR2aWNlIG9uIGhvdyB0byAicHJlcGFyZSBmb3IiIGFuZC9v cg0KICAgIm1pdGlnYXRlIjsNCg0KMi4gVGhlICJNVVNUIGJlIHByZXBhcmVkIiBwYXJ0IGxvb2tz IGxpa2UgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uDQogICByZW1hcmsgcmF0aGVyIHRoYW4g YW4gaW50ZXJvcCByZXF1aXJlbWVudCB0aGF0IHJlcXVpcmVzIEJDUDE0DQogICBsYW5ndWFnZS4N Cg0KSSBzdWdnZXN0IHRvIHJlbW92ZSB0aGUgTVVTVCBmcm9tICJwcmVwYXJlIGZvciIgYW5kIGV4 cGxhaW4gcHJhY3RpY2FsbHkNCndoYXQgdGhhdCBtZWFucywgZS5nLjogIkltcGxlbWVudGF0aW9u cyBzaG91bGQgZGVmaW5lIGEgbG9jYWwgdXBwZXINCmJvdW5kIGZvciB0aGUgdG9rZW4gc2l6ZSB0 aGF0IGlzIGNvbmZpZ3VyYWJsZSBiYXNlZCBvbiB0aGUgbm9kZSdzDQphdmFpbGFibGUgcGh5c2lj YWwgbWVtb3J5LiIgIFRoZW4gZXhwbGFpbiB3aGF0ICJtaXRpZ2F0ZSIgbWVhbnMgaW4NCnByb3Rv Y29sIHRlcm1zLCBlLmcuOiAiUmVxdWVzdHMgZXhjZWVkaW5nIHRoaXMgbGltaXQgTVVTVCBiZSBy ZWplY3RlZA0Kd2l0aCBzdGF0dXMgNC5YWCwgcmVzcG9uc2VzIGV4Y2VlZGluZyB0aGlzIGxpbWl0 IE1VU1QgYmUgc2lsZW50bHkNCmRpc2NhcmRlZC4iLCBvciBzaW1pbGFyLg0KDQpTZWN0aW9uIDQu MjoNCg0KICAgVHJhbnNwb3J0aW5nIHRoZSBzdGF0ZSBuZWVkZWQgYnkgYSBjbGllbnQgdG8gcHJv Y2VzcyBhIHJlc3BvbnNlIGFzDQogICBzZXJpYWxpemVkIHN0YXRlIGluZm9ybWF0aW9uIGluIHRo ZSB0b2tlbiBoYXMgc2V2ZXJhbCBzaWduaWZpY2FudCBhbmQNCiAgIG5vbi1vYnZpb3VzIHNlY3Vy aXR5IGFuZCBwcml2YWN5IGltcGxpY2F0aW9ucyB0aGF0IG5lZWQgdG8gYmUNCiAgIG1pdGlnYXRl ZC4NCg0KTWF5YmUgcy9taXRpZ2F0ZS9hZGRyZXNzZWQvID8gQnV0IG92ZXJhbGwgdGhpcyBwYXJh Z3JhcGggZG9lc24ndCBzZWVtIHRvDQphZGQgbXVjaDogSSBzdWdnZXN0IHRvIGRyb3AgaXQgYWx0 b2dldGhlciBhbmQgc3RhcnQgdGhpcyBzZWN0aW9uIHN0cmFpZ2h0DQpmcm9tIHRoZSBzZWNvbmQg cGFyYS4NCg0KICAgU2VyaWFsaXplZCBzdGF0ZSBpbmZvcm1hdGlvbiBpcyBhbiBhdHRyYWN0aXZl IHRhcmdldCBmb3IgYm90aA0KICAgdW53YW50ZWQgbm9kZXMgKGF0dGFja2VycyBiZXR3ZWVuIHRo ZSBub2RlIGluIGNsaWVudCByb2xlIGFuZCB0aGUNCiAgIG5leHQgaG9wKSBhbmQgd2FudGVkIG5v ZGVzICh0aGUgbmV4dCBob3AgaXRzZWxmKSBvbiB0aGUgcGF0aC4NCg0KVGhpcyBkaXN0aW5jdGlv biBiZXR3ZWVuIHdhbnRlZC91bndhbnRlZCBzb3VuZHMgYSBiaXQgZnVubnksIGJlc2lkZXMgdGhl DQp0ZXJtcyBhcmUgZGVmaW5lZCBoZXJlIGJ1dCBuZXZlciB1c2VkIGluIHRoZSByZW1haW5kZXIu ICBNeSBzdWdnZXN0aW9uDQp3b3VsZCBiZSB0byByZW1vdmUgdGhlbSBhbmQgaW5zdGVhZCBzYXkg c29tZXRoaW5nIGxpa2U6ICJTZXJpYWxpemVkDQpzdGF0ZSBpbmZvcm1hdGlvbiBpcyBhbiBhdHRy YWN0aXZlIHRhcmdldCBmb3IgYm90aCByZWxheWluZyBub2RlcyBhbmQNCnBhc3NpdmUgb2JzZXJ2 ZXJzLiINCg0KICAgVGhlcmVmb3JlLCBhIG5vZGUgaW4gdGhlIGNsaWVudCByb2xlIE1VU1QgaW50 ZWdyaXR5IHByb3RlY3QgdGhlIHN0YXRlDQogICBpbmZvcm1hdGlvbiwgdW5sZXNzIHByb2Nlc3Np bmcgYSByZXNwb25zZSBkb2VzIG5vdCBtb2RpZnkgc3RhdGUgb3INCiAgIGNhdXNlIG90aGVyIHNp Z25pZmljYW50IHNpZGUgZWZmZWN0cy4NCg0KICAgWy4uLl0gVGhlcmVmb3JlLCB0aGUgbm9kZSBp biBjbGllbnQgcm9sZSBNVVNUDQogICBpbXBsZW1lbnQgcmVwbGF5IHByb3RlY3Rpb24gKGUuZy4s IGJ5IHVzaW5nIHNlcXVlbmNlIG51bWJlcnMgYW5kIGENCiAgIHJlcGxheSB3aW5kb3cpLCB1bmxl c3MgcHJvY2Vzc2luZyBhIHJlc3BvbnNlIGRvZXMgbm90IG1vZGlmeSBzdGF0ZSBvcg0KICAgY2F1 c2Ugb3RoZXIgc2lnbmlmaWNhbnQgc2lkZSBlZmZlY3RzLg0KDQogICBJZiBwcm9jZXNzaW5nIGEg cmVzcG9uc2Ugd2l0aG91dCBrZWVwaW5nIHJlcXVlc3Qgc3RhdGUgaXMgc2Vuc2l0aXZlDQogICB0 byB0aGUgdGltZSBlbGFwc2VkIHRvIHNlbmRpbmcgdGhlIHJlcXVlc3QsIHRoZW4gdGhlIHNlcmlh bGl6ZWQgc3RhdGUNCiAgIE1VU1QgaW5jbHVkZSBmcmVzaG5lc3MgaW5mb3JtYXRpb24gKGUuZy4s IGEgdGltZXN0YW1wKS4NCg0KKCBzL3RvIHNlbmRpbmcvZnJvbSBzZW5kaW5nLyA/ICkNCg0KICAg SW5mb3JtYXRpb24gaW4gdGhlIHNlcmlhbGl6ZWQgc3RhdGUgbWF5IGJlIHByaXZhY3kgc2Vuc2l0 aXZlLiAgQSBub2RlDQogICBpbiBjbGllbnQgcm9sZSBNVVNUIGVuY3J5cHQgdGhlIHNlcmlhbGl6 ZWQgc3RhdGUgaWYgaXQgY29udGFpbnMNCiAgIHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9u IHRoYXQgYW4gYXR0YWNrZXIgd291bGQgbm90IGdldA0KICAgb3RoZXJ3aXNlLg0KDQpJJ20gc2xp Z2h0bHkgY29uY2VybmVkIGJ5IGFsbCB0aGVzZSAiTVVTVCB1bmxlc3MsIE1VU1QgaWYiIGFzIHRo ZXkgc2VlbQ0KdG8gbGVhdmUgdG9vIG11Y2ggZGlzY3JldGlvbiBpbiB0aGUgaGFuZHMgb2YgdGhl IGFwcGxpY2F0aW9uIHVzaW5nIENvQVAuDQoNClRha2luZyBhIHNsaWdodGx5IGhpZ2hlciBwZXJz cGVjdGl2ZSBvbiB0aGUgc3RhdGVsZXNzIGFwcHJvYWNoLCBJU1RNDQp0aGF0IHRvIGdldCBvbiBw YXIgd2l0aCAidXN1YWwiIENvQVAgdG9rZW5zLCB0aGUgc2VyaWFsaXNlZCBzdGF0ZSBNVVNUDQpi ZSBhdXRoLWVuY3J5cHRlZCBhbmQgcmVwbGF5LXByb3RlY3RlZCBhbHdheXMuICBJIGFtIGNvbnNj aW91cyB0aGF0IHRoZQ0KdHlwaWNhbCB1c2VyIG9mIHN0YXRlbGVzcyB3YW50cyB0byBhdm9pZCBj b21taXR0aW5nIGV4dHJhIHJlc291cmNlcyBpbg0KdGhlIGZpcnN0IHBsYWNlLCBob3dldmVyIHVz aW5nIHN0YXRlbGVzcyB3aXRob3V0IHRoZXNlIHNhZmVndWFyZHMgbG9va3MNCmxpa2UgdHJhZGlu ZyBzb21lIGVmZmljaWVuY3kgaW5jcmVhc2Ugd2l0aCBhIHNpZ25pZmljYW50IGRlY3JlYXNlIGlu DQpzZWN1cml0eSwgcm9idXN0bmVzcyAmIHByaXZhY3ksIHdoaWNoIGFsc28gaGFwcGVucyB0byBk b3duZ3JhZGUgdGhlDQplc3RhYmxpc2hlZCBDb0FQL2FwcGxpY2F0aW9uIGNvbnRyYWN0LiAgVmlj ZSB2ZXJzYSwgYnkgcmVxdWlyaW5nDQphdXRoLWVuY3J5cHRpb24gJiByZXBsYXkgcHJvdGVjdGlv biBhbGwgdGhlIG9idmlvdXMgYXR0YWNrcyBvbiBzZWN1cml0eQ0KZGlzc29sdmUgKCopIGFuZCB3 ZSBhcmUgYmFjayB0byBrbm93biwgc2FmZSB0ZXJyaXRvcnkuICBQcml2YWN5LXdpc2UNCnRoZXJl IGlzIHN0aWxsIGEgcHJvYmxlbSByZWxhdGVkIHRvIGxlYWtpbmcgbWVzc2FnZSBzaXplLCB3aGlj aCB3ZSBjb3VsZA0Kc3VnZ2VzdCBtaXRpZ2F0aW5nIHdpdGggcGFkZGluZy4NCg0KKCopIEV4Y2Vw dCBtYXliZSBmb3IgdGhlIGNvbmZ1c2lvbiBhdHRhY2sgaW52b2x2aW5nIGFuIG9uLXBhdGggYWN0 aXZlDQphdHRhY2tlciB3aG8gY2FuIHN3YXAgdG9rZW5zIGJldHdlZW4gdHdvIChvciBtb3JlKSBv dXRzdGFuZGluZyByZXF1ZXN0cw0KZnJvbSB0aGUgc2FtZSBub2RlLCBtYXliZSBpbiBjb21iaW5h dGlvbiB3aXRoIHN1cHByZXNzaW5nIG9uZSAob3IgbW9yZSkNCnJlc3BvbnNlcy4gIEhvd2V2ZXIs IEkgZ3Vlc3MgdGhpcyBpcyBub3QgcmVhbGx5IGRpZmZlcmVudCBmcm9tIHdoYXQgeW91DQpjYW4g YWxyZWFkeSBkbyB3aXRoIE5vU2VjIENvQVAsIGFuZCBpZiB0aGlzIGlzIGEgbWF0ZXJpYWwgdGhy ZWF0IHRoZW4NCndoYXQgeW91IHJlYWxseSBuZWVkIGlzIGEgc2VjdXJlIHRyYW5zcG9ydCB0byBj b21wbGVtZW50IHRoZSBzZWN1cmVkDQp0b2tlbiAoYmVjYXVzZSB5b3UgZG9uJ3Qgd2FudCB0byB0 cnVzdCB0aGUgcHJveHkgd2l0aCB5b3VyIGNsZWFyLXRleHQNCnNlcmlhbGlzZWQgc3RhdGUgYW55 d2F5LikNCg0KICAgWy4uLl0gIEluIHdpcmVsZXNzIG1lc2ggbmV0d29ya3MsDQogICB3aGVyZSBh bGwgdHJhZmZpYyBpcyB2aXNpYmxlIHRvIGEgcGFzc2l2ZSBhdHRhY2tlciwgZW5jcnlwdGlvbiBt YXkNCiAgIG5vdCBiZSBuZWVkZWQgYXMgdGhlIGF0dGFja2VyIGNhbiBnZXQgdGhlIHNhbWUgaW5m b3JtYXRpb24gZnJvbQ0KICAgYW5hbHl6aW5nIHRoZSB0cmFmZmljIGZsb3dzLg0KDQpJIG11c3Qg cmVhbGx5IGJlIG1pc3Npbmcgc29tZXRoaW5nIGJpZyBiZWNhdXNlIEkgZmFpbCB0byB1bmRlcnN0 YW5kIHdoeQ0KY29tbXVuaWNhdGluZyBvdmVyIGEgd2lyZWxlc3MgbWVzaCBtYWtlcyB0b2tlbiBl bmNyeXB0aW9uIHJlZHVuZGFudD8NCg0KDQpBIGZpbmFsIHF1ZXN0aW9uOiBhcyBhbiBhZnRlci1l ZmZlY3QgaW4gY2FzZSBpbnRlZ3JpdHkvZW5jcnlwdGlvbiBrZXlzDQphcmUgcGVyc2lzdGVkLCBj YW4gYW4gT2JzZXJ2YXRpb24gc3Vydml2ZSB0aGUgcmVib290IG9mIHRoZSBub2RlPyAgSWYNCnNv LCBpdCdzIG1heWJlIHdvcnRoIHBvaW50aW5nIHRoYXQgb3V0IGV4cGxpY2l0bHkgYXMgaXQgbWF5 IG9yIG1heSBub3QNCmJlIGEgZGVzaXJhYmxlIHRoaW5nPw0KDQpDaGVlcnMsIHRoYW5rcyENCg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Jun 27 05:06:48 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8B12024A; Thu, 27 Jun 2019 05:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 YrpYqZ3jb6lS; Thu, 27 Jun 2019 05:06:43 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EF71200C5; Thu, 27 Jun 2019 05:06:42 -0700 (PDT) Received: from mail-qk1-f173.google.com ([209.85.222.173]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hgTAl-000487-7P; Thu, 27 Jun 2019 14:06:39 +0200 Received: by mail-qk1-f173.google.com with SMTP id r6so1469328qkc.0; Thu, 27 Jun 2019 05:06:39 -0700 (PDT) X-Gm-Message-State: APjAAAVm5qhdeHFxRlDrCQZCQsEN153QnjAQRHp4qoi6PY+ZTt8bOx4Q aGGd5LOWXpbmHuewITor+Eieo6SXKT9Q4Sm4C7U= X-Google-Smtp-Source: APXvYqxWuA8QRCJCAPRRewONvd4oVphVXWZXBd652s2kgIexMP/8ZUYFTq+/BDu5VtusAFR945vobAWp0udjO6afWvk= X-Received: by 2002:a37:e40a:: with SMTP id y10mr2749984qkf.303.1561637198156; Thu, 27 Jun 2019 05:06:38 -0700 (PDT) MIME-Version: 1.0 References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Klaus Hartke Date: Thu, 27 Jun 2019 14:06:01 +0200 X-Gmail-Original-Message-ID: Message-ID: To: mohamed.boucadair@orange.com Cc: Carsten Bormann , core , "draft-ietf-core-hop-limit@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1561637202; a64bdf2c; X-HE-SMSGID: 1hgTAl-000487-7P Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 12:06:46 -0000 Hi Mohamed, thank you for your response. I'm skipping items that I consider resolved. Mohamed Boucadair wrote: > > 3. "The initial Hop-Limit value SHOULD be configurable." - Is it > > really a protocol violation if my implementation does not provide a > > configuration option for this? > > [Med] No, it is not a protocol violation (that is the reason for using "S= HOULD" and not "MUST"). We briefly discussed this in the interim yesterday and came to the conclusion that having a normative requirement here isn't needed. It seems more like a suggestion for a good quality of implementation. I propose to remove any use of KEYWORDs here. > > 3. "To ease debugging and troubleshooting, the CoAP proxy which > > detects a loop SHOULD include its information ... Each intermediate > > proxy involved in relaying a TBA1 (Hop Limit Reached) error message > > SHOULD prepend its own information" - Is it really a protocol > > violation if I want to configure my proxy not to include any > > information? > > > > [Med] It is not a protocol violation if the information is not included -= hence the SHOULD. However it makes diagnosing the issue more difficult. Same as above. > > 3. "That information MUST NOT include any space character." - Since a > > diagnostic payload is intended for debugging, it seems weird to make > > any requirements on the formatting. > > [Med] Making requirement on the diag is important here because this is us= ed to identify the loop. Note that HTTP also makes some reco about the form= at of diagnostic information, see https://tools.ietf.org/html/rfc7239 I think you need to make a decision here what you want to achieve: Is it purely about generating useful diagnostics for humans to interpret, or is it about generating data that a machine can understand? In the first case, you could suggest that implementations end the text they're prepending in CR LF (in accordance with RFC 5198). But I think it would be too restrictive to require implementations to format their information in a certain way. In the second case, we could simply define a new media type and use CDDL and/or ABNF to describe the format. > Diagnostic information without any > > space characters is probably very hard to read. > > [Med] Hmm. This is about a name, IP addresses. These must not include spa= ce characters. Maybe a few examples in the draft would be helpful. > > 3. "Each intermediate proxy involved in relaying a TBA1 (Hop Limit > > Reached) error message SHOULD prepend its own information" - It might > > be worth pointing out that at some point the diagnostic message might > > become so large that Blockwise Transfers [2] are needed. > > [Med] We do have doubts about the use of 7959 in this context. It is not = obvious from 7959 to see how diagnostic messages can be split over multiple= messages without expecting any action from the client + how the intermedia= te proxy which observes the size is large will handle the transmission of t= he various fragments. > > 4.xx is a failure and so while this could be returned with an additional = BLOCK2 to the next sender in the chain, we don=E2=80=99t think this will wo= rk as the original client is expecting a 2.xx to inspect for a BLOCK2 optio= n to see if the request for the next block of data is needed. Then, how doe= s an interim proxy know that it is to be sending the additional data rather= than forwarding the request on to the next proxy. This is not different from any other proxy-generated error response... There was some agreement in the interim yesterday though that the use of blockwise transfers might not be very desirable here. > We suggest that we only prepend if there is sufficient space. We can add = NEW text to record this. That's one option, but it might be difficult to determine what is "sufficient space" if the message goes through multiple networks. Another option is to record only the information of the hop where the Hop-Limit value reaches 0. Then the payload size would be constant and not grow with the number of hops in between. If someone debugging the system needs the information of the hops in between, then they can send requests with decreasing initial Hop-Limit values. > Intended Usage There was agreement in the interim yesterday that it's probably a good idea to recommend that all CoAP proxies implement this and have it turned on by default. If in certain deployment it doesn't make sense, it can be turned off. Something like the text proposed by Carsten in https://mailarchive.ietf.org/arch/msg/core/dUNMiz-nLBCa4-tblZW5jLaZ5Jg would be good. > HTTP Mapping Mapping the TBA1 (Hop Limit Reached) response code to the 508 (Loop Detected) status code is probably fine. Mapping between the Hop-Limit option and Via or CDN-Loop header field is more difficult. I'm not what what can actually be recommended here. There's also the problem when a CoAP-to-HTTP and a HTTP-to-CoAP proxy are sending a message in a loop (possibly with more CoAP and/or HTTP proxies in between). It would be nice if this could be detected. Otherwise, maybe some text should be added that this scenario cannot be detected with the Hop-Limit option. Klaus From nobody Thu Jun 27 06:23:07 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0D212013C for ; Thu, 27 Jun 2019 06:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wittra.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 5a0KwlbYIX4g for ; Thu, 27 Jun 2019 06:23:01 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1D9120043 for ; Thu, 27 Jun 2019 06:23:00 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 205so2319333ljj.8 for ; Thu, 27 Jun 2019 06:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wittra.se; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RJ5j7UBAofeViAVNX2BmjURZdZFEf5i+5+vHeYN/dao=; b=U+WuGX23C72FZtI2HDJVhgim9SP52CklRaD6/uPCxqT/NaS7+wDKQYb9EcmRZVcA2v Mq2PYgTKTUUnHgoDIQXyvmDvGPh1caMD1/NvTXvVXzwIgJFPLMhoOWxfBR+YpeyhlUuJ bxWXGCjg2LPKZ7l/C8uoxAr6CWUPb1BdNxZEyYCRq1mC44meVuGs/p7ykxnhRIuLY3Zq 4FUsNMSbpLg6nbeWB365k1wtATI/N/WAwSyB6EMdOXgy4rykrnFrl0PgyQy2/cIdH8TI 74k8feMCPS2s2+fpUSjJ8183laGdlRtwyYvW5YWKfGy/Ty+zSvWxd54DAKhsj3C1OgG2 ANXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RJ5j7UBAofeViAVNX2BmjURZdZFEf5i+5+vHeYN/dao=; b=aXaW2r3lMCVV8+yPHxinOMqT8sPJGWo9+Ls7qwkW3Cx2+pdya3hKGoKoi0W/ykC/6J iBs6CAr1/ntSW/VeFPnOhbanGddAyhVh+qQTN9nau5/Sm85YC79J0O06LwEIkdfKhJVM /pILrt8Q6K32e/26xoTxkWJK8Cu9130W+vDpeP4W6UwSC2SXKOC+acrAaxEGGsm1p7sR SfhOkDChVdackjjHPmeib0iMNgpMsfBXWgS4t7QrI1pODAEwh6cjvDpg1d0WMIpGDGHL VoSincM8QnArnIF6YMEe9FiPd52u1PEgCHJ9pJuqsIOTUc3FZT/3uNhmn6dnlGhxERMS JB7A== X-Gm-Message-State: APjAAAXNJupOAG1huSFhUOgQtAKlTajL+IJfeDIjAcfpzvdFfolOFftJ ewskc+vnuIXRmzhiBHA4YMoE5g== X-Google-Smtp-Source: APXvYqzQVgpCuydKFU6IAdp2vDr2Xu3XUujjZIvvklIeI3E/P/cEs3+e/bLt0lTYh+mF69utAe73eQ== X-Received: by 2002:a2e:9758:: with SMTP id f24mr2673106ljj.58.1561641778927; Thu, 27 Jun 2019 06:22:58 -0700 (PDT) Received: from [192.168.0.172] (2.70.105.0.mobile.tre.se. [2.70.105.0]) by smtp.gmail.com with ESMTPSA id s1sm441234ljd.83.2019.06.27.06.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 06:22:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_97E353D9-7832-4D4C-A8AA-2683D11E7279" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Fredrik Wegelid X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 27 Jun 2019 15:22:55 +0200 Cc: core Message-Id: References: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se> <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> To: Abhijan Bhattacharyya X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 13:23:06 -0000 --Apple-Mail=_97E353D9-7832-4D4C-A8AA-2683D11E7279 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Abhijan, Thank you for your response. It is great to see how engaged you guys are = :) The reason that we are talking about this solution are the requirements = for the devices in our network. We have devices sending messages (that = are big enough to require a blockwise transfer) that have very high = requirements when it comes to battery consumption. In order to listen = for responses the devices have to keep the radio turned on to listen for = these responses. By not listening to the responses (except the last one) = we can keep the radio turned off for a larger portion of the time and in = such a way save battery. This is our reasoning for wanting to use = No-Response together with blockwise. I understand that from a network perspective this does not really make = sense. To reduce the amount of traffic on the network I agree that it = would be better to listen for the 2.31 Continue responses and restart = the blockwise transfer in the case of a lost block. If we do not have to = listen to these responses we could hopefully reduce the power = consumption of the device. BR, Fredrik > On 27 Jun 2019, at 07:18, Abhijan Bhattacharyya = wrote: >=20 > Hi Fredrick and Carsten, > Thanks for the discussion so far. Let me put my thoughts. >=20 > The proposal to reduce the traffic in case of block-wise transfer = using no-response is obvious. However, there is a catch. As per my = understanding, the use case considered for block-wise transfer relates = to transfers demanding high integrity of the received data and very low = complexity at the receiving end in re-assembling the segments. One = example is firmware upgrade of remote sensors: you cannot miss a single = bit. Also, the message reception is tightly sequential in order. In case = you miss one segment or receive in out-of-order, the transfers seizes in = between. >=20 > Now, Fredrick, coming to your solution: I do not know the QoS = requirements in your perceived use case. You do not care about responses = of intermediate blocks (essentially this means RESTfully = fire-and-forget!) and you take the response of the last block to ensure = the end of transfer. Now the question is, if you care for all the blocks = at the receiving end (for which you did not care for a response) how do = you ensure reception of all the blocks? Considering the resource = constrains in IoT use cases it will be a wastage of bandwidth if you = have sent all the segments from the transmit end and the receiver, after = receiving the end block, realizes that one intermediate segment got = missing. The whole transfer, and the resource consumption related to = that, becomes useless. You might have rather stopped at the loss = instance and take corrective measures to resume. That would save your = resources. So, there something more to think and design carefully = according to the exact QoS requirements of the perceived class of = use-cases. >=20 > However, in case you are looking for real-time + low-latency + = low-resource consuming transfer, you may please have a look at this = proposal that we already submitted few months back: = https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-02 = . To = relate this draft to your problem you may simply consider to model your = block-wise traffic as a time-series traffic. >=20 > Having said that, I did once nurture some ideas to make block-wise = transfer "statistically" more resource-efficient, yet reliable . But, = must I be confirmed about the efficacy of my idea, both theoretically = and experimentally, before I speak about that. I have kept that in back = burner. In case there is enough interest I can renew the interest and = discuss. >=20 > Thank you. =20 >=20 > With Best Regards > Abhijan Bhattacharyya > Consultant / Scientist, > {Internet Protocols | 5G | Standardization},=20 > TCS Research, > Tata Consultancy Services > Building 1B,Ecospace > Plot - IIF/12 ,New Town, Rajarhat, > Kolkata - 700160,West Bengal > India > Ph:- +91 33 66884691 > Cell:- +919830468972 | +918583875003 > Mailto: abhijan.bhattacharyya@tcs.com = > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ >=20 >=20 > -----"core" > = wrote: ----- > To: Carsten Bormann > > From: Fredrik Wegelid=20 > Sent by: "core"=20 > Date: 06/26/2019 05:28PM > Cc: core > > Subject: Re: [core] RFC 7967 (No-Response) together with block-wise = transfers in CoAP >=20 > "External email. Open with Caution" >=20 > Hi Carsten, >=20 > This is how an example looks like without the No-Response option. >=20 > Client -> Server: NON POST Payload: =E2=80=9CBlock 1...=E2=80=9D > Server -> Client: NON 2.31 Continue > Client -> Server: NON POST Payload: =E2=80=9CBlock 2...=E2=80=9D > Server -> Client: NON 2.31 Continue >=20 > More blocks=E2=80=A6 >=20 > Client -> Server: NON POST Payload: =E2=80=9CFinal block...=E2=80=9D > Server -> Client: NON 2.01 Created (As an example) >=20 > With the No-Response option I wish the exchange to look something like = this: >=20 > Client -> Server: NON POST (No-Response:26) Payload: =E2=80=9CBlock = 1...=E2=80=9D > Client -> Server: NON POST (No-Response:26) Payload: =E2=80=9CBlock = 2...=E2=80=9D >=20 > More blocks=E2=80=A6 >=20 > Client -> Server: NON POST Payload: =E2=80=9CFinal block...=E2=80=9D > Server -> Client: NON 2.01 Created (As an example) >=20 > This would mean that the server would not send the 2.31 responses for = each block (as the No-Response option is set to 26) while it still would = send the final response (since the final block does not have the = No-Response option set). > This allows the client to ensure that all blocks were sent = successfully. If they are not, the server would respond with another = code. It would also mean that the amount of traffic on the network is = reduced. >=20 > Best regards, > Fredrik >=20 > > On 26 Jun 2019, at 13:43, Carsten Bormann > wrote: > >=20 > > Hi Fredrik, > >=20 > > I=E2=80=99m not sure I entirely understand the message exchanges you = envision; maybe you can provide an example. > >=20 > > RFC 7967 has a way to suppress responses based on the response code. > > Unfortunately, the granularity is on the class only at the moment. > > The option that carries this information isn=E2=80=99t explicitly = defined as an extension point. Still, someone (the original author? = The WG?) might want to go ahead, e.g., by defining a bit in the option = value that says =E2=80=9CNot interested in 2.31 responses=E2=80=9D. = (Maybe we want to understand what exactly a client would not be = interested in a bit more before we go ahead allocating bits like this.) > >=20 > > Abhijan, what do you think? > >=20 > > Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > >> On Jun 26, 2019, at 13:30, Fredrik Wegelid = > wrote: > >>=20 > >> Hi, > >>=20 > >> I hope that I am using this email list in the correct way. I = apologise if that is not the case. > >> I have some questions/thoughts about using the No-Response option = (RFC 7967) together with block-wise transfers in COAP. > >>=20 > >> In my team we are using CoAP to send messages from devices to a = server. The messages are of such a size that we need to make block-wise = transfers. In an attempt to reduce the amount of traffic in the network = we have looked at using the No-Response option. We are however not clear = on how this would work if used together with block-wise transfers. We = would like to use the No-Response option to make the server omit the = 2.31 Continue responses from the server on each block. We would however = still like to be able to get a response on the last block to indicate = the status of the entire block sequence.=20 > >>=20 > >> Does this make sense? In RFC 7967 block-wise transfers are not = mentioned. Are they meant to be used together? > >>=20 > >> Best regards, > >> Fredrik Wegelid > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core = > >>=20 > >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = > =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D > Notice: The information contained in this e-mail > message and/or attachments to it may contain=20 > confidential or privileged information. If you are=20 > not the intended recipient, any dissemination, use,=20 > review, distribution, printing or copying of the=20 > information contained in this e-mail message=20 > and/or attachments to it are strictly prohibited. If=20 > you have received this communication in error,=20 > please notify us by reply e-mail or telephone and=20 > immediately and permanently delete the message=20 > and any attachments. Thank you >=20 >=20 --Apple-Mail=_97E353D9-7832-4D4C-A8AA-2683D11E7279 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Abhijan,

Thank you = for your response. It is great to see how engaged you guys are = :)

The reason = that we are talking about this solution are the requirements for the = devices in our network. We have devices sending messages (that are big = enough to require a blockwise transfer) that have very high requirements = when it comes to battery consumption. In order to listen for responses = the devices have to keep the radio turned on to listen for these = responses. By not listening to the responses (except the last one) we = can keep the radio turned off for a larger portion of the time and in = such a way save battery. This is our reasoning for wanting to use = No-Response together with blockwise.

I understand that from a network = perspective this does not really make sense. To reduce the amount of = traffic on the network I agree that it would be better to listen for the = 2.31 Continue responses and restart the blockwise transfer in the case = of a lost block. If we do not have to listen to these responses we could = hopefully reduce the power consumption of the device.

BR,
Fredrik

On 27 Jun 2019, at 07:18, = Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> wrote:

Hi Fredrick and Carsten,
Thanks for the = discussion so far. Let me put my thoughts.

The proposal to reduce the traffic in = case of block-wise transfer using no-response is obvious. However, there = is a catch. As per my understanding, the use case considered for = block-wise transfer relates to transfers demanding high integrity of the = received data and very low complexity at the receiving end in = re-assembling the segments. One example is firmware upgrade of remote = sensors: you cannot miss a single bit. Also, the message reception is = tightly sequential in order. In case you miss one segment or receive in = out-of-order, the transfers seizes in between.

Now, Fredrick, coming to your solution: = I do not know the QoS requirements in your perceived use case. You do = not care about responses of intermediate blocks (essentially this means = RESTfully fire-and-forget!) and you take the response of the last block = to ensure the end of transfer. Now the question is, if you care for all = the blocks at the receiving end (for which you did not care for a = response) how do you ensure reception of all the blocks? Considering the = resource constrains in IoT use cases it will be a wastage of bandwidth = if you have sent all the segments from the transmit end and the = receiver, after receiving the end block, realizes that one intermediate = segment got missing. The whole transfer, and the resource consumption = related to that, becomes useless. You might have rather stopped at the = loss instance and take corrective measures to resume. That would save = your resources. So, there something more to think and design carefully = according to the exact QoS requirements of the perceived class of = use-cases.

However, in case you are looking for real-time + low-latency = + low-resource consuming transfer, you may please have a look at this = proposal that we already submitted few months back: https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-= 02 . To relate this draft to your problem you may simply consider to = model your block-wise traffic as a time-series traffic.

Having said that, I did = once nurture some ideas to make block-wise transfer "statistically" more = resource-efficient, yet reliable . But, must I be confirmed about the = efficacy of my idea, both theoretically and experimentally, before I = speak about that. I have kept that in back burner. In case there is = enough interest I can renew the interest and discuss.

Thank you.   =   

With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization}, =
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________


-----"core" <core-bounces@ietf.org> wrote: = -----
To: Carsten Bormann <cabo@tzi.org>
From: = Fredrik Wegelid
Sent = by: "core"
Date: = 06/26/2019 05:28PM
Cc: core <core@ietf.org>
Subject: Re: [core] RFC = 7967 (No-Response) together with block-wise transfers in CoAP

"External email. Open with = Caution"

Hi Carsten,

This is how an example looks like without the No-Response = option.

Client -> Server: NON POST = Payload: =E2=80=9CBlock 1...=E2=80=9D
Server -> Client: = NON 2.31 Continue
Client -> Server: NON POST = Payload: =E2=80=9CBlock 2...=E2=80=9D
Server -> Client: = NON 2.31 Continue

More blocks=E2=80=A6

Client -> Server: NON POST Payload: = =E2=80=9CFinal block...=E2=80=9D
Server -> Client: = NON 2.01 Created (As an example)

With the = No-Response option I wish the exchange to look something like this:

Client -> Server: NON POST = (No-Response:26) Payload: =E2=80=9CBlock 1...=E2=80=9D
Client -> Server: NON POST (No-Response:26) = Payload: =E2=80=9CBlock 2...=E2=80=9D

More = blocks=E2=80=A6

Client -> Server: = NON POST Payload: =E2=80=9CFinal block...=E2=80=9D
Server = -> Client: NON 2.01 Created (As an example)

This would mean that the server would not send the 2.31 = responses for each block (as the No-Response option is set to 26) while = it still would send the final response (since the final block does not = have the No-Response option set).
This allows the client = to ensure that all blocks were sent successfully. If they are not, the = server would respond with another code. It would also mean that the = amount of traffic on the network is reduced.

Best regards,
Fredrik

> On 26 Jun 2019, at 13:43, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Fredrik,
>
> I=E2=80= =99m not sure I entirely understand the message exchanges you envision; = maybe you can provide an example.
>
> = RFC 7967 has a way to suppress responses based on the response code.
> Unfortunately, the granularity is on the class only at = the moment.
> The option that carries this information = isn=E2=80=99t explicitly defined as an extension point.  Still, = someone (the original author?  The WG?) might want to go ahead, = e.g., by defining a bit in the option value that says =E2=80=9CNot = interested in 2.31 responses=E2=80=9D.  (Maybe we want to = understand what exactly a client would not be interested in a bit more = before we go ahead allocating bits like this.)
>
> Abhijan, what do you think?
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>> On Jun 26, 2019, at 13:30, = Fredrik Wegelid <fredrik.wegelid@wittra.se> wrote:
>>
>> Hi,
>> =
>> I hope that I am using this email list in the = correct way. I apologise if that is not the case.
>> = I have some questions/thoughts about using the No-Response option (RFC = 7967) together with block-wise transfers in COAP.
>> =
>> In my team we are using CoAP to send messages = from devices to a server. The messages are of such a size that we need = to make block-wise transfers. In an attempt to reduce the amount of = traffic in the network we have looked at using the No-Response option. = We are however not clear on how this would work if used together with = block-wise transfers. We would like to use the No-Response option to = make the server omit the 2.31 Continue responses from the server on each = block. We would however still like to be able to get a response on the = last block to indicate the status of the entire block sequence.
>>
>> Does this make sense? In RFC = 7967 block-wise transfers are not mentioned. Are they meant to be used = together?
>>
>> Best = regards,
>> Fredrik Wegelid
>> = _______________________________________________
>> = core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>

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

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D----= -=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you



= --Apple-Mail=_97E353D9-7832-4D4C-A8AA-2683D11E7279-- From nobody Thu Jun 27 06:29:29 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1435B12013C; Thu, 27 Jun 2019 06:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dP4oOsfDOHMw; Thu, 27 Jun 2019 06:29:25 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4526F120043; Thu, 27 Jun 2019 06:29:25 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45ZLN33MJJz5y9f; Thu, 27 Jun 2019 15:29:23 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 45ZLN32Ym8zDq7r; Thu, 27 Jun 2019 15:29:23 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 15:29:23 +0200 From: To: Klaus Hartke CC: Carsten Bormann , core , "draft-ietf-core-hop-limit@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBvZiBkcmFmdC1pZXRmLWNvcmUtaG9wLWxpbWl0?= =?utf-8?Q?-03.txt?= Thread-Index: AQHVLODHqL10tf5ohUe16bdCx0kZ16avaVyA Date: Thu, 27 Jun 2019 13:29:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAEBD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org> <787AE7BB302AE849A7480A190F8B93302EAAD266@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-hop-limit-?= =?utf-8?q?03=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 13:29:28 -0000 SGkgS2xhdXMsIA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmb2xsb3ctdXAuIA0KDQpQbGVhc2Ugc2Vl IGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IEtsYXVzIEhhcnRrZSBbbWFpbHRvOmhhcnRrZUBwcm9qZWN0Y29vbC5kZV0NCj4g RW52b3nDqcKgOiBqZXVkaSAyNyBqdWluIDIwMTkgMTQ6MDYNCj4gw4DCoDogQk9VQ0FEQUlSIE1v aGFtZWQgVEdJL09MTg0KPiBDY8KgOiBDYXJzdGVuIEJvcm1hbm47IGNvcmU7IGRyYWZ0LWlldGYt Y29yZS1ob3AtbGltaXRAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtjb3JlXSDwn5SUIFdHTEMg b2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1pdC0wMy50eHQNCj4gDQo+IEhpIE1vaGFtZWQsDQo+ IA0KPiB0aGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UuIEknbSBza2lwcGluZyBpdGVtcyB0aGF0 IEkgY29uc2lkZXIgcmVzb2x2ZWQuDQo+IA0KPiBNb2hhbWVkIEJvdWNhZGFpciB3cm90ZToNCj4g PiA+IDMuICJUaGUgaW5pdGlhbCBIb3AtTGltaXQgdmFsdWUgU0hPVUxEIGJlIGNvbmZpZ3VyYWJs ZS4iIC0gSXMgaXQNCj4gPiA+IHJlYWxseSBhIHByb3RvY29sIHZpb2xhdGlvbiBpZiBteSBpbXBs ZW1lbnRhdGlvbiBkb2VzIG5vdCBwcm92aWRlIGENCj4gPiA+IGNvbmZpZ3VyYXRpb24gb3B0aW9u IGZvciB0aGlzPw0KPiA+DQo+ID4gW01lZF0gTm8sIGl0IGlzIG5vdCBhIHByb3RvY29sIHZpb2xh dGlvbiAodGhhdCBpcyB0aGUgcmVhc29uIGZvciB1c2luZw0KPiAiU0hPVUxEIiBhbmQgbm90ICJN VVNUIikuDQo+IA0KPiBXZSBicmllZmx5IGRpc2N1c3NlZCB0aGlzIGluIHRoZSBpbnRlcmltIHll c3RlcmRheSBhbmQgY2FtZSB0byB0aGUNCj4gY29uY2x1c2lvbiB0aGF0IGhhdmluZyBhIG5vcm1h dGl2ZSByZXF1aXJlbWVudCBoZXJlIGlzbid0IG5lZWRlZC4gSXQNCj4gc2VlbXMgbW9yZSBsaWtl IGEgc3VnZ2VzdGlvbiBmb3IgYSBnb29kIHF1YWxpdHkgb2YgaW1wbGVtZW50YXRpb24uIEkNCj4g cHJvcG9zZSB0byByZW1vdmUgYW55IHVzZSBvZiBLRVlXT1JEcyBoZXJlLg0KPiANCg0KW01lZF0g V2lsbCBnbyB3aXRoIHRoZSBvdXRjb21lIG9mIHRoZSBpbnRlcmltLiANCg0KPiA+ID4gMy4gIlRv IGVhc2UgZGVidWdnaW5nIGFuZCB0cm91Ymxlc2hvb3RpbmcsIHRoZSBDb0FQIHByb3h5IHdoaWNo DQo+ID4gPiBkZXRlY3RzIGEgbG9vcCBTSE9VTEQgaW5jbHVkZSBpdHMgaW5mb3JtYXRpb24gLi4u IEVhY2ggaW50ZXJtZWRpYXRlDQo+ID4gPiBwcm94eSBpbnZvbHZlZCBpbiByZWxheWluZyBhIFRC QTEgKEhvcCBMaW1pdCBSZWFjaGVkKSBlcnJvciBtZXNzYWdlDQo+ID4gPiBTSE9VTEQgcHJlcGVu ZCBpdHMgb3duIGluZm9ybWF0aW9uIiAtIElzIGl0IHJlYWxseSBhIHByb3RvY29sDQo+ID4gPiB2 aW9sYXRpb24gaWYgSSB3YW50IHRvIGNvbmZpZ3VyZSBteSBwcm94eSBub3QgdG8gaW5jbHVkZSBh bnkNCj4gPiA+IGluZm9ybWF0aW9uPw0KPiA+ID4NCj4gPg0KPiA+IFtNZWRdIEl0IGlzIG5vdCBh IHByb3RvY29sIHZpb2xhdGlvbiBpZiB0aGUgaW5mb3JtYXRpb24gaXMgbm90IGluY2x1ZGVkDQo+ IC0gaGVuY2UgdGhlIFNIT1VMRC4gSG93ZXZlciBpdCBtYWtlcyBkaWFnbm9zaW5nIHRoZSBpc3N1 ZSBtb3JlIGRpZmZpY3VsdC4NCj4gDQo+IFNhbWUgYXMgYWJvdmUuDQoNCltNZWRdIE9LLg0KDQo+ IA0KPiA+ID4gMy4gIlRoYXQgaW5mb3JtYXRpb24gTVVTVCBOT1QgaW5jbHVkZSBhbnkgc3BhY2Ug Y2hhcmFjdGVyLiIgLSBTaW5jZSBhDQo+ID4gPiBkaWFnbm9zdGljIHBheWxvYWQgaXMgaW50ZW5k ZWQgZm9yIGRlYnVnZ2luZywgaXQgc2VlbXMgd2VpcmQgdG8gbWFrZQ0KPiA+ID4gYW55IHJlcXVp cmVtZW50cyBvbiB0aGUgZm9ybWF0dGluZy4NCj4gPg0KPiA+IFtNZWRdIE1ha2luZyByZXF1aXJl bWVudCBvbiB0aGUgZGlhZyBpcyBpbXBvcnRhbnQgaGVyZSBiZWNhdXNlIHRoaXMgaXMNCj4gdXNl ZCB0byBpZGVudGlmeSB0aGUgbG9vcC4gTm90ZSB0aGF0IEhUVFAgYWxzbyBtYWtlcyBzb21lIHJl Y28gYWJvdXQgdGhlDQo+IGZvcm1hdCBvZiBkaWFnbm9zdGljIGluZm9ybWF0aW9uLCBzZWUgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzkNCj4gDQo+IEkgdGhpbmsgeW91IG5lZWQg dG8gbWFrZSBhIGRlY2lzaW9uIGhlcmUgd2hhdCB5b3Ugd2FudCB0byBhY2hpZXZlOiBJcw0KPiBp dCBwdXJlbHkgYWJvdXQgZ2VuZXJhdGluZyB1c2VmdWwgZGlhZ25vc3RpY3MgZm9yIGh1bWFucyB0 byBpbnRlcnByZXQsDQo+IG9yIGlzIGl0IGFib3V0IGdlbmVyYXRpbmcgZGF0YSB0aGF0IGEgbWFj aGluZSBjYW4gdW5kZXJzdGFuZD8NCj4gDQo+IEluIHRoZSBmaXJzdCBjYXNlLCB5b3UgY291bGQg c3VnZ2VzdCB0aGF0IGltcGxlbWVudGF0aW9ucyBlbmQgdGhlIHRleHQNCj4gdGhleSdyZSBwcmVw ZW5kaW5nIGluIENSIExGIChpbiBhY2NvcmRhbmNlIHdpdGggUkZDIDUxOTgpLiBCdXQgSSB0aGlu aw0KPiBpdCB3b3VsZCBiZSB0b28gcmVzdHJpY3RpdmUgdG8gcmVxdWlyZSBpbXBsZW1lbnRhdGlv bnMgdG8gZm9ybWF0IHRoZWlyDQo+IGluZm9ybWF0aW9uIGluIGEgY2VydGFpbiB3YXkuDQo+IA0K PiBJbiB0aGUgc2Vjb25kIGNhc2UsIHdlIGNvdWxkIHNpbXBseSBkZWZpbmUgYSBuZXcgbWVkaWEg dHlwZSBhbmQgdXNlDQo+IENEREwgYW5kL29yIEFCTkYgdG8gZGVzY3JpYmUgdGhlIGZvcm1hdC4N Cj4gDQo+ID4gIERpYWdub3N0aWMgaW5mb3JtYXRpb24gd2l0aG91dCBhbnkNCj4gPiA+IHNwYWNl IGNoYXJhY3RlcnMgaXMgcHJvYmFibHkgdmVyeSBoYXJkIHRvIHJlYWQuDQo+ID4NCj4gPiBbTWVk XSBIbW0uIFRoaXMgaXMgYWJvdXQgYSBuYW1lLCBJUCBhZGRyZXNzZXMuIFRoZXNlIG11c3Qgbm90 IGluY2x1ZGUNCj4gc3BhY2UgY2hhcmFjdGVycy4NCj4gDQo+IE1heWJlIGEgZmV3IGV4YW1wbGVz IGluIHRoZSBkcmFmdCB3b3VsZCBiZSBoZWxwZnVsLg0KDQpbTWVkXSBXaWxsIGFkZCBzb21lLiAN Cg0KPiANCj4gPiA+IDMuICJFYWNoIGludGVybWVkaWF0ZSBwcm94eSBpbnZvbHZlZCBpbiByZWxh eWluZyBhIFRCQTEgKEhvcCBMaW1pdA0KPiA+ID4gUmVhY2hlZCkgZXJyb3IgbWVzc2FnZSBTSE9V TEQgcHJlcGVuZCBpdHMgb3duIGluZm9ybWF0aW9uIiAtIEl0IG1pZ2h0DQo+ID4gPiBiZSB3b3J0 aCBwb2ludGluZyBvdXQgdGhhdCBhdCBzb21lIHBvaW50IHRoZSBkaWFnbm9zdGljIG1lc3NhZ2Ug bWlnaHQNCj4gPiA+IGJlY29tZSBzbyBsYXJnZSB0aGF0IEJsb2Nrd2lzZSBUcmFuc2ZlcnMgWzJd IGFyZSBuZWVkZWQuDQo+ID4NCj4gPiBbTWVkXSBXZSBkbyBoYXZlIGRvdWJ0cyBhYm91dCB0aGUg dXNlIG9mIDc5NTkgaW4gdGhpcyBjb250ZXh0LiBJdCBpcyBub3QNCj4gb2J2aW91cyBmcm9tIDc5 NTkgdG8gc2VlIGhvdyBkaWFnbm9zdGljIG1lc3NhZ2VzIGNhbiBiZSBzcGxpdCBvdmVyDQo+IG11 bHRpcGxlIG1lc3NhZ2VzIHdpdGhvdXQgZXhwZWN0aW5nIGFueSBhY3Rpb24gZnJvbSB0aGUgY2xp ZW50ICsgaG93IHRoZQ0KPiBpbnRlcm1lZGlhdGUgcHJveHkgd2hpY2ggb2JzZXJ2ZXMgdGhlIHNp emUgaXMgbGFyZ2Ugd2lsbCBoYW5kbGUgdGhlDQo+IHRyYW5zbWlzc2lvbiBvZiB0aGUgdmFyaW91 cyBmcmFnbWVudHMuDQo+ID4NCj4gPiA0Lnh4IGlzIGEgZmFpbHVyZSBhbmQgc28gd2hpbGUgdGhp cyBjb3VsZCBiZSByZXR1cm5lZCB3aXRoIGFuIGFkZGl0aW9uYWwNCj4gQkxPQ0syIHRvIHRoZSBu ZXh0IHNlbmRlciBpbiB0aGUgY2hhaW4sIHdlIGRvbuKAmXQgdGhpbmsgdGhpcyB3aWxsIHdvcmsg YXMNCj4gdGhlIG9yaWdpbmFsIGNsaWVudCBpcyBleHBlY3RpbmcgYSAyLnh4IHRvIGluc3BlY3Qg Zm9yIGEgQkxPQ0syIG9wdGlvbiB0bw0KPiBzZWUgaWYgdGhlIHJlcXVlc3QgZm9yIHRoZSBuZXh0 IGJsb2NrIG9mIGRhdGEgaXMgbmVlZGVkLiBUaGVuLCBob3cgZG9lcyBhbg0KPiBpbnRlcmltIHBy b3h5IGtub3cgdGhhdCBpdCBpcyB0byBiZSBzZW5kaW5nIHRoZSBhZGRpdGlvbmFsIGRhdGEgcmF0 aGVyDQo+IHRoYW4gZm9yd2FyZGluZyB0aGUgcmVxdWVzdCBvbiB0byB0aGUgbmV4dCBwcm94eS4N Cj4gDQo+IFRoaXMgaXMgbm90IGRpZmZlcmVudCBmcm9tIGFueSBvdGhlciBwcm94eS1nZW5lcmF0 ZWQgZXJyb3IgcmVzcG9uc2UuLi4NCj4gDQo+IFRoZXJlIHdhcyBzb21lIGFncmVlbWVudCBpbiB0 aGUgaW50ZXJpbSB5ZXN0ZXJkYXkgdGhvdWdoIHRoYXQgdGhlIHVzZQ0KPiBvZiBibG9ja3dpc2Ug dHJhbnNmZXJzIG1pZ2h0IG5vdCBiZSB2ZXJ5IGRlc2lyYWJsZSBoZXJlLg0KDQoNCltNZWRdIEkg YWdyZWUgd2l0aCB0aGUgY29uY2x1c2lvbiB0byBub3QgdXNlIHRoZSBibG9ja3dpc2UuDQoNCj4g DQo+ID4gV2Ugc3VnZ2VzdCB0aGF0IHdlIG9ubHkgcHJlcGVuZCBpZiB0aGVyZSBpcyBzdWZmaWNp ZW50IHNwYWNlLiBXZSBjYW4gYWRkDQo+IE5FVyB0ZXh0IHRvIHJlY29yZCB0aGlzLg0KPiANCj4g VGhhdCdzIG9uZSBvcHRpb24sIGJ1dCBpdCBtaWdodCBiZSBkaWZmaWN1bHQgdG8gZGV0ZXJtaW5l IHdoYXQgaXMNCj4gInN1ZmZpY2llbnQgc3BhY2UiIGlmIHRoZSBtZXNzYWdlIGdvZXMgdGhyb3Vn aCBtdWx0aXBsZSBuZXR3b3Jrcy4NCg0KW01lZF0gInN1ZmZpY2llbnQgc3BhY2UiIGlzIGJhc2Vk IG9uIHRoZSBQYXRoIE1UVS4gSWYgaXQgY2FuJ3QgYmUgZGV0ZXJtaW5lZCwgNzI1MiB3aWxsIGJl IGZvbGxvd2VkIGZvciBkZXRlcm1pbmluZyBtaW5pbXVtIHZhbHVlcy4gDQoNCj4gDQo+IEFub3Ro ZXIgb3B0aW9uIGlzIHRvIHJlY29yZCBvbmx5IHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgaG9wIHdo ZXJlIHRoZQ0KPiBIb3AtTGltaXQgdmFsdWUgcmVhY2hlcyAwLiBUaGVuIHRoZSBwYXlsb2FkIHNp emUgd291bGQgYmUgY29uc3RhbnQgYW5kDQo+IG5vdCBncm93IHdpdGggdGhlIG51bWJlciBvZiBo b3BzIGluIGJldHdlZW4uIElmIHNvbWVvbmUgZGVidWdnaW5nIHRoZQ0KPiBzeXN0ZW0gbmVlZHMg dGhlIGluZm9ybWF0aW9uIG9mIHRoZSBob3BzIGluIGJldHdlZW4sIHRoZW4gdGhleSBjYW4NCj4g c2VuZCByZXF1ZXN0cyB3aXRoIGRlY3JlYXNpbmcgaW5pdGlhbCBIb3AtTGltaXQgdmFsdWVzLg0K DQoNCltNZWRdIFRoYXQgb3B0aW9uIHdpbGwgYmUgbmF0dXJhbGx5IG1ldCBpZiB3ZSBkb24ndCBw cmVwZW5kIG9uY2UgdGhlcmUgaXMgbm8gc3VmZmljaWVudCBzcGFjZS4gVGhlIHZhbHVlIGluIGhh dmluZyB0aGUgZnVsbCBwYXRoIHdoZW4gcG9zc2libGUgaXMgdG8gZWFzZSB0cm91Ymxlc2hvb3Rp bmcgd2hlbiBhZHZhbmNlZCB0cmFmZmljIGZvcndhcmRpbmcgYXJlIGltcGxlbWVudGVkIChlLmcu LCBsb2FkIGJhbGFuY2luZywgbXVsdGlwYXRoLCBldGMuKSB3aXRob3V0IHJlcXVpcmluZyB0byBm dXJ0aGVyIHNlbmQgYW5vdGhlciB0cmFjZS9wcm9iZSByZXF1ZXN0LiANCg0KPiANCj4gPiBJbnRl bmRlZCBVc2FnZQ0KPiANCj4gVGhlcmUgd2FzIGFncmVlbWVudCBpbiB0aGUgaW50ZXJpbSB5ZXN0 ZXJkYXkgdGhhdCBpdCdzIHByb2JhYmx5IGEgZ29vZA0KPiBpZGVhIHRvIHJlY29tbWVuZCB0aGF0 IGFsbCBDb0FQIHByb3hpZXMgaW1wbGVtZW50IHRoaXMgYW5kIGhhdmUgaXQNCj4gdHVybmVkIG9u IGJ5IGRlZmF1bHQuIElmIGluIGNlcnRhaW4gZGVwbG95bWVudCBpdCBkb2Vzbid0IG1ha2Ugc2Vu c2UsDQo+IGl0IGNhbiBiZSB0dXJuZWQgb2ZmLiBTb21ldGhpbmcgbGlrZSB0aGUgdGV4dCBwcm9w b3NlZCBieSBDYXJzdGVuIGluDQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvY29yZS9kVU5NaXotbkxCQ2E0LXRibFpXNWpMYVo1SmcNCj4gd291bGQgYmUgZ29vZC4NCg0K W01lZF0gT0ssIHRoYW5rcy4gV2UgZGlkIGFscmVhZHkgaW5jbHVkZSB0aGF0IHRleHQgaW4gb3Vy IHdvcmtpbmcgY29weS4NCg0KPiANCj4gPiBIVFRQIE1hcHBpbmcNCj4gDQo+IE1hcHBpbmcgdGhl IFRCQTEgKEhvcCBMaW1pdCBSZWFjaGVkKSByZXNwb25zZSBjb2RlIHRvIHRoZSA1MDggKExvb3AN Cj4gRGV0ZWN0ZWQpIHN0YXR1cyBjb2RlIGlzIHByb2JhYmx5IGZpbmUuIE1hcHBpbmcgYmV0d2Vl biB0aGUgSG9wLUxpbWl0DQo+IG9wdGlvbiBhbmQgVmlhIG9yIENETi1Mb29wIGhlYWRlciBmaWVs ZCBpcyBtb3JlIGRpZmZpY3VsdC4gSSdtIG5vdA0KPiB3aGF0IHdoYXQgY2FuIGFjdHVhbGx5IGJl IHJlY29tbWVuZGVkIGhlcmUuDQoNCltNZWRdIFRoZSBpbml0aWFsIHByb3Bvc2FsIGlzIHRvIGlu c2VydCBIb3AtTGltaXQgeSBkZWZhdWx0IGJ5IGEgaHR0cC10by1Db0FQIHByb3h5LiBPcHRpb25h bGx5LCB0aGUgcHJveHkgY2FuIGJlIGluc3RydWN0ZWQgdG8gaW5zZXJ0IGl0IG9ubHkgd2hlbiBW aWEgaXMgcHJlc2VudC4gV2UgY2FuIHVwZGF0ZSB0aGF0IHRleHQgdG8gbWVudGlvbiAiVmlhIG9y IENETi1Mb29wIi4NCg0KV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIGZvciBDb0FQLXRvLUhUVFA/ DQoqIE1hcCBieSBkZWZhdWx0IEhvcC1MaW1pdCB0byBWaWENCiogTWFwIHRvIENETi1Mb29wIGlm IHRoZSBwcm94eSBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZG8gc28uICANCg0KPiANCj4g VGhlcmUncyBhbHNvIHRoZSBwcm9ibGVtIHdoZW4gYSBDb0FQLXRvLUhUVFAgYW5kIGEgSFRUUC10 by1Db0FQIHByb3h5DQo+IGFyZSBzZW5kaW5nIGEgbWVzc2FnZSBpbiBhIGxvb3AgKHBvc3NpYmx5 IHdpdGggbW9yZSBDb0FQIGFuZC9vciBIVFRQDQo+IHByb3hpZXMgaW4gYmV0d2VlbikuIEl0IHdv dWxkIGJlIG5pY2UgaWYgdGhpcyBjb3VsZCBiZSBkZXRlY3RlZC4NCj4gT3RoZXJ3aXNlLCBtYXli ZSBzb21lIHRleHQgc2hvdWxkIGJlIGFkZGVkIHRoYXQgdGhpcyBzY2VuYXJpbyBjYW5ub3QNCj4g YmUgZGV0ZWN0ZWQgd2l0aCB0aGUgSG9wLUxpbWl0IG9wdGlvbi4NCg0KW01lZF0gIFRoaXMgaXMg c2ltaWxhciB0byB0aGUgY2FzZSB3aGVyZSBhIENvQVAgcmVxdWVzdCBjcm9zc2VzIG11bHRpcGxl IGFkbWluaXN0cmF0aXZlIGRvbWFpbnMuIFdoYXQgYWJvdXQgYWRkaW5nIHRoZSBmb2xsb3dpbmc6 DQoNCiAgIFdoZW4gYm90aCBIVFRQLXRvLUNvQVAgYW5kIENvQVAtdG8tSFRUUCBwcm94aWVzIGFy ZSBpbnZvbHZlZCwgdGhlDQogICBsb29wIGRldGVjdGlvbiBtYXkgZ2V0IGJyb2tlbiBpZiB0aGUg cHJveHktZm9yd2FyZGVkIHRyYWZmaWMNCiAgIHJlcGVhdGVkbHkgY3Jvc3NlcyB0aGUgSFRUUC10 by1Db0FQIGFuZCBDb0FQLXRvLUhUVFAgcHJveGllcy4NCiAgIE5ldmVydGhlbGVzcywgaWYgdGhl IGxvb3AgaXMgd2l0aGluIHRoZSBDb0FQIG9yIEhUVFAgbGVncywgdGhlIGxvb3ANCiAgIGRldGVj dGlvbiBpcyBzdGlsbCBmdW5jdGlvbmFsLg0KDQo+IA0KPiBLbGF1cw0K From nobody Thu Jun 27 07:22:18 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881D2120026 for ; Thu, 27 Jun 2019 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlxiUlyikqSv for ; Thu, 27 Jun 2019 07:22:14 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50080.outbound.protection.outlook.com [40.107.5.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9597120074 for ; Thu, 27 Jun 2019 07:22:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=M6Vvo4VVNA1QWovQuLYYJqCf+GSn3kkkb0TPx5ZsNrtkKcUYLUA+zwFqREOzd7VdhZSmO1Xf7b/YW4TipPpPiJ1W91Fid5LcOpz45+zEJOCJYW0Y0Fs/1FxX9zTyi7Xt2vCaQ4anz3+iiH57LPNigDph1QZqunlvq47C5y5h2bM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k407YnyvbKNetVmOUG7oTNwdzeJthQZov09d+epoQZY=; b=lzJ8gUD7MqqqhR8jFD3hnjHRd176mHCe2pY8ukwN7pvrAQ7h+Ca5gA4BEteB2gZ9eQ3Idpl2axgXZRd9maAKmXeMEYuYURM0UapLZFAL+sHKMT+4WFhWg5xEkh6W2azg3j17VYPhFWH3PpIxfSLlO4Ms+qB1wPBzOfrZXYJ2JVY= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k407YnyvbKNetVmOUG7oTNwdzeJthQZov09d+epoQZY=; b=O496T158gaw1liXAVlr+F582gVRgv/ld4kDaRydxj0bMwj9pIBSyMvV8xejm5FfLAKsoZRWBL5BmlR9+52D6haK5uLhh0kEiCBan4uuz04ZTiHOr+O2vpSsyznkCi2qzGGO0pZHBm9cIzb/Q3d6A1abbWcaiEvZy+L90SZb5Y0M= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.4.202) by AM6PR08MB3591.eurprd08.prod.outlook.com (20.177.114.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 14:22:10 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::6897:93dc:1fd:e091]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::6897:93dc:1fd:e091%4]) with mapi id 15.20.2008.017; Thu, 27 Jun 2019 14:22:10 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: Review of draft-ietf-core-stateless-01 (editorial bits) Thread-Index: AQHVLPO1B5qSkPdKKE6UQ1I1Y43qgA== Date: Thu, 27 Jun 2019 14:22:10 +0000 Message-ID: <3884679F-4236-42D5-A643-0957D1B6F3C9@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [93.44.81.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0d034ab-ca8a-47b2-4596-08d6fb0ad79d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3591; x-ms-traffictypediagnostic: AM6PR08MB3591: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(366004)(39860400002)(136003)(40434004)(189003)(199004)(7736002)(6486002)(229853002)(66946007)(6436002)(256004)(486006)(2616005)(53936002)(6246003)(2501003)(5660300002)(91956017)(71190400001)(66446008)(8936002)(476003)(81166006)(6506007)(316002)(86362001)(25786009)(66556008)(1730700003)(8676002)(66476007)(76116006)(99286004)(73956011)(81156014)(6512007)(71200400001)(14444005)(14454004)(33656002)(26005)(72206003)(102836004)(64756008)(186003)(6916009)(3846002)(4744005)(5024004)(2351001)(6116002)(305945005)(36756003)(66066001)(478600001)(2906002)(68736007)(4326008)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3591; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LtJX8gcn6590niCm4tpykQ4Lk5gEdZMlKACBeCr3nIA3leoo1jIq107L3lQOpHXP5Ng4h1wkcAdk2Bao7PzRMmOru6qrzFc3+I7T4UfYnC2NAw16eaGWQ4dfgZ9Rw/tLqwPSBzMI6y1wNMMFC7iMkNuDmXCGuw3iY13kGzk7UwE+7GLFVoyZjDIbFnZBllmOQPCVzt7TzANasS1kFNbttBaAC6wQdI2tkkJGohXeafNRB+luSNyU93s9vImR3Fqr1Tc6L64A977AUG9OklnPHOFxY+euccvKTGdPvuy7jEiQZiYtm+PEuFA8IHw/LrmjlWTS2PTUQEqwP+pCCbJIYbmWkRnoxnI/B3hSvefJYmt9LgAan/kaefOhSWjmK70b5CB+RZKxlSpzlWIG/CnyqAmxlrZ+ogbd4ujXrCGmoCk= Content-Type: text/plain; charset="utf-8" Content-ID: <65931A45BA0A324E943E09B186F846D3@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0d034ab-ca8a-47b2-4596-08d6fb0ad79d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 14:22:10.4297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Thomas.Fossati@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3591 Archived-At: Subject: Re: [core] Review of draft-ietf-core-stateless-01 (editorial bits) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 14:22:17 -0000 TGFzdCBiYXRjaCBvZiAocHVyZWx5IGVkaXRvcmlhbCkgY29tbWVudHM6DQoNClNlY3Rpb24gMS4x IGRlZmluZXMgdGhlIHNob3J0aGFuZCBDbGllbnQgYW5kIFNlcnZlci4gIEluIHRoZSByZW1haW5k ZXINCm9mIHRoZSBtZW1vIHRoZXNlIGFyZSBub3QgdXNlZCBhbmQgdGhlIGxvbmcgdmVyc2lvbiAi c2VydmVyIG9yDQppbnRlcm1lZGlhcnkgaW4gdGhlIHNlcnZlciByb2xlIiBhbmQgImNsaWVudCBv ciBpbnRlcm1lZGlhcnkgaW4gdGhlDQpjbGllbnQgcm9sZSIgYXJlIHVzZWQgaW5zdGVhZC4gIEVp dGhlciB1c2UgdGhlIHNob3J0aGFuZCBvciBkcm9wIHRoZW0uDQoNClNlY3Rpb24gMS4xDQogICBb Li4uXSBzdWNoIGFzIHN0YXRlIGZvciBnZW5lcmF0aW5nIHRva2VucyBhbmQgY29uZ2VzdGlvbiBj b250cm9sDQoNCnMvZ2VuZXJhdGluZyB0b2tlbnMvcmVxdWVzdCByZXRyYW5zbWlzc2lvbi8gPw0K DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Fri Jun 28 03:19:04 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6B120220 for ; Fri, 28 Jun 2019 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Zche1_A8sd8G for ; Fri, 28 Jun 2019 03:18:58 -0700 (PDT) Received: from 17.mo3.mail-out.ovh.net (17.mo3.mail-out.ovh.net [87.98.178.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653AE120130 for ; Fri, 28 Jun 2019 03:18:57 -0700 (PDT) Received: from player168.ha.ovh.net (unknown [10.108.54.203]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id E237221C256 for ; Fri, 28 Jun 2019 12:18:52 +0200 (CEST) Received: from simonbernard.eu (134.163-14-84.ripe.coltfrance.com [84.14.163.134]) (Authenticated sender: contact@simonbernard.eu) by player168.ha.ovh.net (Postfix) with ESMTPSA id 27ACA741994E; Fri, 28 Jun 2019 10:18:49 +0000 (UTC) To: Fredrik Wegelid Cc: core References: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se> <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> From: Simon Bernard Message-ID: <4106fb23-a3ba-1a38-7bdd-b48cc5e82995@simonbernard.eu> Date: Fri, 28 Jun 2019 12:18:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA1859DD239AD7574622859F" Content-Language: en-US X-Ovh-Tracer-Id: 16828825909410478247 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrvddtgddvlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 10:19:03 -0000 This is a multi-part message in MIME format. --------------EA1859DD239AD7574622859F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fredrik, Reading RFCs, I would assume that this is not really recommended. The RFC7967 says that benefits are : /"Reduction in server-side load by relieving the server from responding to requests for which responses are not necessary."/ But in case of block-wise transfer, the response seems clearly necessary or at least the acknowledgement which is the only mechanism available for UDP packet drop/reorder issue. RFC7959 says : /"using Non-confirmable requests within block-wise transfers outside the use case of Section 2.8 would escalate the overall non-delivery probability"/. (translation CON is strongly recommended) Generally block must be sent/received in right order else you could face issue like this : /"If not all previous blocks are available at the server at the time of processing the final block, the transfer fails and error code 4.08 (Request Entity Incomplete, Section 2.9.2) MUST be returned.  A server MAY also return a 4.08 error code for any (final or non-final) Block1 transfer that is not in sequence; therefore, clients that do not have specific mechanisms to handle this case SHOULD always start with block zero and send the following blocks in order."/ (RFC7959) As /"a sequence of block-wise transfers should be performed 'without undue delay'"/, piggybacked are really well-suited for block-wise transfers.  (RFC7959) And using No-Response with CON would probably not help in your case. /"Using this option with CON requests may not serve the desired purpose if piggybacked responses are triggered."/(RFC7967) Simon Le 27/06/2019 à 15:22, Fredrik Wegelid a écrit : > Hi Abhijan, > > Thank you for your response. It is great to see how engaged you guys > are :) > > The reason that we are talking about this solution are the > requirements for the devices in our network. We have devices sending > messages (that are big enough to require a blockwise transfer) that > have very high requirements when it comes to battery consumption. In > order to listen for responses the devices have to keep the radio > turned on to listen for these responses. By not listening to the > responses (except the last one) we can keep the radio turned off for a > larger portion of the time and in such a way save battery. This is our > reasoning for wanting to use No-Response together with blockwise. > > I understand that from a network perspective this does not really make > sense. To reduce the amount of traffic on the network I agree that it > would be better to listen for the 2.31 Continue responses and restart > the blockwise transfer in the case of a lost block. If we do not have > to listen to these responses we could hopefully reduce the power > consumption of the device. > > BR, > Fredrik > >> On 27 Jun 2019, at 07:18, Abhijan Bhattacharyya >> > > wrote: >> >> Hi Fredrick and Carsten, >> Thanks for the discussion so far. Let me put my thoughts. >> >> The proposal to reduce the traffic in case of block-wise transfer >> using no-response is obvious. However, there is a catch. As per my >> understanding, the use case considered for block-wise transfer >> relates to transfers demanding high integrity of the received data >> and very low complexity at the receiving end in re-assembling the >> segments. One example is firmware upgrade of remote sensors: you >> cannot miss a single bit. Also, the message reception is tightly >> sequential in order. In case you miss one segment or receive in >> out-of-order, the transfers seizes in between. >> >> Now, Fredrick, coming to your solution: I do not know the QoS >> requirements in your perceived use case. You do not care about >> responses of intermediate blocks (essentially this means RESTfully >> fire-and-forget!) and you take the response of the last block to >> ensure the end of transfer. Now the question is, if you care for all >> the blocks at the receiving end (for which you did not care for a >> response) how do you ensure reception of all the blocks? Considering >> the resource constrains in IoT use cases it will be a wastage of >> bandwidth if you have sent all the segments from the transmit end and >> the receiver, after receiving the end block, realizes that one >> intermediate segment got missing. The whole transfer, and the >> resource consumption related to that, becomes useless. You might have >> rather stopped at the loss instance and take corrective measures to >> resume. That would save your resources. So, there something more to >> think and design carefully according to the exact QoS requirements of >> the perceived class of use-cases. >> >> However, in case you are looking for real-time + low-latency + >> low-resource consuming transfer, you may please have a look at this >> proposal that we already submitted few months back: >> https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-02 . >> To relate this draft to your problem you may simply consider to model >> your block-wise traffic as a time-series traffic. >> >> Having said that, I did once nurture some ideas to make block-wise >> transfer "statistically" more resource-efficient, yet reliable . But, >> must I be confirmed about the efficacy of my idea, both theoretically >> and experimentally, before I speak about that. I have kept that in >> back burner. In case there is enough interest I can renew the >> interest and discuss. >> >> Thank you. >> >> With Best Regards >> Abhijan Bhattacharyya >> Consultant / Scientist, >> {Internet Protocols | 5G | Standardization}, >> TCS Research, >> Tata Consultancy Services >> Building 1B,Ecospace >> Plot -  IIF/12 ,New Town, Rajarhat, >> Kolkata - 700160,West Bengal >> India >> Ph:- +91 33 66884691 >> Cell:- +919830468972 | +918583875003 >> Mailto: abhijan.bhattacharyya@tcs.com >> >> Website: http://www.tcs.com >> ____________________________________________ >> Experience certainty. IT Services >> Business Solutions >> Consulting >> ____________________________________________ >> >> >> -----"core" > >> wrote: ----- >> To: Carsten Bormann > >> From: Fredrik Wegelid >> Sent by: "core" >> Date: 06/26/2019 05:28PM >> Cc: core > >> Subject: Re: [core] RFC 7967 (No-Response) together with block-wise >> transfers in CoAP >> >> "External email. Open with Caution" >> >> Hi Carsten, >> >> This is how an example looks like without the No-Response option. >> >> Client -> Server: NON POST Payload: “Block 1...” >> Server -> Client: NON 2.31 Continue >> Client -> Server: NON POST Payload: “Block 2...” >> Server -> Client: NON 2.31 Continue >> >> More blocks… >> >> Client -> Server: NON POST Payload: “Final block...” >> Server -> Client: NON 2.01 Created (As an example) >> >> With the No-Response option I wish the exchange to look something >> like this: >> >> Client -> Server: NON POST (No-Response:26) Payload: “Block 1...” >> Client -> Server: NON POST (No-Response:26) Payload: “Block 2...” >> >> More blocks… >> >> Client -> Server: NON POST Payload: “Final block...” >> Server -> Client: NON 2.01 Created (As an example) >> >> This would mean that the server would not send the 2.31 responses for >> each block (as the No-Response option is set to 26) while it still >> would send the final response (since the final block does not have >> the No-Response option set). >> This allows the client to ensure that all blocks were sent >> successfully. If they are not, the server would respond with another >> code. It would also mean that the amount of traffic on the network is >> reduced. >> >> Best regards, >> Fredrik >> >> > On 26 Jun 2019, at 13:43, Carsten Bormann > > wrote: >> > >> > Hi Fredrik, >> > >> > I’m not sure I entirely understand the message exchanges you >> envision; maybe you can provide an example. >> > >> > RFC 7967 has a way to suppress responses based on the response code. >> > Unfortunately, the granularity is on the class only at the moment. >> > The option that carries this information isn’t explicitly defined >> as an extension point.  Still, someone (the original author?  The >> WG?) might want to go ahead, e.g., by defining a bit in the option >> value that says “Not interested in 2.31 responses”.  (Maybe we want >> to understand what exactly a client would not be interested in a bit >> more before we go ahead allocating bits like this.) >> > >> > Abhijan, what do you think? >> > >> > Grüße, Carsten >> > >> > >> >> On Jun 26, 2019, at 13:30, Fredrik Wegelid >> > wrote: >> >> >> >> Hi, >> >> >> >> I hope that I am using this email list in the correct way. I >> apologise if that is not the case. >> >> I have some questions/thoughts about using the No-Response option >> (RFC 7967) together with block-wise transfers in COAP. >> >> >> >> In my team we are using CoAP to send messages from devices to a >> server. The messages are of such a size that we need to make >> block-wise transfers. In an attempt to reduce the amount of traffic >> in the network we have looked at using the No-Response option. We are >> however not clear on how this would work if used together with >> block-wise transfers. We would like to use the No-Response option to >> make the server omit the 2.31 Continue responses from the server on >> each block. We would however still like to be able to get a response >> on the last block to indicate the status of the entire block sequence. >> >> >> >> Does this make sense? In RFC 7967 block-wise transfers are not >> mentioned. Are they meant to be used together? >> >> >> >> Best regards, >> >> Fredrik Wegelid >> >> _______________________________________________ >> >> core mailing list >> >> core@ietf.org >> >> https://www.ietf.org/mailman/listinfo/core >> >> >> > >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> =====-----=====-----===== >> Notice: The information contained in this e-mail >> message and/or attachments to it may contain >> confidential or privileged information. If you are >> not the intended recipient, any dissemination, use, >> review, distribution, printing or copying of the >> information contained in this e-mail message >> and/or attachments to it are strictly prohibited. If >> you have received this communication in error, >> please notify us by reply e-mail or telephone and >> immediately and permanently delete the message >> and any attachments. Thank you >> >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------EA1859DD239AD7574622859F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Fredrik,

Reading RFCs, I would assume that this is not really recommended.

The RFC7967 says that benefits are :
"Reduction in server-side load by relieving the server from responding to requests for which responses are not necessary."

But in case of block-wise transfer, the response seems clearly necessary or at least the acknowledgement which is the only mechanism available for UDP packet drop/reorder issue.
RFC7959 says :
"using Non-confirmable requests within block-wise transfers outside the use case of Section 2.8 would escalate the overall non-delivery probability".
(translation CON is strongly recommended)

Generally block must be sent/received in right order else you could face issue like this :
"If not all previous blocks are available at the server at the time of processing the final block, the transfer fails and error code 4.08 (Request Entity Incomplete, Section 2.9.2) MUST be returned.  A server MAY also return a 4.08 error code for any (final or non-final) Block1 transfer that is not in sequence; therefore, clients that do not have specific mechanisms to handle this case SHOULD always start with block zero and send the following blocks in order." (RFC7959)

As "a sequence of block-wise transfers should be performed 'without undue delay'", piggybacked are really well-suited for block-wise transfers.  (RFC7959)

And using No-Response with CON would probably not help in your case.
"Using this option with CON requests may not serve the desired purpose if piggybacked responses are triggered."(RFC7967)

Simon

Le 27/06/2019 à 15:22, Fredrik Wegelid a écrit :
Hi Abhijan,

Thank you for your response. It is great to see how engaged you guys are :)

The reason that we are talking about this solution are the requirements for the devices in our network. We have devices sending messages (that are big enough to require a blockwise transfer) that have very high requirements when it comes to battery consumption. In order to listen for responses the devices have to keep the radio turned on to listen for these responses. By not listening to the responses (except the last one) we can keep the radio turned off for a larger portion of the time and in such a way save battery. This is our reasoning for wanting to use No-Response together with blockwise.

I understand that from a network perspective this does not really make sense. To reduce the amount of traffic on the network I agree that it would be better to listen for the 2.31 Continue responses and restart the blockwise transfer in the case of a lost block. If we do not have to listen to these responses we could hopefully reduce the power consumption of the device.

BR,
Fredrik

On 27 Jun 2019, at 07:18, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> wrote:

Hi Fredrick and Carsten,
Thanks for the discussion so far. Let me put my thoughts.

The proposal to reduce the traffic in case of block-wise transfer using no-response is obvious. However, there is a catch. As per my understanding, the use case considered for block-wise transfer relates to transfers demanding high integrity of the received data and very low complexity at the receiving end in re-assembling the segments. One example is firmware upgrade of remote sensors: you cannot miss a single bit. Also, the message reception is tightly sequential in order. In case you miss one segment or receive in out-of-order, the transfers seizes in between.

Now, Fredrick, coming to your solution: I do not know the QoS requirements in your perceived use case. You do not care about responses of intermediate blocks (essentially this means RESTfully fire-and-forget!) and you take the response of the last block to ensure the end of transfer. Now the question is, if you care for all the blocks at the receiving end (for which you did not care for a response) how do you ensure reception of all the blocks? Considering the resource constrains in IoT use cases it will be a wastage of bandwidth if you have sent all the segments from the transmit end and the receiver, after receiving the end block, realizes that one intermediate segment got missing. The whole transfer, and the resource consumption related to that, becomes useless. You might have rather stopped at the loss instance and take corrective measures to resume. That would save your resources. So, there something more to think and design carefully according to the exact QoS requirements of the perceived class of use-cases.

However, in case you are looking for real-time + low-latency + low-resource consuming transfer, you may please have a look at this proposal that we already submitted few months back: https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-02 . To relate this draft to your problem you may simply consider to model your block-wise traffic as a time-series traffic.

Having said that, I did once nurture some ideas to make block-wise transfer "statistically" more resource-efficient, yet reliable . But, must I be confirmed about the efficacy of my idea, both theoretically and experimentally, before I speak about that. I have kept that in back burner. In case there is enough interest I can renew the interest and discuss.

Thank you.     

With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization},
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________


-----"core" <core-bounces@ietf.org> wrote: -----
To: Carsten Bormann <cabo@tzi.org>
From: Fredrik Wegelid
Sent by: "core"
Date: 06/26/2019 05:28PM
Cc: core <core@ietf.org>
Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP

"External email. Open with Caution"

Hi Carsten,

This is how an example looks like without the No-Response option.

Client -> Server: NON POST Payload: “Block 1...”
Server -> Client: NON 2.31 Continue
Client -> Server: NON POST Payload: “Block 2...”
Server -> Client: NON 2.31 Continue

More blocks…

Client -> Server: NON POST Payload: “Final block...”
Server -> Client: NON 2.01 Created (As an example)

With the No-Response option I wish the exchange to look something like this:

Client -> Server: NON POST (No-Response:26) Payload: “Block 1...”
Client -> Server: NON POST (No-Response:26) Payload: “Block 2...”

More blocks…

Client -> Server: NON POST Payload: “Final block...”
Server -> Client: NON 2.01 Created (As an example)

This would mean that the server would not send the 2.31 responses for each block (as the No-Response option is set to 26) while it still would send the final response (since the final block does not have the No-Response option set).
This allows the client to ensure that all blocks were sent successfully. If they are not, the server would respond with another code. It would also mean that the amount of traffic on the network is reduced.

Best regards,
Fredrik

> On 26 Jun 2019, at 13:43, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Fredrik,
>
> I’m not sure I entirely understand the message exchanges you envision; maybe you can provide an example.
>
> RFC 7967 has a way to suppress responses based on the response code.
> Unfortunately, the granularity is on the class only at the moment.
> The option that carries this information isn’t explicitly defined as an extension point.  Still, someone (the original author?  The WG?) might want to go ahead, e.g., by defining a bit in the option value that says “Not interested in 2.31 responses”.  (Maybe we want to understand what exactly a client would not be interested in a bit more before we go ahead allocating bits like this.)
>
> Abhijan, what do you think?
>
> Grüße, Carsten
>
>
>> On Jun 26, 2019, at 13:30, Fredrik Wegelid <fredrik.wegelid@wittra.se> wrote:
>>
>> Hi,
>>
>> I hope that I am using this email list in the correct way. I apologise if that is not the case.
>> I have some questions/thoughts about using the No-Response option (RFC 7967) together with block-wise transfers in COAP.
>>
>> In my team we are using CoAP to send messages from devices to a server. The messages are of such a size that we need to make block-wise transfers. In an attempt to reduce the amount of traffic in the network we have looked at using the No-Response option. We are however not clear on how this would work if used together with block-wise transfers. We would like to use the No-Response option to make the server omit the 2.31 Continue responses from the server on each block. We would however still like to be able to get a response on the last block to indicate the status of the entire block sequence.
>>
>> Does this make sense? In RFC 7967 block-wise transfers are not mentioned. Are they meant to be used together?
>>
>> Best regards,
>> Fredrik Wegelid
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>

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

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you




_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------EA1859DD239AD7574622859F-- From nobody Fri Jun 28 04:47:19 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8B120162 for ; Fri, 28 Jun 2019 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hX98UO46vdd6 for ; Fri, 28 Jun 2019 04:47:13 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DA31200BA for ; Fri, 28 Jun 2019 04:47:13 -0700 (PDT) Received: from fe0vm1650.rbesz01.com (unknown [139.15.230.188]) by si0vms0217.rbdmz01.com (Postfix) with ESMTPS id 45Zw3f5z0qz4f3kZX; Fri, 28 Jun 2019 13:47:10 +0200 (CEST) Received: from fe0vm1740.rbesz01.com (unknown [10.58.172.176]) by fe0vm1650.rbesz01.com (Postfix) with ESMTPS id 45Zw3f5dWzz1QV; Fri, 28 Jun 2019 13:47:10 +0200 (CEST) X-AuditID: 0a3aad14-cc5ff7000000410a-12-5d15fe3e1f1f Received: from si0vm1949.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm1740.rbesz01.com (SMG Outbound) with SMTP id 48.45.16650.E3EF51D5; Fri, 28 Jun 2019 13:47:10 +0200 (CEST) Received: from SI-MBX2032.de.bosch.com (si-mbx2032.de.bosch.com [10.3.230.35]) by si0vm1949.rbesz01.com (Postfix) with ESMTPS id 45Zw3f3RQ1z6Cjg8F; Fri, 28 Jun 2019 13:47:10 +0200 (CEST) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2032.de.bosch.com (10.3.230.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 28 Jun 2019 13:47:10 +0200 Received: from SI-MBX2033.de.bosch.com ([fe80::88a0:7dd8:cf69:6aaa]) by SI-MBX2033.de.bosch.com ([fe80::88a0:7dd8:cf69:6aaa%4]) with mapi id 15.01.1713.007; Fri, 28 Jun 2019 13:47:10 +0200 From: "Kraus Achim (INST/ECS4)" To: Fredrik Wegelid CC: core , Abhijan Bhattacharyya Thread-Topic: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP Thread-Index: AQHVLBK8nICW0UGNtEGz9XWVWE27WKatrykAgAAD3wCAASLKAIAAh12AgAGSQ8A= Date: Fri, 28 Jun 2019 11:47:10 +0000 Message-ID: References: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se> <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.83.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA21TfUwbdRjmd3ftXRlnjmsr78rIZpmZLsrHNgcyWfbPEkKGX4kR3RCKXD8E WtIrBIgfiHMDaoQMMMAEug4Naxhff0CF0bDCNgo6iR8bVGdUcBuESeYCU2HMOw7W/uE/b973 eX/P8/x+z+UonHVTGspktnFWsy5PKw8lQpPORz17cE2dEdc/Gp04e3pInui504UnXhrtkR3C U9ra/sFSGhbrZSmT7hHyZfzN0BdyuDxTEWeNPZgVauz1N+EFC+8Uu4ajy9AnxipEUcDsg8kr fBUKpVimAYPfT0zh0uBBcM5ZTkjDHQR/fOYgpWEYQXmHD6tCCkrOJMEpxwgp9iomFvxDi+s4 zrwCAyebCbFXMq9DzaAdSWfSYdkzSIjWKuZFmLgbJcIE8ySsfFUmE3uaOQB1/eVI8mrE4PyP 0+sLBZMMdwf71r0QEwXd3d/iklcE9N68v34GGAbaLkg4MGqYm1nbwHeA7+ogEn1x5mnoGoiV qE9Anf03UvINB1/jLFGDIpqCVJsCjKYgRlMQw4EIF1Lrubii/PiEfXEx1myOL42Lj3nbkt+L pI+mcqMVr96LGAppw2j9fXUGK9MV8SX5XvQchWnV9OV/BeixbEtOiVHHGzOthXkcr9XQ2yZT j7HKRzBfmJ1v4nmTxexFQOFaFb31qiqDpXN0JaWc1SLRvCiSIrQRtIF66RjLGHQ2LpfjCjjr 5vYARWmBnn8gGIZbOQNXrDfl2TbX2igahYSEsI8Hb4JtMUrhRXupMME7QZSg+QJdPm8ybNC3 SnR2Ew1Qx9FRqmau2YlTFy+1CHXZ0ybU6UWxjjZ/4cRZwmwxc5oIenZV0GVEBWOh+dHNNNvo 6DRlBqsOWgTU59F1JGSrpLeL5DDhnwncCehIMcbwDTBA2nNW4DB9e6DnFsBx+27omrEj+KX+ DAafO8cxaDg7gcG96mUMLqy5cLj9tRuHCv93OIy5TxIw1n6bgArnEgFzE0syeHi8RQ5TNzvl sNrfLYf2sl45jJb/JIe/f/1LDgu1H5HwsK6ShPpztSR4T7SQ4J5ykdDT2kXC7NwaCWOdfRTc W7lCwXCFQwE+5w0FdLSvKuaFuDEh7qyPWTFum872P3FvoIG3acqQsbOm4+cPpyOrMz2pte8N 7Ej9waAvbt1vv7g3uTXmWu77lUdeq9515tPwna43uNK36Ez7lobe8ncXvtmepPbP7Bo/fMrx vDpC3+jYb3g17Zryz0aHbadTdT3hsPF7e/IN7QenfZHZsi1PdR9N/zLrgSs95tblkdyQQ0vD c/WVQ2n+KewZLcEbdfG7cSuv+w+0HqouywQAAA== Archived-At: Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 11:47:18 -0000 SGVsbG8gRnJlZHJpaywNCg0Kc28gdGhlIGFzc3VtcHRpb24sIHRoYXQgUkZDNzk2NyBnZW5lcmFs bHkgYXBwbGllcyBhbHNvIHRvIFJGQzc5NTksIHNlZW0gdG8gYmUgbmVnYXRlZC4NCg0KPiBzZW5k aW5nIG1lc3NhZ2VzICh0aGF0IGFyZSBiaWcgZW5vdWdoIHRvIHJlcXVpcmUgYSBibG9ja3dpc2Ug dHJhbnNmZXIpDQoNCkluIG15IGV4cGVyaWVuY2UsIFJGQzc5NTkgaXMgYXBwbGllZCB0byB0d28g dXNlLWNhc2VzOg0KLSBhIGR5bmFtaWMgcmVzb3VyY2UgaXMgdG9vIGxhcmdlIHRvIGZpdCBpbnRv IG9uZSBtZXNzYWdlIGFuZCBpcyB0aGVyZWZvcmUgc3BsaXQgaW4gZmV3IGJsb2NrcywgZWl0aGVy IHVzaW5nIGJsb2NrMSBvciBibG9jazINCi0gYSBzdGF0aWMgZ2lhbnQgcmVzb3VyY2UgbXVzdCBi ZSB0cmFuc2ZlcnJlZCwgcG90ZW50aWFsbHkgd2l0aCBwYXVzZXMgYW5kIHJlc3VtcHRpb25zLCBo b3BlZnVsbHkgdXNpbmcgYmxvY2syDQoNCkZvciB0aGUgImdpYW50IHJlc291cmNlIiwgSSB0aGlu aywgaXQncyBub3Qgd29ydGggdG8gdHJ5IGl0LCBpdCB3aWxsIGZhaWwgb3IgaXMgaW1wb3NzaWJs ZSBiZWNhdXNlIG9mIGJsb2NrMi4NCkZvciB0aGUgImZldyBibG9ja3MgcmVzb3VyY2UiIHlvdSBt YXkgZ2VuZXJhbGx5IGhhdmUgYSBjaGFuY2UsIHRoYXQgaXQgd29ya3MgZ29vZCBlbm91Z2guDQpZ b3VyIHdvcmRpbmcgImJpZyBlbm91Z2ggdG8gcmVxdWlyZSBhIGJsb2Nrd2lzZSB0cmFuc2ZlciIg cG9pbnRzIGludG8gdGhhdCBkaXJlY3Rpb24uDQpJJ20gc3RpbGwgbm90IGNsZWFyLCBpZiB5b3Vy IGFwcGxpY2F0aW9uIHJlcXVpcmVzLCB0aGF0IEFMTCBibG9ja3MgYXJlIHRyYW5zZmVycmVkLCBv ciBpZiBpdCBtYXkgYmUgYWNjZXB0YWJsZSwgdGhhdCB0aGUgZGF0YSBvZiBzb21lIGJsb2NrcyBh cmUgbWlzc2luZy4NCkVzcGVjaWFsbHksIGlmIGl0J3MgYWNjZXB0YWJsZSwgdGhhdCBzb21lIGJs b2NrcyBhcmUgbWlzc2luZywgUkZDNzk2NyB3aXRoIGEgcHJvcHJpZXRhcnkgYXBwbGljYXRpb24g bGF5ZXIgbWF5IGJlIGEgZmlyc3Qgc3RlcC4gIA0KDQpNaXQgZnJldW5kbGljaGVuIEdyw7zDn2Vu IC8gQmVzdCByZWdhcmRzIA0KDQpBY2hpbSBLcmF1cw0KDQpFbmdpbmVlcmluZyBDbG91ZCBTZXJ2 aWNlcyA0IEJvc2NoIElvVCBIdWIgKElOU1QvRUNTNCkgDQoNClZvbjogY29yZSA8Y29yZS1ib3Vu Y2VzQGlldGYub3JnPiBJbSBBdWZ0cmFnIHZvbiBGcmVkcmlrIFdlZ2VsaWQNCkdlc2VuZGV0OiBE b25uZXJzdGFnLCAyNy4gSnVuaSAyMDE5IDE1OjIzDQpBbjogQWJoaWphbiBCaGF0dGFjaGFyeXlh IDxhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4NCkNjOiBjb3JlIDxjb3JlQGlldGYub3Jn Pg0KQmV0cmVmZjogUmU6IFtjb3JlXSBSRkMgNzk2NyAoTm8tUmVzcG9uc2UpIHRvZ2V0aGVyIHdp dGggYmxvY2std2lzZSB0cmFuc2ZlcnMgaW4gQ29BUA0KDQpIaSBBYmhpamFuLA0KDQpUaGFuayB5 b3UgZm9yIHlvdXIgcmVzcG9uc2UuIEl0IGlzIGdyZWF0IHRvIHNlZSBob3cgZW5nYWdlZCB5b3Ug Z3V5cyBhcmUgOikNCg0KVGhlIHJlYXNvbiB0aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IHRoaXMg c29sdXRpb24gYXJlIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBkZXZpY2VzIGluIG91ciBuZXR3 b3JrLiBXZSBoYXZlIGRldmljZXMgc2VuZGluZyBtZXNzYWdlcyAodGhhdCBhcmUgYmlnIGVub3Vn aCB0byByZXF1aXJlIGEgYmxvY2t3aXNlIHRyYW5zZmVyKSB0aGF0IGhhdmUgdmVyeSBoaWdoIHJl cXVpcmVtZW50cyB3aGVuIGl0IGNvbWVzIHRvIGJhdHRlcnkgY29uc3VtcHRpb24uIEluIG9yZGVy IHRvIGxpc3RlbiBmb3IgcmVzcG9uc2VzIHRoZSBkZXZpY2VzIGhhdmUgdG8ga2VlcCB0aGUgcmFk aW8gdHVybmVkIG9uIHRvIGxpc3RlbiBmb3IgdGhlc2UgcmVzcG9uc2VzLiBCeSBub3QgbGlzdGVu aW5nIHRvIHRoZSByZXNwb25zZXMgKGV4Y2VwdCB0aGUgbGFzdCBvbmUpIHdlIGNhbiBrZWVwIHRo ZSByYWRpbyB0dXJuZWQgb2ZmIGZvciBhIGxhcmdlciBwb3J0aW9uIG9mIHRoZSB0aW1lIGFuZCBp biBzdWNoIGEgd2F5IHNhdmUgYmF0dGVyeS4gVGhpcyBpcyBvdXIgcmVhc29uaW5nIGZvciB3YW50 aW5nIHRvIHVzZSBOby1SZXNwb25zZSB0b2dldGhlciB3aXRoIGJsb2Nrd2lzZS4NCg0KSSB1bmRl cnN0YW5kIHRoYXQgZnJvbSBhIG5ldHdvcmsgcGVyc3BlY3RpdmUgdGhpcyBkb2VzIG5vdCByZWFs bHkgbWFrZSBzZW5zZS4gVG8gcmVkdWNlIHRoZSBhbW91bnQgb2YgdHJhZmZpYyBvbiB0aGUgbmV0 d29yayBJIGFncmVlIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGxpc3RlbiBmb3IgdGhlIDIu MzEgQ29udGludWUgcmVzcG9uc2VzIGFuZCByZXN0YXJ0IHRoZSBibG9ja3dpc2UgdHJhbnNmZXIg aW4gdGhlIGNhc2Ugb2YgYSBsb3N0IGJsb2NrLiBJZiB3ZSBkbyBub3QgaGF2ZSB0byBsaXN0ZW4g dG8gdGhlc2UgcmVzcG9uc2VzIHdlIGNvdWxkIGhvcGVmdWxseSByZWR1Y2UgdGhlIHBvd2VyIGNv bnN1bXB0aW9uIG9mIHRoZSBkZXZpY2UuDQoNCkJSLA0KRnJlZHJpaw0KDQoNCk9uIDI3IEp1biAy MDE5LCBhdCAwNzoxOCwgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxtYWlsdG86YWJoaWphbi5iaGF0 dGFjaGFyeXlhQHRjcy5jb20+IHdyb3RlOg0KDQpIaSBGcmVkcmljayBhbmQgQ2Fyc3RlbiwNClRo YW5rcyBmb3IgdGhlIGRpc2N1c3Npb24gc28gZmFyLiBMZXQgbWUgcHV0IG15IHRob3VnaHRzLg0K DQpUaGUgcHJvcG9zYWwgdG8gcmVkdWNlIHRoZSB0cmFmZmljIGluIGNhc2Ugb2YgYmxvY2std2lz ZSB0cmFuc2ZlciB1c2luZyBuby1yZXNwb25zZSBpcyBvYnZpb3VzLiBIb3dldmVyLCB0aGVyZSBp cyBhIGNhdGNoLiBBcyBwZXIgbXkgdW5kZXJzdGFuZGluZywgdGhlIHVzZSBjYXNlIGNvbnNpZGVy ZWQgZm9yIGJsb2NrLXdpc2UgdHJhbnNmZXIgcmVsYXRlcyB0byB0cmFuc2ZlcnMgZGVtYW5kaW5n IGhpZ2ggaW50ZWdyaXR5IG9mIHRoZSByZWNlaXZlZCBkYXRhIGFuZCB2ZXJ5IGxvdyBjb21wbGV4 aXR5IGF0IHRoZSByZWNlaXZpbmcgZW5kIGluIHJlLWFzc2VtYmxpbmcgdGhlIHNlZ21lbnRzLiBP bmUgZXhhbXBsZSBpcyBmaXJtd2FyZSB1cGdyYWRlIG9mIHJlbW90ZSBzZW5zb3JzOiB5b3UgY2Fu bm90IG1pc3MgYSBzaW5nbGUgYml0LiBBbHNvLCB0aGUgbWVzc2FnZSByZWNlcHRpb24gaXMgdGln aHRseSBzZXF1ZW50aWFsIGluIG9yZGVyLiBJbiBjYXNlIHlvdSBtaXNzIG9uZSBzZWdtZW50IG9y IHJlY2VpdmUgaW4gb3V0LW9mLW9yZGVyLCB0aGUgdHJhbnNmZXJzIHNlaXplcyBpbiBiZXR3ZWVu Lg0KDQpOb3csIEZyZWRyaWNrLCBjb21pbmcgdG8geW91ciBzb2x1dGlvbjogSSBkbyBub3Qga25v dyB0aGUgUW9TIHJlcXVpcmVtZW50cyBpbiB5b3VyIHBlcmNlaXZlZCB1c2UgY2FzZS4gWW91IGRv IG5vdCBjYXJlIGFib3V0IHJlc3BvbnNlcyBvZiBpbnRlcm1lZGlhdGUgYmxvY2tzIChlc3NlbnRp YWxseSB0aGlzIG1lYW5zIFJFU1RmdWxseSBmaXJlLWFuZC1mb3JnZXQhKSBhbmQgeW91IHRha2Ug dGhlIHJlc3BvbnNlIG9mIHRoZSBsYXN0IGJsb2NrIHRvIGVuc3VyZSB0aGUgZW5kIG9mIHRyYW5z ZmVyLiBOb3cgdGhlIHF1ZXN0aW9uIGlzLCBpZiB5b3UgY2FyZSBmb3IgYWxsIHRoZSBibG9ja3Mg YXQgdGhlIHJlY2VpdmluZyBlbmQgKGZvciB3aGljaCB5b3UgZGlkIG5vdCBjYXJlIGZvciBhIHJl c3BvbnNlKSBob3cgZG8geW91IGVuc3VyZSByZWNlcHRpb24gb2YgYWxsIHRoZSBibG9ja3M/IENv bnNpZGVyaW5nIHRoZSByZXNvdXJjZSBjb25zdHJhaW5zIGluIElvVCB1c2UgY2FzZXMgaXQgd2ls bCBiZSBhIHdhc3RhZ2Ugb2YgYmFuZHdpZHRoIGlmIHlvdSBoYXZlIHNlbnQgYWxsIHRoZSBzZWdt ZW50cyBmcm9tIHRoZSB0cmFuc21pdCBlbmQgYW5kIHRoZSByZWNlaXZlciwgYWZ0ZXIgcmVjZWl2 aW5nIHRoZSBlbmQgYmxvY2ssIHJlYWxpemVzIHRoYXQgb25lIGludGVybWVkaWF0ZSBzZWdtZW50 IGdvdCBtaXNzaW5nLiBUaGUgd2hvbGUgdHJhbnNmZXIsIGFuZCB0aGUgcmVzb3VyY2UgY29uc3Vt cHRpb24gcmVsYXRlZCB0byB0aGF0LCBiZWNvbWVzIHVzZWxlc3MuIFlvdSBtaWdodCBoYXZlIHJh dGhlciBzdG9wcGVkIGF0IHRoZSBsb3NzIGluc3RhbmNlIGFuZCB0YWtlIGNvcnJlY3RpdmUgbWVh c3VyZXMgdG8gcmVzdW1lLiBUaGF0IHdvdWxkIHNhdmUgeW91ciByZXNvdXJjZXMuIFNvLCB0aGVy ZSBzb21ldGhpbmcgbW9yZSB0byB0aGluayBhbmQgZGVzaWduIGNhcmVmdWxseSBhY2NvcmRpbmcg dG8gdGhlIGV4YWN0IFFvUyByZXF1aXJlbWVudHMgb2YgdGhlIHBlcmNlaXZlZCBjbGFzcyBvZiB1 c2UtY2FzZXMuDQoNCkhvd2V2ZXIsIGluIGNhc2UgeW91IGFyZSBsb29raW5nIGZvciByZWFsLXRp bWUgKyBsb3ctbGF0ZW5jeSArIGxvdy1yZXNvdXJjZSBjb25zdW1pbmcgdHJhbnNmZXIsIHlvdSBt YXkgcGxlYXNlIGhhdmUgYSBsb29rIGF0IHRoaXMgcHJvcG9zYWwgdGhhdCB3ZSBhbHJlYWR5IHN1 Ym1pdHRlZCBmZXcgbW9udGhzIGJhY2s6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1iaGF0dGFjaGFyeXlhLWNvcmUtYS1yZWFsaXN0LTAyIC4gVG8gcmVsYXRlIHRoaXMgZHJhZnQg dG8geW91ciBwcm9ibGVtIHlvdSBtYXkgc2ltcGx5IGNvbnNpZGVyIHRvIG1vZGVsIHlvdXIgYmxv Y2std2lzZSB0cmFmZmljIGFzIGEgdGltZS1zZXJpZXMgdHJhZmZpYy4NCg0KSGF2aW5nIHNhaWQg dGhhdCwgSSBkaWQgb25jZSBudXJ0dXJlIHNvbWUgaWRlYXMgdG8gbWFrZSBibG9jay13aXNlIHRy YW5zZmVyICJzdGF0aXN0aWNhbGx5IiBtb3JlIHJlc291cmNlLWVmZmljaWVudCwgeWV0IHJlbGlh YmxlIC4gQnV0LCBtdXN0IEkgYmUgY29uZmlybWVkIGFib3V0IHRoZSBlZmZpY2FjeSBvZiBteSBp ZGVhLCBib3RoIHRoZW9yZXRpY2FsbHkgYW5kIGV4cGVyaW1lbnRhbGx5LCBiZWZvcmUgSSBzcGVh ayBhYm91dCB0aGF0LiBJIGhhdmUga2VwdCB0aGF0IGluIGJhY2sgYnVybmVyLiBJbiBjYXNlIHRo ZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBJIGNhbiByZW5ldyB0aGUgaW50ZXJlc3QgYW5kIGRpc2N1 c3MuDQoNClRoYW5rIHlvdS4gwqAgwqDCoA0KDQpXaXRoIEJlc3QgUmVnYXJkcw0KQWJoaWphbiBC aGF0dGFjaGFyeXlhDQpDb25zdWx0YW50IC8gU2NpZW50aXN0LA0Ke0ludGVybmV0IFByb3RvY29s cyB8IDVHIHwgU3RhbmRhcmRpemF0aW9ufSwgDQpUQ1MgUmVzZWFyY2gsDQpUYXRhIENvbnN1bHRh bmN5IFNlcnZpY2VzDQpCdWlsZGluZyAxQixFY29zcGFjZQ0KUGxvdCAtIMKgSUlGLzEyICxOZXcg VG93biwgUmFqYXJoYXQsDQpLb2xrYXRhIC0gNzAwMTYwLFdlc3QgQmVuZ2FsDQpJbmRpYQ0KUGg6 LSArOTEgMzMgNjY4ODQ2OTENCkNlbGw6LSArOTE5ODMwNDY4OTcyIHwgKzkxODU4Mzg3NTAwMw0K TWFpbHRvOiBtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20NCldlYnNpdGU6IGh0 dHA6Ly93d3cudGNzLmNvbS8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpFeHBlcmllbmNlIGNlcnRhaW50eS4gSVQgU2VydmljZXMNCkJ1c2luZXNzIFNvbHV0 aW9ucw0KQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KDQotLS0tLSJjb3JlIiA8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4gd3Jv dGU6IC0tLS0tDQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxtYWlsdG86Y2Fib0B0emkub3JnPg0KRnJv bTogRnJlZHJpayBXZWdlbGlkIA0KU2VudCBieTogImNvcmUiIA0KRGF0ZTogMDYvMjYvMjAxOSAw NToyOFBNDQpDYzogY29yZSA8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Nv cmVdIFJGQyA3OTY3IChOby1SZXNwb25zZSkgdG9nZXRoZXIgd2l0aCBibG9jay13aXNlIHRyYW5z ZmVycyBpbiBDb0FQDQoiRXh0ZXJuYWwgZW1haWwuIE9wZW4gd2l0aCBDYXV0aW9uIg0KDQpIaSBD YXJzdGVuLA0KDQpUaGlzIGlzIGhvdyBhbiBleGFtcGxlIGxvb2tzIGxpa2Ugd2l0aG91dCB0aGUg Tm8tUmVzcG9uc2Ugb3B0aW9uLg0KDQpDbGllbnQgLT4gU2VydmVyOiBOT04gUE9TVCBQYXlsb2Fk OiDigJxCbG9jayAxLi4u4oCdDQpTZXJ2ZXIgLT4gQ2xpZW50OiBOT04gMi4zMSBDb250aW51ZQ0K Q2xpZW50IC0+IFNlcnZlcjogTk9OIFBPU1QgUGF5bG9hZDog4oCcQmxvY2sgMi4uLuKAnQ0KU2Vy dmVyIC0+IENsaWVudDogTk9OIDIuMzEgQ29udGludWUNCg0KTW9yZSBibG9ja3PigKYNCg0KQ2xp ZW50IC0+IFNlcnZlcjogTk9OIFBPU1QgUGF5bG9hZDog4oCcRmluYWwgYmxvY2suLi7igJ0NClNl cnZlciAtPiBDbGllbnQ6IE5PTiAyLjAxIENyZWF0ZWQgKEFzIGFuIGV4YW1wbGUpDQoNCldpdGgg dGhlIE5vLVJlc3BvbnNlIG9wdGlvbiBJIHdpc2ggdGhlIGV4Y2hhbmdlIHRvIGxvb2sgc29tZXRo aW5nIGxpa2UgdGhpczoNCg0KQ2xpZW50IC0+IFNlcnZlcjogTk9OIFBPU1QgKE5vLVJlc3BvbnNl OjI2KSBQYXlsb2FkOiDigJxCbG9jayAxLi4u4oCdDQpDbGllbnQgLT4gU2VydmVyOiBOT04gUE9T VCAoTm8tUmVzcG9uc2U6MjYpIFBheWxvYWQ6IOKAnEJsb2NrIDIuLi7igJ0NCg0KTW9yZSBibG9j a3PigKYNCg0KQ2xpZW50IC0+IFNlcnZlcjogTk9OIFBPU1QgUGF5bG9hZDog4oCcRmluYWwgYmxv Y2suLi7igJ0NClNlcnZlciAtPiBDbGllbnQ6IE5PTiAyLjAxIENyZWF0ZWQgKEFzIGFuIGV4YW1w bGUpDQoNClRoaXMgd291bGQgbWVhbiB0aGF0IHRoZSBzZXJ2ZXIgd291bGQgbm90IHNlbmQgdGhl IDIuMzEgcmVzcG9uc2VzIGZvciBlYWNoIGJsb2NrIChhcyB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9u IGlzIHNldCB0byAyNikgd2hpbGUgaXQgc3RpbGwgd291bGQgc2VuZCB0aGUgZmluYWwgcmVzcG9u c2UgKHNpbmNlIHRoZSBmaW5hbCBibG9jayBkb2VzIG5vdCBoYXZlIHRoZSBOby1SZXNwb25zZSBv cHRpb24gc2V0KS4NClRoaXMgYWxsb3dzIHRoZSBjbGllbnQgdG8gZW5zdXJlIHRoYXQgYWxsIGJs b2NrcyB3ZXJlIHNlbnQgc3VjY2Vzc2Z1bGx5LiBJZiB0aGV5IGFyZSBub3QsIHRoZSBzZXJ2ZXIg d291bGQgcmVzcG9uZCB3aXRoIGFub3RoZXIgY29kZS4gSXQgd291bGQgYWxzbyBtZWFuIHRoYXQg dGhlIGFtb3VudCBvZiB0cmFmZmljIG9uIHRoZSBuZXR3b3JrIGlzIHJlZHVjZWQuDQoNCkJlc3Qg cmVnYXJkcywNCkZyZWRyaWsNCg0KPiBPbiAyNiBKdW4gMjAxOSwgYXQgMTM6NDMsIENhcnN0ZW4g Qm9ybWFubiA8bWFpbHRvOmNhYm9AdHppLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBGcmVkcmlrLA0K PiANCj4gSeKAmW0gbm90IHN1cmUgSSBlbnRpcmVseSB1bmRlcnN0YW5kIHRoZSBtZXNzYWdlIGV4 Y2hhbmdlcyB5b3UgZW52aXNpb247IG1heWJlIHlvdSBjYW4gcHJvdmlkZSBhbiBleGFtcGxlLg0K PiANCj4gUkZDIDc5NjcgaGFzIGEgd2F5IHRvIHN1cHByZXNzIHJlc3BvbnNlcyBiYXNlZCBvbiB0 aGUgcmVzcG9uc2UgY29kZS4NCj4gVW5mb3J0dW5hdGVseSwgdGhlIGdyYW51bGFyaXR5IGlzIG9u IHRoZSBjbGFzcyBvbmx5IGF0IHRoZSBtb21lbnQuDQo+IFRoZSBvcHRpb24gdGhhdCBjYXJyaWVz IHRoaXMgaW5mb3JtYXRpb24gaXNu4oCZdCBleHBsaWNpdGx5IGRlZmluZWQgYXMgYW4gZXh0ZW5z aW9uIHBvaW50LiDCoFN0aWxsLCBzb21lb25lICh0aGUgb3JpZ2luYWwgYXV0aG9yPyDCoFRoZSBX Rz8pIG1pZ2h0IHdhbnQgdG8gZ28gYWhlYWQsIGUuZy4sIGJ5IGRlZmluaW5nIGEgYml0IGluIHRo ZSBvcHRpb24gdmFsdWUgdGhhdCBzYXlzIOKAnE5vdCBpbnRlcmVzdGVkIGluIDIuMzEgcmVzcG9u c2Vz4oCdLiDCoChNYXliZSB3ZSB3YW50IHRvIHVuZGVyc3RhbmQgd2hhdCBleGFjdGx5IGEgY2xp ZW50IHdvdWxkIG5vdCBiZSBpbnRlcmVzdGVkIGluIGEgYml0IG1vcmUgYmVmb3JlIHdlIGdvIGFo ZWFkIGFsbG9jYXRpbmcgYml0cyBsaWtlIHRoaXMuKQ0KPiANCj4gQWJoaWphbiwgd2hhdCBkbyB5 b3UgdGhpbms/DQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiANCj4+IE9uIEp1biAyNiwg MjAxOSwgYXQgMTM6MzAsIEZyZWRyaWsgV2VnZWxpZCA8bWFpbHRvOmZyZWRyaWsud2VnZWxpZEB3 aXR0cmEuc2U+IHdyb3RlOg0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gSSBob3BlIHRoYXQgSSBhbSB1 c2luZyB0aGlzIGVtYWlsIGxpc3QgaW4gdGhlIGNvcnJlY3Qgd2F5LiBJIGFwb2xvZ2lzZSBpZiB0 aGF0IGlzIG5vdCB0aGUgY2FzZS4NCj4+IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucy90aG91Z2h0cyBh Ym91dCB1c2luZyB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uIChSRkMgNzk2NykgdG9nZXRoZXIgd2l0 aCBibG9jay13aXNlIHRyYW5zZmVycyBpbiBDT0FQLg0KPj4gDQo+PiBJbiBteSB0ZWFtIHdlIGFy ZSB1c2luZyBDb0FQIHRvIHNlbmQgbWVzc2FnZXMgZnJvbSBkZXZpY2VzIHRvIGEgc2VydmVyLiBU aGUgbWVzc2FnZXMgYXJlIG9mIHN1Y2ggYSBzaXplIHRoYXQgd2UgbmVlZCB0byBtYWtlIGJsb2Nr LXdpc2UgdHJhbnNmZXJzLiBJbiBhbiBhdHRlbXB0IHRvIHJlZHVjZSB0aGUgYW1vdW50IG9mIHRy YWZmaWMgaW4gdGhlIG5ldHdvcmsgd2UgaGF2ZSBsb29rZWQgYXQgdXNpbmcgdGhlIE5vLVJlc3Bv bnNlIG9wdGlvbi4gV2UgYXJlIGhvd2V2ZXIgbm90IGNsZWFyIG9uIGhvdyB0aGlzIHdvdWxkIHdv cmsgaWYgdXNlZCB0b2dldGhlciB3aXRoIGJsb2NrLXdpc2UgdHJhbnNmZXJzLiBXZSB3b3VsZCBs aWtlIHRvIHVzZSB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uIHRvIG1ha2UgdGhlIHNlcnZlciBvbWl0 IHRoZSAyLjMxIENvbnRpbnVlIHJlc3BvbnNlcyBmcm9tIHRoZSBzZXJ2ZXIgb24gZWFjaCBibG9j ay4gV2Ugd291bGQgaG93ZXZlciBzdGlsbCBsaWtlIHRvIGJlIGFibGUgdG8gZ2V0IGEgcmVzcG9u c2Ugb24gdGhlIGxhc3QgYmxvY2sgdG8gaW5kaWNhdGUgdGhlIHN0YXR1cyBvZiB0aGUgZW50aXJl IGJsb2NrIHNlcXVlbmNlLiANCj4+IA0KPj4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IEluIFJGQyA3 OTY3IGJsb2NrLXdpc2UgdHJhbnNmZXJzIGFyZSBub3QgbWVudGlvbmVkLiBBcmUgdGhleSBtZWFu dCB0byBiZSB1c2VkIHRvZ2V0aGVyPw0KPj4gDQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBGcmVkcmlr IFdlZ2VsaWQNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBjb3JlIG1haWxpbmcgbGlzdA0KPj4gbWFpbHRvOmNvcmVAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPj4gDQo+IA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5n IGxpc3QNCm1haWx0bzpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvcmUNCj09PT09LS0tLS09PT09PS0tLS0tPT09PT0NCk5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbA0KbWVzc2FnZSBhbmQvb3IgYXR0YWNo bWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gDQpjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbi4gSWYgeW91IGFyZSANCm5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz c2VtaW5hdGlvbiwgdXNlLCANCnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5 aW5nIG9mIHRoZSANCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdl IA0KYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiAN CnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgDQpwbGVhc2Ug bm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIA0KaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSANCmFuZCBhbnkgYXR0YWNobWVudHMu IFRoYW5rIHlvdQ0KDQoNCg== From nobody Fri Jun 28 16:03:34 2019 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 C8A511209B5; Fri, 28 Jun 2019 15:58:03 -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, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268381.11015.18188747270274041084.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:03 -0700 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 105 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, 28 Jun 2019 23:00:05 -0000 Dear Carsten Bormann, 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:30 requested) Tuesday, 23 July 2019, Afternoon Session III 1710-1810 Room Name: Duluth size: 150 --------------------------------------------- core Session 2 (1:30 requested) Thursday, 25 July 2019, Morning Session I 1000-1200 Room Name: Duluth size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor cose ace suit lwig artarea t2trg rats Second Priority: saag secdispatch sacm teep irtfopen 6tisch 6lo paw roll httpbis lpwan Third Priority: coinrg dinrg cfrg icnrg detnet dnssd netconf netmod emu dots anima People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Plse also avd any potntlly IoT reltd BOFs&PRGs (e.g., coin) tht mght cme up; also "loops". Prefer some time between the two meetings (48 h or more). Second meeting often is 40 people. ---------------------------------------------------------